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

[Balaji Rajagopalan <[e-mail]>]

Hi Sue,
As a co-author of BGP-CT draft, I support its adoption.
>>Do you agree or disagree that these two drafts are functionally identical?
[Balaji] I think the drafts attempt to solve the same problem, namely extending service mapping across domains.
>>If you agree, should we have just one draft or do the operational difference encourage us to have two drafts?
[Balaji] I think having one draft will avoid duplication of effort and minimize interop issues.
>>If you disagree, do the functional differences encourage us to have one or two drafts adopted?
[Balaji] I’m inclined to having just one draft, and my preference would be BGP-CT. I prefer BGP-CT for the following reasons:

  1.  Mutable attributes such as colour are not stored in NLRI. Across admin domains, colours may need to be remapped. Overwriting an attribute in BGP is well-established procedure; overwriting a key is not.
  2.  I prefer RD to AddPath ID for the following reasons:
     *   RD lends itself better to troubleshooting than AddPath ID’s, since the originator sets it, and it remains the same across the entire path.
     *   RD is flexible enough that for cases like Anycast, where multiple paths are not desired, RD may be set to the same value across routers.
     *   I don’t believe that usage of RD and VPN-like mechanisms would lead to any noticeable overhead. These mechanisms have been shown to scale to millions of prefixes in the VPN world, and transport routes are usually a fraction in number.
     *   I also don’t believe that usage of RD affects end-to-end convergence. It, in fact, offers more flexibility in multi-path. With RD, a router has the liberty to do any one of the following:
·         Provide an upstream node with end-to-end visibility of a path by simply propagating the received NLRI with RD intact. This allows the receiving router to perform multipath as it wishes. It can choose any subset of the paths for multi-path.
·         Install a local multipath route for forwarding, and originate a single new route. This leaves the local router in control of multipath.
--
Balaji Rajagopalan


From: Idr <[e-mail]> on behalf of Susan Hares <[e-mail]>
Date: Wednesday, 6 July 2022 at 11:47 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
[External Email. Be cautious of content]

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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-dskc-bess-bgp-car/__;!!NEt6yMaO-gk!FhxPv_0Raoa-KbopkFqEjH87cT1dspWcRcuGFwJcfhKP01dWHEnM_rKPrJRoBvzEGskoXYubhRU8xA4$>)

  *   draft-kaliraj-idr-bgp-classful-transport-planes-17.txt

(https://datatracker.ietf.org/doc/draft-kaliraj-idr-bgp-classful-transport-planes/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-kaliraj-idr-bgp-classful-transport-planes/__;!!NEt6yMaO-gk!FhxPv_0Raoa-KbopkFqEjH87cT1dspWcRcuGFwJcfhKP01dWHEnM_rKPrJRoBvzEGskoXYubk53yi24$>)
The associated drafts may be useful in your consideration.
CAR:

  *   draft-ietf-spring-segment-routing-policy-22

https://datatracker.ietf.org/doc/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/__;!!NEt6yMaO-gk!FhxPv_0Raoa-KbopkFqEjH87cT1dspWcRcuGFwJcfhKP01dWHEnM_rKPrJRoBvzEGskoXYubCW3cLlw$> draft-ietf-spring-segment-routing-policy/



  *   draft-ietf-idr-segment-routing-te-policy-18

https://datatracker.ietf.org/doc/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/__;!!NEt6yMaO-gk!FhxPv_0Raoa-KbopkFqEjH87cT1dspWcRcuGFwJcfhKP01dWHEnM_rKPrJRoBvzEGskoXYubCW3cLlw$> 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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-dskc-bess-bgp-car-problem-statement/__;!!NEt6yMaO-gk!FhxPv_0Raoa-KbopkFqEjH87cT1dspWcRcuGFwJcfhKP01dWHEnM_rKPrJRoBvzEGskoXYubHjeUjd8$>
CT

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

https://datatracker.ietf.org/doc/draft-hegde-spring-mpls-seamless-sr/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hegde-spring-mpls-seamless-sr/__;!!NEt6yMaO-gk!FhxPv_0Raoa-KbopkFqEjH87cT1dspWcRcuGFwJcfhKP01dWHEnM_rKPrJRoBvzEGskoXYublhlUKfI$>



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

(https://datatracker.ietf.org/doc/draft-kaliraj-idr-multinexthop-attribute/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-kaliraj-idr-multinexthop-attribute/__;!!NEt6yMaO-gk!FhxPv_0Raoa-KbopkFqEjH87cT1dspWcRcuGFwJcfhKP01dWHEnM_rKPrJRoBvzEGskoXYubc5nj6jQ$>)



  *   draft-kaliraj-bess-bgp-sig-private-mpls-labels-04

(https://datatracker.ietf.org/doc/draft-kaliraj-bess-bgp-sig-private-mpls-labels/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-kaliraj-bess-bgp-sig-private-mpls-labels/__;!!NEt6yMaO-gk!FhxPv_0Raoa-KbopkFqEjH87cT1dspWcRcuGFwJcfhKP01dWHEnM_rKPrJRoBvzEGskoXYub_j1SRzI$>)


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/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/__;!!NEt6yMaO-gk!FhxPv_0Raoa-KbopkFqEjH87cT1dspWcRcuGFwJcfhKP01dWHEnM_rKPrJRoBvzEGskoXYubFy_wOKI$>

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/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/__;!!NEt6yMaO-gk!FhxPv_0Raoa-KbopkFqEjH87cT1dspWcRcuGFwJcfhKP01dWHEnM_rKPrJRoBvzEGskoXYub8lGSQxY$>

  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?




Juniper Business Use Only