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

[Ketan Talaulikar <[e-mail]>]

Hi Srihari,

A quick follow-up on your response below.


On Tue, Jul 19, 2022 at 6:52 PM Srihari Sangli <[e-mail]> wrote:

> Ketan,
>
>
>
> Please comments inline.
>
>
>
> Thanks & Regards,
>
>
>
> srihari…
>
>
>
>
>
> *From: *Idr <[e-mail]> on behalf of Ketan Talaulikar <
> [e-mail]>
> *Date: *Monday, 18 July 2022 at 7:02 PM
> *To: *Susan Hares <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>
> *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
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Sue/All,
>
>
>
> TL;DR - I support the adoption of the BGP-CAR draft
>
>
>
> As the WG evaluates the two BGP proposals, it is essential to step back
> and review
> https://datatracker.ietf.org/doc/draft-hr-spring-intentaware-routing-using-color/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hr-spring-intentaware-routing-using-color/__;!!NEt6yMaO-gk!C87bEXrV_LFCIcFpo5LiwIGBHoFQmh1UrxDe2pwDL8Eo4XUxXxphElw1b_X95P01COvBs-8Ds2yI0HYqY2bP$> which
> captures the broader problem statement.
>
>
>
> What we need from BGP is to signal these "intent" aware paths for
> destinations through multi-domain networks. Color is an existing notion in
> BGP as an abstraction for "intent". Therefore, the most natural data model
> representation in a BGP NLRI would be (Prefix, Color). BGP CAR proposal is
> aligned with it.
>
>
>
>
>
> Srihari> To restate what the problem-statement draft (that you quote
> above) says – BGP needs “a” mechanism to signal the intent. It does not
> lead the reader or suggest any particular type of encoding. So, it is up to
> the solution-maker to propose different ways to signal the intent. We want
> color in BGP terminoloty as preferred mode to signal intent.
>
>
>
> I want to clarify this point as reading your email, one might get an
> impression that encoding color is the only way to satisfy the
> requirement/address the problem statement.
>
>
>
> Multi-domain networks today use different encapsulations in different
> domains based on various considerations - MPLS, VxLAN, SRv6, GRE, etc. The
> "intent" aware paths can be set up to destinations across one or more
> combinations of these encapsulations. We need the ability to not only
> stitch these paths at borders but also simultaneously signal multiple
> encapsulations since some domains may support more than one (either during
> the migration or in a steady state). BGP CAR proposal is trying to tackle
> this in a clean way without any implicit assumptions of MPLS.
>
>
>
>
>
> Srihari> I think we need to look at this in different perspective. “Clean”
> is subjective. IMO intent is providing various “types” of connectivity for
> a single endpoint. That “type” is best expressed as an attribute.
>

KT> Going by that logic, why is the MPLS label (which is also a "type" -
encapsulation info) being carried in the NLRI for a new SAFI design?

Thanks,
Ketan


