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

[Shawn Zhang <[e-mail]>]

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]> 于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]>
> 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
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>