Re: [Idr] Fwd: Part 2 of CAR/CT Adoption call (7/6 to 7/20) - Adoption of draft-dskc-bess-bgp-car-05.txt and draft-kaliraj-idr-bgp-classful-transport-planes-17.txt

[Susan Hares <[e-mail]>]

Shawn:

Thank you for letting me know your feedback on the two proposals.

Would you mind sharing which  company do you work for?


Thank you, Sue

From: Shawn Zhang <[e-mail]>
Sent: Monday, July 11, 2022 5:58 AM
To: Ketan Talaulikar <[e-mail]>
Cc: Susan Hares <[e-mail]>; idr@ietf. org <[e-mail]>
Subject: Re: [Idr] Fwd: Part 2 of CAR/CT Adoption call (7/6 to 7/20) - Adoption of draft-dskc-bess-bgp-car-05.txt and draft-kaliraj-idr-bgp-classful-transport-planes-17.txt

As an end customer, I support the adoption of BGP-CT. why i support CT? when deploying inter-as tunnels before, we have hit the problems as: . A domain may have intra-AS tunnels with varying TE charac
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzg0NjI1OWNlZTUyOGM1OTljMmJiODAwNTZmYjFjZmJlLzE2NTc1MzM0ODguODI=#key=92aff7018521b1f4a3516d7790448830>  FAQ<https://www.inky.com/banner-faq>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>

As an end customer, I support the adoption of BGP-CT.

why i support CT?  when deploying inter-as tunnels before, we have hit the problems as:
. A domain may have intra-AS tunnels with varying TE characteristics (gold, silver, bronze) denoting different SLAs.
. There could be multiple tunnels to the same destination. And different tunneling protocols creating those tunnels in different adjacent domains.
. The tunnels may need to be extended inter-domain, while preserving their TE characteristics (aka ‘color’) end-to-end. Extend BGP protocol to signal these pieces of information.
. Provide inter-op between different tunneling protocols that may be in use in different domains.
. Provide ability to map a Service route to
.. Tunnels of a certain TE characteristic, with fallback to best-effort tunnels (Default).
.. Tunnels of a certain TE characteristic, without any fallback.
.. Tunnels of a certain TE characteristic, with fallback to a different TE characteristics.
. Restrict best-effort service-routes from using ‘colored’ tunnels. They use only best-effort tunnels.
. Mapping to Inter-domain tunnels should work the same way as mapping to Intra-domain tunnels.


How BGP-CT can solve the problems?
. Implement a new construct viz. “Transport Class”, that collects tunnels of a certain TE characteristic.
. The “Transport Class” maps to the “Transport Topology Slice” in 5G Network-slicing.
. A Transport class is identified by a 32bit Color. This Color value aligns with the Color carried in SR transport-protocols like SRTE, ISIS-FlexAlgo. And it is carried to neighboring AS-domains as “Transport Route Target” using a new BGP family: BGP-CT
Implement support in Transport protocols to associate a tunnel to a specific Transport class. RSVP, ISIS-FlexAlgo are supported.
. Service routes carry ‘mapping-community’ (e.g. Color extended community) that indicate the desired SLA. This lets them resolve over tunnels in associated transport-class RIB.
. Implement “Resolution Scheme” construct to provide the more sophisticated fallback schemes.
. By default, service-routes binding to a transport class use best-effort tunnels as fallback. as you know, fallback is always what we have to consider all time.
. BGP protocol extensions extend the Classful Transport architecture to multi-domain.
. It defines a new Transport Layer BGP family, viz. “BGP CT”, which uses SAFI: 76,
. BGP families ”inet transport” and “inet6 transport”.
. A new route-target “Transport-Class Route Target” is defined to carry the Transport class ID (Color).
. This new family follows time tested VPN mechanisms (RFC-4364) to leak transport-routes to appropriate Transport Class RIBs. It follows RFC-8277 NLRI encoding. by default, i.e. does not advertise anything to EBGP peers without explicit export policy.
. The new transport-family uses sane defaults like per-prefix-label,
. we have benchmarkingly tested the arch, base on junos, basically meets our requiremnet.

Thanks.

Ketan Talaulikar <[e-mail]<mailto:[e-mail]>> 于2022年7月11日周一 14:51写道：
Forwarding this on behalf of DJ since he is having some IT issues.