>
>
> This is a new problem space that we are trying to tackle. To that end, a
> protocol needs to evolve and develop for handling the new requirements.
> That said, BGP CAR is not the first AFI/SAFI that is introducing or dealing
> with an extensible NLRI design (e.g., EVPN). Many such mechanisms are
> widely implemented and successfully deployed. BGP CAR is a fresh/clean
> approach that leverages and learns from existing BGP mechanisms as
> appropriate. I am sure the technical review in the WG will improve the
> specification (e.g., the inputs on error handling) and make them more
> robust for not just CAR but other similar BGP extensions required in the
> future. Therefore, some of these opinions being raised on the NLRI and
> encoding design seem like red herrings to me. I am all for leveraging
> existing BGP mechanisms but trying to force-fit those mechanisms to solve
> an entirely different problem space or resisting clean design approaches
> can lead to the ossification of the protocol.
>
>
>
> The BGP CAR keeps the notion of Color (as the "intent") consistent between
> the BGP Services and the BGP Transport layer. It maps in a straightforward
> manner to SR Policy mapping but is applicable to other "intent-aware"
> technologies like IGP FlexAlgo, RSVP-TE, and "best-effort" mechanisms like
> IGP-SR and LDP. There is a good balance of simplicity (I would call it
> "color consistency" across layers) and flexibility with policy mechanisms
> like mapping between colors, between layers, fallback mechanisms in
> resolution, etc.
>
>
>
> Most importantly, BGP CAR is exactly similar in operations to the BGP-LU
> (Seamless MPLS) design which most operators are familiar with. The BGP CAR
> proposal, only adds two things to the BGP-LU design - (a) the color
> ("intent") and (b) support for multiple encapsulations. All other aspects
> like route propagation, policies, convergence, scaling, and resolution are
> similar.
>
>
>
> Arrcus has an implementation of BGP CAR and has done interop testing with
> Cisco.
>
>
>
> I do not support the adoption of the BGP CT mechanism. It is trying to
> retrofit MPLS L3VPN constructs from the service layer to the transport
> layer and in doing so magnifies its well-known challenges (see [A] and [B])
> unnecessarily. It obfuscates the notion of "intent" or "color" with the
> introduction of new terminologies and a requirement to always perform
> policy mapping at each router. The transport needs to be simple to manage
> and operate. I am cautious not to get lulled into the notion of familiarity
> with VPNs as this might be just the tip of the iceberg. I note that some of
> the authors of BGP CT have two other proposals ("associated" drafts as
> indicated by Sue) to try and provide a scaling solution with multiple MPLS
> label spaces (a new AFI/SAFI) and a new BGP attribute for multi-NH. So, my
> concern is that taking an IMHO "time to market" (?) approach for a very
> important problem space can cost us more in the long run.
>
>
>
> 1.    Do you agree or disagree that these two drafts are functionally
> identical?
>
> KT> I believe they are functionally identical for the most part. However,
> the support for multiple encapsulation signaling is not very clear or
> obvious (at least to me) in the BGP CT draft. Other similar extensibility
> mechanisms may also arise down the line.
>
> 2.    If you agree, should we have just one draft, or do the operational
> difference encourage us to have two drafts?
>
> KT> One draft is definitely preferable.
>
> 3.    If you disagree, do the functional differences encourage us to have
> one or two drafts adopted?
>
> KT> Don't disagree but will await clarification on the extensibility and
> encapsulation-related functionality.
>
>
>
> [A] Check some of the points raised here:
> https://mailarchive.ietf.org/arch/msg/idr/R-ockSQHvDojiaEu__OgLBdOxBk/
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/R-ockSQHvDojiaEu__OgLBdOxBk/__;!!NEt6yMaO-gk!C87bEXrV_LFCIcFpo5LiwIGBHoFQmh1UrxDe2pwDL8Eo4XUxXxphElw1b_X95P01COvBs-8Ds2yI0FZ5lRFs$>
>
> [B] The discussion here is also related:
> https://mailarchive.ietf.org/arch/msg/idr/gRMxFd7R5HnIscR-Lqi6aDspf84/
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/gRMxFd7R5HnIscR-Lqi6aDspf84/__;!!NEt6yMaO-gk!C87bEXrV_LFCIcFpo5LiwIGBHoFQmh1UrxDe2pwDL8Eo4XUxXxphElw1b_X95P01COvBs-8Ds2yI0KhKVLdJ$>
>
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Wed, Jul 6, 2022 at 11:47 PM Susan Hares <[e-mail]> wrote:
>
> This begins a 2-week WG Adoption call (7/6/2022 to 7/20/2022) for the
> following drafts:
>
> · draft-dskc-bess-bgp-car-05.txt
>
> (https://datatracker.ietf.org/doc/draft-dskc-bess-bgp-car/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-dskc-bess-bgp-car/__;!!NEt6yMaO-gk!C87bEXrV_LFCIcFpo5LiwIGBHoFQmh1UrxDe2pwDL8Eo4XUxXxphElw1b_X95P01COvBs-8Ds2yI0E1b2P-V$>)
>
>
> · draft-kaliraj-idr-bgp-classful-transport-planes-17.txt
>
> (
> https://datatracker.ietf.org/doc/draft-kaliraj-idr-bgp-classful-transport-planes/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-kaliraj-idr-bgp-classful-transport-planes/__;!!NEt6yMaO-gk!C87bEXrV_LFCIcFpo5LiwIGBHoFQmh1UrxDe2pwDL8Eo4XUxXxphElw1b_X95P01COvBs-8Ds2yI0AZU-Rqs$>)
>
>
> The associated drafts may be useful in your consideration.
>
> CAR:
>
> · draft-ietf-spring-segment-routing-policy-22
>
> https://datatracker.ietf.org/doc/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/__;!!NEt6yMaO-gk!C87bEXrV_LFCIcFpo5LiwIGBHoFQmh1UrxDe2pwDL8Eo4XUxXxphElw1b_X95P01COvBs-8Ds2yI0IHFOKxu$>
> draft-ietf-spring-segment-routing-policy/
>
>
>
> · draft-ietf-idr-segment-routing-te-policy-18
>
> https://datatracker.ietf.org/doc/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/__;!!NEt6yMaO-gk!C87bEXrV_LFCIcFpo5LiwIGBHoFQmh1UrxDe2pwDL8Eo4XUxXxphElw1b_X95P01COvBs-8Ds2yI0IHFOKxu$>
> draft-ietf-idr-segment-routing-te-policy/
>
>
>
> · draft-dskc-bess-bgp-car-problem-statement-05.txt
>
> https://datatracker.ietf.org/doc/draft-dskc-bess-bgp-car-problem-statement/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-dskc-bess-bgp-car-problem-statement/__;!!NEt6yMaO-gk!C87bEXrV_LFCIcFpo5LiwIGBHoFQmh1UrxDe2pwDL8Eo4XUxXxphElw1b_X95P01COvBs-8Ds2yI0BHvNtNv$>
>
> CT
>
> · draft-hegde-spring-mpls-seamless-sr-06.txt
>
> https://datatracker.ietf.org/doc/draft-hegde-spring-mpls-seamless-sr/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hegde-spring-mpls-seamless-sr/__;!!NEt6yMaO-gk!C87bEXrV_LFCIcFpo5LiwIGBHoFQmh1UrxDe2pwDL8Eo4XUxXxphElw1b_X95P01COvBs-8Ds2yI0IoO7xMm$>
>
>
>
> · draft-kaliraj-idr-multinexthop-attribute-02.txt
>
> (
> https://datatracker.ietf.org/doc/draft-kaliraj-idr-multinexthop-attribute/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-kaliraj-idr-multinexthop-attribute/__;!!NEt6yMaO-gk!C87bEXrV_LFCIcFpo5LiwIGBHoFQmh1UrxDe2pwDL8Eo4XUxXxphElw1b_X95P01COvBs-8Ds2yI0KL8yFFZ$>)
>
>
>
>
> · draft-kaliraj-bess-bgp-sig-private-mpls-labels-04
>
> (
> https://datatracker.ietf.org/doc/draft-kaliraj-bess-bgp-sig-private-mpls-labels/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-kaliraj-bess-bgp-sig-private-mpls-labels/__;!!NEt6yMaO-gk!C87bEXrV_LFCIcFpo5LiwIGBHoFQmh1UrxDe2pwDL8Eo4XUxXxphElw1b_X95P01COvBs-8Ds2yI0JZWVrT_$>
> )
>
>
>
> You may discuss adoption of one or both the main drafts (CAR or
> Classful-Transport (CT)) in your response, and the associate drafts.
>
> A few caveats on your discussion:
>
> 1.      Please do not worry whether the drafts belong in BESS or IDR.
>
> Both BESS and IDR work on creating relevant quality standards in BGP,
>
> and the chairs will work this out.
>
>
>
> 2.      The IDR has spent time over 2020-2022 discussing these drafts.
>
> For background information, see the following links below.
>
> You can refer to these previous presentations or email discussions in your
> responses.
>
>
>
> 3.      Please constrain your discussion to whether these drafts should
> be adopted.
>
> I’ve started another email thread on whether path
> establishment/distribution
>
> for a color (aka QOS/SLA/Transport Class) should be done via a
>
> specific BGP route (i.e., per-color NLRI) rather than as per-color
> attributes on a route.
>
> https://mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/__;!!NEt6yMaO-gk!C87bEXrV_LFCIcFpo5LiwIGBHoFQmh1UrxDe2pwDL8Eo4XUxXxphElw1b_X95P01COvBs-8Ds2yI0GENGbTn$>
>
>
>
> Questions (to consider) for these drafts:
>
> Jeff Haas (IDR Co-chair) posted a summary on March 21, 2022 that for
>
> route resolution and route origination/propagation, BGP-CAR and BGP-CT are
> functionally identical,
>
> but operationally different.
>
>     (
> https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/__;!!NEt6yMaO-gk!C87bEXrV_LFCIcFpo5LiwIGBHoFQmh1UrxDe2pwDL8Eo4XUxXxphElw1b_X95P01COvBs-8Ds2yI0Ae3EviX$>
>
> 1.      Do you agree or disagree that these two drafts are functionally
> identical?
>
> 2.      If you agree, should we have just one draft or do the operational
> difference encourage us to have two drafts?
>
> 3.      If you disagree, do the functional differences encourage us to
> have one or two drafts adopted?
>
>
>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!C87bEXrV_LFCIcFpo5LiwIGBHoFQmh1UrxDe2pwDL8Eo4XUxXxphElw1b_X95P01COvBs-8Ds2yI0Bl4xAAu$>
>
>
> Juniper Business Use Only
>