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

[Jose Liste <[e-mail]>]

Hello Susan,

I support WG adoption of draft-dskc-bess-bgp-car.

As the WG embarks on the standardization of a new transport SAFI, it is
crucial to start with the right base solution. This includes applying the
lessons learnt from more that 20 years of deployment of its predecessor
(BGP-LU)  and avoiding shortcuts.

In my opinion, BGP-CAR brings the right solution to elevate BGP to provide
intent-aware inter-domain routing. Three key architectural advantages of
BGP-CAR include:

- BGP-CAR provides a natural evolution of BGP-LU that shares the same
operational and routing models of Seamless MPLS networks. BGP-CT's use of
VPN semantics for transport prefixes is overkill and unnecessary.

- BGP-CAR provides automated steering and resolution based on color
ext-communities applied to both service and transport routes. BGP-CT
unnecessarily introduces different mechanisms like mapping communities that
create operational overhead.

- BGP-CAR provides intent-aware multi-domain paths across one or more
encapsulation types (e.g.; MPLS and SRv6). Consider multi-domain networks
with domains of different encapsulation or even domains supporting multiple
encapsulations. BGP-CT proposal does not provide clarity on how to achieve
this and break away from an implicit assumption of MPLS encapsulation.

Now on to your questions:

 1.  Do you agree or disagree that these two drafts are functionally
identical?

I reviewed Jeff H. note and believe it to be accurate. Broadly speaking,
the proposals are functionally identical

 2.  If you agree, should we have just one draft or do the operational
difference encourage us to have two drafts?

I am of the opinion that both customers and networking vendors would
benefit from having a single solution to address a given problem/use case.
And my support goes for BGP-CAR

 3.  If you disagree, do the functional differences encourage us to have
one or two drafts adopted?
<n/a>

Thanks,
Jose


On Wed, Jul 20, 2022 at 12:48 PM Pablo Camarillo (pcamaril) <pcamaril=
[e-mail]> wrote:

> Hi all,
>
> I support the adoption of BGP-CAR.
>
> Also, I do not support the adoption of BGP-CT.
>
> > 1.- Do you agree or disagree that these two drafts are functionally
> identical?
>
> I agree they are functionally identical, but their design is completely
> different.
>
> As already argued by others, BGP-CT seems to be a more narrowed solution
> from extensibility point of view. Also, I’m not at ease using the VPN
> encoding for a BGP transport as proposed by BGP-CT.
>
> On the contrary, BGP CAR is a natural evolution of BGP LU with future
> extensibility. Hence my preference for BGP-CAR.
>
> > 2.- If you agree, should we have just one draft or do the operational
> difference encourage us to have two drafts?
>
> One draft.
>
> > 3.- If you disagree, do the functional differences encourage us to have
> one or two drafts adopted?
>
> n/a
>
> Thanks,
> Pablo.
>
>
>
>
>
> *From:* Idr <[e-mail]> *On Behalf Of *Susan Hares
> *Sent:* miércoles, 6 de julio de 2022 20:17
> *To:* [e-mail]
> *Subject:* [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
>
>
>
> 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
>