---------- Forwarded message ---------
From: Dhananjaya Rao <[e-mail]<mailto:[e-mail]>>
Date: Mon, Jul 11, 2022 at 12:02 PM
Subject: Re: [Idr] Part 2 of CAR/CT Adoption call (7/6 to 7/20) - Adoption of draft-dskc-bess-bgp-car-05.txt and draft-kaliraj-idr-bgp-classful-transport-planes-17.txt
To: <[e-mail]<mailto:[e-mail]>>

(Re-sending, due to some issue with posting)


As co-author, I support the adoption of BGP-CAR.



I support it for the following technical and operational benefits it provides, and it’s significant architectural advantages over short-term solutions such as BGP-CT.



    1.     Protocol efficiency and operational simplicity



For over 20 years, operators have run transport networks using BGP IPv4/IPv6 and BGP-LU for MPLS. BGP-CAR preserves that operational and routing model. These protocols operate on an IP prefix. BGP-CAR extends it to IP prefix + Color. It is therefore the simplest and most natural extension to introduce color-awareness in BGP.



This design choice is not merely functional, it is critical to the simplicity and efficiency of the BGP protocol processing and supporting scale on the order of several 100s of thousands of prefixes (PEs) across a multi-domain network.



Inserting a MPLS VPN paradigm for BGP hop-by-hop routing with RDs and VPN import/export at each hop is not only totally unnecessary, but it has real implementation complexity, and operational impact (unlike the spurious ones made against BGP-CAR).



One of the most basic functions provided inherently by BGP IPv4/IPv6 and BGP-LU is merging of multiple paths at a BGP hop and propagating a single path with next-hop set to self while providing multipathing (ECMP/backup) at that hop, suppressing the churn of failures/changes to alternate paths locally, and providing fast convergence around failures locally.



BGP-CAR naturally provides it because of the (E, C) model.



BGP-CT utterly fails to do it, because of the choice to use an opaque RD for each originated route.



As has previously been discussed on both the list and in the previous IDR sessions, either you get failure propagation all the way to the ingress PEs in all domains and slow convergence; or you get a workaround called “RD stripping” to merge the paths locally at each hop.



Leaving aside the irony of using an RD for its purported benefits only to strip it at every hop; it is worth looking at the implementation complexity and the operational impact.



Completely distinct BGP routes (different NLRI/keys) need to be merged to achieve multipath, and get a common label/LSP in the forwarding plane.



And yet even though they now map to a single label/LSP, all the distinct routes redundantly still need to be propagated to downstream BGP peers. Hence this workaround still does not address the churn/failure propagation of the alternate paths, those still will be sent all the way to all ingress PEs.



And since this needs to be done at every hop, it makes all the implementations who will need to this unnecessarily complex. And this unnatural behavior has no precedent in any MPLS/VPN network.



The impact of this suboptimal behavior only gets exacerbated when one uses it with Anycast, the one case that has gotten a lot of discussion lately. Instead of a couple of ABRs, now there may be 16, 32 or more such originating routers in each domain, hence that many more paths needing to be RD-stripped and propagated. And the number of such paths gets multiplied by the number of redundant peerings between domains.



VPN import/export also naturally adds CPU processing and memory utilization overhead. We incur this on PEs for good reason but it can be avoided on every BGP transport node.



Folks who seem to think simply repurposing an MPLS VPN paradigm for hop-by-hop BGP transport is better because of its perceived familiarity should consider the impact and trade-offs.



The CAR design, by emulating BGP-IP/LU provides the benefits of multipathing, local fast convergence and stability due to failure churn suppression, without requiring any VPN-like import/export at every hop, nor such workarounds.



    2.     Protocol extensibility



Different operators have different use-cases that are relevant to them.



BGP-CAR efficiently supports all the use-cases that have been discussed in this forum – including low-latency, diverse paths; avoidance of links/nodes/domains; Anycast/EPE etc. Many of these are described in the CAR draft (Ref: Appendix A).



More importantly, the color/intent-aware journey is just beginning, and no one can presumably claim to have or know all the use-cases today.



BGP-CAR is systematically designed for extensibility to accommodate new use-cases or operator constraints that will inevitably arise. It is also designed to simplify network operations when customers migrate from one transport technology to another.



