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

[Srihari Sangli <[e-mail]>]

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.

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]<mailto:[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]<mailto:[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