Closed sa1231-coder closed 8 months ago
BGP CAR has identical protocol semantics to BGP-LU or BGP IPv4/v6. There is no use of VPN-like RDs or VPN import/export/re-origination at BGP transport nodes (ABRs, ASBRs etc).
Existing VPN services such as RFC 4364 or RFC 7432 get automatically resolved and steered over BGP CAR transport paths as described in Section 3, and Appendix A.
BGP CAR can resolve it’s Next-hops via traditional MPLS intra-domain transport (LDP/RSVP-TE) as describes in Section 2.5 and Appendix A.3.2. It thus seamlessly establishes end-to-end paths over both intent-aware and traditional routing/MPLS domains.
Swadesh and DJ:
You need to query the IDR WG regarding your answer to this question.
Let's start with the following:
Pick up the text from your -01.tx t that you believe clearly defines
[Existing VPN services (RFC4364 or RFC7432) domain} | [CAR domain (for transport) ] |
---|
[Existing VPN services (RFC4364 or RFC7432) domain]
After I see the text, we can decide to start 1 or 2 calls on this topic.
Cheers, Sue
After we agree
Appendix A.4 provides an example of CAR domains connected by BGP-LU. Appendix A.3.2 provides an example of CAR domains connected by RSVP-TE
Query Jeffrey Zhang a copy to have his issues resolved.
Appendix A.4 needs to include the AS boundaries in the diagram and text. An example of LU domains in a different AS should be added to section 4.
Appendix A.3.2 formatting issues should be fixed. Appendix A.3.2 should give an example of a specific AIGP penalty in the following sections to add clarity on the AIGP metric penalty.
- Local policy on 231 and 232 maps intent C1 to resolve CAR route
next-hop over best effort LDP LSP in access domain 1. BGP CAR
label swap entry is installed that goes over LDP LSP to next-
hop. AIGP metric is updated to reflect best effort metric to
next- hop with an additional penalty.
- Local policy on 121 and 122 maps intent C1 to resolve CAR route
next-hop in Core domain over TE tunnels. BGP CAR label swap
entry is installed that goes over a TE tunnel to next-hop
providing intent in Core domain. AIGP metric is updated to
reflect TE tunnel metric.
After these are fixed, I will review the section again.
Took care of comments in 02 version. Requested review during WGLC and 2 interims. No further comments.
• Chair + Jeffrey Zhang: define an example of RD, RTCs, and labels passed by VPN services that might interact with CT and CAR domains. • CT: Clarify the interaction with RDs and RTCs by discussing how CT handles RDs, RTCs, labels and other VPN signaling information that sent to domain with CT. • CT discuss how efficient CT is in domains which do not handle SR-MPLS or VPNs. • CAR: Clarify the interaction with RDs and RTCs by discussing how CAR handles RDs, RTCs, labels and other VPN signaling information that sent to domain with CAR. • CAR discuss how efficient CAR is domains which do not handle SR-MPLS or VPNs