BGP-CAR has route-types built in to enable new requirements, without requiring operators to deploy additional SAFIs in parallel with the just deployed one.



It has native support for signaling multiple encapsulations efficiently and independently. without needing to overload 24-bit MPLS label space, or use complex techniques to carry the data. It maintains the ability to pack multiple prefixes in an update message at the same time.



These extensions are being spuriously attacked as being complex and unnecessary. But we have multiple implementations that demonstrate otherwise.



There’s plenty of precedent in BGP SAFIs today that support route-types. All BGP SAFIs including BGP-LU and BGP-CT carry non-key data.



BGP CAR NLRI definition improves this design in a few ways



-       It adds structure to signaling such per-prefix information such as labels, SIDs,  label-index etc.

-       It allows each encap to a different forwarding value when multiple encaps are being signaled.

-       It provides efficient encoding such that BGP prefix packing is maintained.



We expect BGP-CAR will subsume and replace BGP-LU like SAFIs in transport networks over time.



BGP-CT uses the same encoding as BGP-LU (3107/8277), so inherits all limitations of BGP-LU



-       Only supports label encoding, no other encaps (without complex overloading or breaking update packing)

-       No extensibility



A new transport SAFI (that intends to augment/replace BGP-LU) should not have the same limitations as BGP-LU that was designed 20 years ago.



     3.  VPN CAR



Providers may want to extend color-aware routing to their customers, as well as carry their own color aware services over their core networks. BGP-CAR

extends seamlessly to the actual VPN layer via VPN CAR, where the notion of VPN RDs and RTs is actually needed to carry color-aware routes per-VRF.

Retrofitting this into a solution that already overloads RDs for transport/color purposes will introduce additional layers of complexity.



    4.     Native support for Color based automated steering and resolution



BGP-CAR solution is totally compliant with use of the Color ExtComm for automated steering of services, of which there are multiple implementations and deployments already with SR-Policy and IGP FlexAlgo.



The color based steering construct has demonstrated flexibility across a wide variety of use-cases as described in the SR-TE IETF draft . This can be augmented with any BGP based policy supported by an implementation,



There is no need to invent new “mapping communities” for the purpose as done by BGP-CT and break compatibility with existing technologies.



    5.   Support for network domains with different color/intent granularities



BGP-CAR establishes paths across domains that may have a lesser number of colors enabled, while maintaining the finer granularity needed by an end-to-end color-aware path. As described in Appendix B. of the BGP-CAR draft, It leverages the same Color-ExtComm based resolution that’s used for service steering



    6.     Support for color domains with inconsistent color-to-intent mappings



CAR supports the presence of multiple color domains, enabling the establishment of color-aware paths across such administrative boundaries, by virtue of the LCM-EC color translation/mapping mechanism.



While doing so, it provides the ability to achieve both multipathing as well as to make e2e paths from different egress domains available at an ingress PE for load-balancing. It avoids the suboptimal behavior (described above) needed by BGP-CT.



7.     It seamlessly resolves over and interworks with both color-aware technologies such as IGP   FlexAlgo and SR-TE as well as existing MPLS technologies (LDP/RSVP-TE and BGP-LU), enabling seamless insertion into existing MPLS networks.



8.     Works for multiple transport types – classic MPLS, SR-MPLS and SRv6 among others.



In summary, BGP-CAR solution has precisely and deliberately defined the base protocol for an efficient, scalable deployment for immediate use-cases of BGP based intent-aware routing, and an extensible framework to address intent requirements that may emerge in future.



Regards,

-Dhananjaya


_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr<https://shared.outlook.inky.com/link?domain=www.ietf.org&t=h.eJxFjUEOgyAURK_SsG74gkI_rryKIAipYgM0JDa9e2XV7byZNx_yThsZb8SX8sojQK2VBlscPdIK-xy2fY6whVxCdAeEJZH7jTzbItpydVgnUCrGIfs52TzF5fTUHDvgILlQxlrB0QilDNcau05Ip5lx2gKT4iH6fkCkyJvVNuulqfH02U9re2-qxpbG_sn3BzaVONE.MEUCIQD9dEl87hzbFDaqKeYXU7GmFqL-YqFpafQNE5UourIAHwIgOZHbgyE906h2jnO_56DIk9_5kOcostbOc4erI4l7V5g>