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

["Mankamana Mishra (mankamis)" <[e-mail]>]

WG,
Support the adoption of draft-dskc-bess-bgp-car-05.txt and oppose the adoption of draft-kaliraj-idr-bgp-classful-transport-planes-17.txt.   Though many points discussed and documented at https://mailarchive.ietf.org/arch/msg/idr/4Sffm_AR-wW9_jEEn3UfPGBbG4U/ , some of the  reasons for my input are

  *   As WG we must have solution where future extension can be easy. In case of BGP CAR solution multiple transports including MPLS , SR-MPLS and SRv6 are supported natively. All of these transport are very well deployed or in process of deployment.  Native support provides flexibility to be able to deploy different transport without much impact where as CT solution supports only label encoding in the route NLRI. Addition of any other encap is not handled automatically.  This point does make BGP CAR as robust solution compare to CT.
  *   Operational simplicity :  BGP CAR being similar to BGP-LU in its operational model, its preserving the BGP-LU simplicity .

I am also aware of BGP CAR implementation by multiple vendors including cisco .

Mankamana

From: Idr <[e-mail]> on behalf of Susan Hares <[e-mail]>
Date: Wednesday, July 6, 2022 at 11:16 AM
To: [e-mail] <[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:

  1.  draft-dskc-bess-bgp-car-05.txt

(https://datatracker.ietf.org/doc/draft-dskc-bess-bgp-car/)

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

  1.  draft-ietf-spring-segment-routing-policy-22

https://datatracker.ietf.org/doc/ draft-ietf-spring-segment-routing-policy/



  1.  draft-ietf-idr-segment-routing-te-policy-18

https://datatracker.ietf.org/doc/ draft-ietf-idr-segment-routing-te-policy/



  1.  draft-dskc-bess-bgp-car-problem-statement-05.txt

https://datatracker.ietf.org/doc/draft-dskc-bess-bgp-car-problem-statement/
CT

  1.  draft-hegde-spring-mpls-seamless-sr-06.txt

https://datatracker.ietf.org/doc/draft-hegde-spring-mpls-seamless-sr/



  1.  draft-kaliraj-idr-multinexthop-attribute-02.txt

(https://datatracker.ietf.org/doc/draft-kaliraj-idr-multinexthop-attribute/)



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



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/

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?