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

["Swadesh Agrawal (swaagraw)" <[e-mail]>]

Hi Sue,
I support adoption of BGP CAR (draft-dskc-bess-bgp-car-05.txt ) as a co-author and oppose adoption of BGP CT for the protocol reasons already listed by Dhananjaya Rao on the list https://mailarchive.ietf.org/arch/msg/idr/R-ockSQHvDojiaEu__OgLBdOxBk/
In addition to reasons listed by Dhananjaya, following points are important to consider:

  1.  BGP CT proposes RTC for constraint distribution. RTC filters on RT and thus need to carry PE address based RT in CT route. This means same PE address is carried in 2 places i.e. NLRI (RD:PE address) and Route Target: PE:TC. This breaks BGP packing completely. Each bgp update can carry only single CT route. For large scale networks where transport route scale is number of intents multiplied by PEs, it’s a nonstarter.
  2.  Also need to note that RTC for service layer is currently static in nature. But RTC in transport is based on service routes advertisement and withdrawal and very dynamic. Need to evaluate impact of such dynamicity on RTC safi and transport plane CT safi relying on it
  3.  CT claim of advantage of using proven existing MPLS VPN procedure and better ROI have no ground. Scale aspects of CT are based on completely new procedures defined in “BGP signalled MPLS-namespaces”. It introduces new Private(VPN) label SAFI, additional complexity on RR to allocate VPN labels and download from RRs to ABR in new SAFI. These are unproven methods and need to be vetted by WG. It make take years to have any CT scalable solution. BGP CAR provides existing hierarchical methods to scale and hardware analysis.
  4.  Similar claim for ROI fails when statements by CT authors make refence to “draft-kaliraj-idr-multinexthop-attribute-02.txt”. It is also individual draft which is unproven. How can multi-nexthop be response to carry per-prefix information?
Further to your questions

  1.  Do you agree or disagree that these two drafts are functionally identical? Agree but CT is based on workarounds to even provide base multipath/protection which has implications.
  2.  If you agree, should we have just one draft or do the operational difference encourage us to have two drafts?  Just need one draft. Support BGP CAR for protocol, scale and operational similarity to BGP LU.
  3.  If you disagree, do the functional differences encourage us to have one or two drafts adopted?

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

  *   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?