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 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/
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.

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.

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.

   1. 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.

   1. 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/
[B] The discussion here is also related:
https://mailarchive.ietf.org/arch/msg/idr/gRMxFd7R5HnIscR-Lqi6aDspf84/

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/)
>
>    - draft-kaliraj-idr-bgp-classful-transport-planes-17.txt
>
> (
> https://datatracker.ietf.org/doc/draft-kaliraj-idr-bgp-classful-transport-planes/)
>
>
> The associated drafts may be useful in your consideration.
>
> CAR:
>
>    - draft-ietf-spring-segment-routing-policy-22
>
> https://datatracker.ietf.org/doc/
> draft-ietf-spring-segment-routing-policy/
>
>
>
>    - draft-ietf-idr-segment-routing-te-policy-18
>
> https://datatracker.ietf.org/doc/
> 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/
>
> CT
>
>    - draft-hegde-spring-mpls-seamless-sr-06.txt
>
> https://datatracker.ietf.org/doc/draft-hegde-spring-mpls-seamless-sr/
>
>
>
>    - draft-kaliraj-idr-multinexthop-attribute-02.txt
>
> (
> https://datatracker.ietf.org/doc/draft-kaliraj-idr-multinexthop-attribute/)
>
>
>
>
>    - draft-kaliraj-bess-bgp-sig-private-mpls-labels-04
>
> (
> https://datatracker.ietf.org/doc/draft-kaliraj-bess-bgp-sig-private-mpls-labels/
> )
>
>
>
> 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.
>
>
>
>    1. 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.
>
>
>
>    1. 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/
>
>
>
> 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/
>
>    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
>