F3-WG-Issue-5: Technology BGP-CT and CAR are based [upon] and implications [Jeffrey Zhang]

[sa1231-coder]

• 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

[sa1231-coder]

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.

[suehares]

Swadesh and DJ:

You need to query the IDR WG regarding your answer to this question.

Let's start with the following:

1. Existing Service (RFC4364 or RFC7432) being automatic resolved and steered over BGP CAR Transport paths.

Pick up the text from your -01.tx t that you believe clearly defines

1. Automatic resolution of Existing VPN services [RFC4364 and RFC7432] to be transported over BPG CAR paths. Make sure you cover the following scenario

[Existing VPN services (RFC4364 or RFC7432) domain}		[CAR domain (for transport) ]

[Existing VPN services (RFC4364 or RFC7432) domain]

2. Resolution of CAR Next-Hop via MPLS (LDP/RSVP-TE) Provide a paragraph (either new or from your -01.txt ) on how effecient it is.

After I see the text, we can decide to start 1 or 2 calls on this topic.

Cheers, Sue

After we agree

[suehares]

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

[suehares]

Query Jeffrey Zhang a copy to have his issues resolved.

[suehares]

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.

[sa1231-coder]

Took care of comments in 02 version. Requested review during WGLC and 2 interims. No further comments.