[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

[Ketan Talaulikar <[e-mail]>]

Forwarding this on behalf of DJ since he is having some IT issues.


---------- Forwarded message ---------
From: Dhananjaya Rao <[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]>


(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