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

["Satya Mohanty (satyamoh)" <[e-mail]>]

Hi Susan,

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

[SM] Yes, the two drafts are functionally very identical. They address the same problems.



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



[SM] I believe it is better to have one draft. Below are some of my observations.

  *   BGP CAR model is very similar on the widely deployed BGP LU model of  “underlay” connectivity. This is opposed to CT that imposes VPN like semantics in the under-lay. CT has an implementation and provisioning issue that the same intent (ECMP) but from two unique origin-points (anycast/multi-homing) need unique NLRIs (two different Route Distinguishers). They need to be brought together at an ABR and then advertised upstream. Question is which RD to choose or whether to assign a new RD? Bringing routes together (via import) operation involves some work and therefore designating a new RD with possible new net and path (although this is really implementation dependent). In CAR this all already accounted for as it follows the LU paradigm, same net resulting in two different paths.
  *   In CAR Convergence is addressed naturally as both paths can be programmed in the forwarding as ECMP/PIC as may be the case. If both next-hops need to be communicated upstream, add-path can easily be applicable.
  *   Semantics of clean separation of contiguous key elements and non-key elements with explicitly specified lengths makes CAR very extensible and requires no RR upgrades. IMO, this addresses a historical fault inherent in typed-NLRI SAFIs like EVPN wherein with any new route-type addition it is a pain to upgrade the RRs.  .
  *   Recursive-Resolution can easily be done with one color-aware route resolving over another color-aware route and other in fact other routes viz. learnt via SR policy, IGP Flex-algo, BGP-LU etc. [I realize that CT also has the desired handling here].
  *   There are other points already discussed in the mailing lists by others.


  1.  If you disagree, do the functional differences encourage us to have one or two drafts adopted?

[SM] Although functional differences are small, it is not clear to me how implementations based on respective drafts will inter-operate. Therefore, I will go with the CAR.

Best Regards,
--Satya

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

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