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

[Susan Hares <[e-mail]>]

Swadesh, Kaliraj and Gyan:
Please be aware that the IDR chairs still believe the analysis by Jeff Haas is correct - that these two proposals are functionally identical but operationally different.
I will start a new mail thread (Q3) for the CAR-CT adoption poll to discuss the operational differences of the two proposals.
I ask the authors and IDR members to await my post on Thursday 7/14 to pick up this discussion on operational differences.
Since Swadesh is pointing to BGP CT authors as making incorrect statements,  as a chair I need to indicate:

  *   Where Swadesh makes a valid point (1 or 2 points)
  *   Where the technologies could be view either way (most of the points).
Since Swadesh directly challenged veracity of the CAR-CT authors,  IETF procedures suggests I deal with it directly.  I feel both author groups are acting appropriately and passionately about their technology.  Please ask me clarifying questions, but IDR and CAR-CT authors should move the discussion of operations differences on the Q3 mail thread.
I feel the issues raised in this to email threads point to operational differences should be discussion on the CAR-DT Mail thread 3 (Q3): operational differences.

  *   define your use case and topology
  *   if you are discussing the other authors work give a specific section and a specific use case, and
  *   avoid general summation statements (these belonged on the 1st post for Adoption mail thread Q2), and
  *   consider that the majority of IDR people who have replied want an interoperable solution.
A big thanks to the draft authors and IDR WG members for their active discussion.
Sue
From: Swadesh Agrawal (swaagraw) <[e-mail]>
Sent: Tuesday, July 12, 2022 8:46 AM
To: Kaliraj Vairavakkalai <kaliraj=[e-mail]>; Susan Hares <[e-mail]>; [e-mail]
Subject: 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

BGP CT authors keep making incorrect claims about CAR. Even after multiple rebuttal, I see same pattern in below mail. For each point I am adding my response with [SA] and earlier discussion on list f
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzRmZjMwYTMxMWNlNTdlMTJhOGYxYzFiN2Q2Y2YxMTI5LzE2NTc2Mjk5NTcuMTQ=#key=ce635781d1e23724c7f007dbe1102339>  FAQ<https://www.inky.com/banner-faq>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>

BGP CT authors keep making incorrect claims about CAR. Even after multiple rebuttal, I see same pattern in below mail. For each point I am adding my response with [SA] and earlier discussion on list for reference.
Regards
Swadesh
From: Idr <[e-mail]<mailto:[e-mail]>> on behalf of Kaliraj Vairavakkalai <kaliraj=[e-mail]<mailto:kaliraj=[e-mail]>>
Date: Friday, July 8, 2022 at 10:42 PM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: 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

Hi Sue,
As one of the authors, I support adoption of the BGP-CT draft:

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

(https://datatracker.ietf.org/doc/draft-kaliraj-idr-bgp-classful-transport-planes/<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxFj0tPg0AUhf-KJS6F6UCHR910IYmttk1Nq4YNuZ0HIMMjM1MpGP-7YExcnvvlfjnny7ooaS1vrNyYVi8RGiPjgteaO7Sp0KeH0vSPMTBgFNCSK6fgRjiNyhBrKGIKhLFLkIWCD7tgyj5nrU0laC0u0h5_at02ytithJrr0Xg_m-1i4_db2NtZOXvwn9wkTnZyI2V82lfNkHbkMc2yrocq7itvWJ8hey7fjifyEl7zDWlMt72SdRJf5HF4T8L8dC3UNgn6V_9wuLXubqxyWlVzM5bEcxL6EXaRzkFxvarZkP-uWwjhzcHDmHIScOxCKDDF54D5VGDsRgj7JPDdKCKBgxeTlU9W3QFkCroVLTRtJtOE2IT-L98_sixyWA.MEQCIGzkNKZPErr5mV_mrl_71cHKKY29b9nZTJkAq3Q7vVK4AiAWyxLfOgvSEGDimSxu84UaKt-Gzl6FUAaBQHg2-1KMYg>)

I don’t support adoption of CAR draft (draft-dskc-bess-bgp-car-05.txt), for the following reasons:


  *   CAR has made basic assumptions about scenarios like ‘non agreeing color-domains’

and ‘multihoming’ being corner-cases, and don’t handle them well. As we can

see from operator feedback, these assumptions are incorrect. IMHO, any new

mechanisms should cater to all perceivable scenarios without making such assumptions.
[SA] This is an incorrect claim by CT authors. Color is a BGP construct to represent intent. We expect an administrative domain (under single administrator) to converge on such mapping. CAR NLRI is optimized for it(multipath/protection/keeping network churn within a domain). CAR supports multi-homing and multiple color domains (non agreeing color domains) with Color construct with help of LCM-EC. Please check sections https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-05#appendix-A.7<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJxFzEEOgjAQheGrmLq1LQOWCis8yjCdAkGBtDUYjXfXrty-P-97i0e4ifYgxpS22GrtMGEKSDMHNXHyag2DdivpMd1v2gX0Sbo4k-w5RtkPmyQMsjBH3DZe3PSUV2XF6SDmrC6cfn8ozKVuoNRxxMCxW9xrVLTe9dn7qsAKgNhYhhIvHgh662ryAGWjoTa2LpvGWAXnrHJW4444BNw7miKtWcrJ5fRfPl-bLkQy.MEUCIGfCI9UuLmT54Pn8fOYWYGGvi33llr939UZnIzuqdVs7AiEAglUcDqBaM9niRpMIhGurbS8VuVPQWJ0hKNU9Q5PQmVA> and https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-05#appendix-B<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJxFzMsOgjAQheFXIXVrKQOU24r4JsN0CgS5pK3BaHx37crt-XO-t3i4u-gSMYVw-E4pgwGDQ1rYpTMHm-5uVGYnNYX1roxDG6TxC8mBvZfDeEhCJzN9wePgzcxPeRPXRCzR3Dj83pDppmohV35Cx77fzGtKaV9VaW2RYQFArGuGHBsLBENtKrIAeaug0nWVt62uUyijylH1J-Lo8Oxp9rRHKSYT03_5fAErXEPO.MEUCIGLDPVHtcuPCayciC6VO7pJS8llgjAHHP4nFZUY6Ecu8AiEA9a3KJKsnHwq_DlUKc0XqbOOHxd2MSZ1XgYfYT54wOzM>. Please also refer to our earlier response on list https://mailarchive.ietf.org/arch/msg/idr/N_Mq--wyZTKj2Q5C8qoEzRutj8c/<https://shared.outlook.inky.com/link?domain=mailarchive.ietf.org&t=h.eJxFzL0OwiAYheFbMcy2nx9Kf5xMjJPRROPkYpBCobZFAW3UeO_K5HrenOdN7q4l8xHRIVz9HKDjpuVOaPOQqZFBpdbVEAfofA2mcrA9bW5JMjyPh3VDd2xZ3Ozqtb-HphBAxiNyiVwvw--IE1ZkJVLwmjvpF3310qmwHcyUmk74FFFIlkukvFAo8JxXmVCItATMWJ7RsmR5irOoyqj6gfPa8WEhjBc2SjFVMf2XzxdelkGL.MEYCIQCemWY9yg5EsQycsmKisg42Nyi6n4msPgdcNpSo3tqWbQIhAItlefxqtQjoKkB8JHxPFbF-DGAiL9sIlrJXCmwhID5H>

[Sue] : This is a valid push back. Kaliraj would have been better stating that the default scenarios targeted by CAR wasn't what he preferred.




  *   Carrying color in NLRI has problems, including inability to express

diverse paths to maximize network utilization, for Traffic-engineering.

Using RD allows for such use cases in BGP-CT. Besides, RD is a better

Disambiguator (even across network domains) than Addpath-ID (per session scope).
[SA] Not sure above statement is made on any facts. CAR supports diverse paths using Color. RD has many problems are already mentioned during interim and on list. RD makes a provider visible IP address opaque. It requires import/export VPN procedure to get even a base multipath/protection on routes learnt from 2 different originating ABRs. Different RD routes brought together by import, will allocate common local label for multipath/protection. Now problem arises which RD route are advertised upstream and if both are advertised they carry same label and create unnecessary states on all upstream hops. Such procedures which were meant for edge PEs in VPNs are now to be performed hop by hop on all ABRs and create such problems.
[Sue]: Here, Both Author-teams need go deeper during the discussion on Q3.

  *   The RD usage is per VPN procedures.  It is unclear what exact scenario is being defined.
  *   For this pro/con discussion (on Adoption call Q3), each author group needs to first layout the topology that their answer applies to.
  *   After defining your topology and asking if the author understanding the example, you can debate why your operational process is better.
Also please refer to Jeffs mail regarding the topic and functional similarity https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/<https://shared.outlook.inky.com/link?domain=mailarchive.ietf.org&t=h.eJxFzMkKwjAUheFXkayltze1qenKjcNKUBHB3TVDE2ytJHVA8d01K7fn53xvdgstq0fMDcM11gAd-ZaCcv5uMm8Gm_WhgTRAFxvwOoARcr3V0nNa5of9c3HeubndrI5x1QMbj9g5cRcz_I6Yl1MhkUN0FEycXfTLZarvYGJtkVOBqExZGeQ0tajwVGmhLCKXgKKsBJeyrDKcJNUkNT6ImkCPmfJR9UlKSaf0Xz5fL65BPQ.MEQCIFC-TLxUnn6586T8v9q5TCMbDQZuab1rclPSps-RvBtdAiA_pNKb3nCiqOXPi4Mi7c9pWPRNAysoAVcQ3KAtmizWzQ> and our response to same question raised earlier https://mailarchive.ietf.org/arch/msg/idr/0RUa-hJ1DNQ76dFfy9V0mgF8gOM/<https://shared.outlook.inky.com/link?domain=mailarchive.ietf.org&t=h.eJxFzE0PwUAUheG_IrOmt7d0pmNlIRYShIT9Nd-hKjNFEP-dWdmeN-d5s1s8s-mA-b6_pilAS-FMUflwN0UwvS266CAP0CYHQUcod3sa-SXO11vB9cI-5aFs3aJxmxWw4YCdMncx_e-IZd1wiRUkT9Gk2UW_fKG6FibWjksaIypTC4MVNRYVHoXmyiJWEpDXgldS1qLASVZNVtODyEV6zFRIqstSTjqn__L5AtEuQJY.MEQCIBbuqGiVcbSakrVkeMmuI5EbngKrdH9eAN0wtW6ld5nbAiBseHe_rnbEzNFtBNKvy-41dwO07PC0revYtUmlRiLD7w>

  *   The proposal of carrying non-key fields in BGP NLRI complicates code,

makes error handling tricky, and troubleshooting hard. It is also

wasteful to repeat forwarding-information (e.g. per-VRF label/SID) per

NLRI prefix instead of sharing it among all NLRIs, especially when

the forwarding-information is large like SRv6 SIDs.
[SA] BGP carries non key field in NLRI. Even CT carries it in form of hard coded VPN label. CAR just provides structure to it along with capability to carry more such prefix specific information to not break BGP packing. Reminder: forwarding information for transport case is per prefix. Hence labels, SIDs and label index are proposed to be in non key tlv and does not break BGP packing. CAR specifies non key as TLVs that are well known from code implementation and error handling point of view. We have multiple interoperating implementations for CAR SAFI. CT cannot carry SRv6 SIDs in NLRI as it has only VPN label space. It will break packing as would be required to carry it in attributes as information is per-prefix.

[Sue]:  The IDR chairs realize the CAR and CT proposals have different viewpoints on error handling, and what non-key forms do for IDR.
The chairs in Adoption Mail thread 1, ask the IDR WG for guidance.
https://mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/
Bruno’s comment on July 11, provides a nice summary of trade-off issues (see https://mailarchive.ietf.org/arch/msg/idr/AWPvdVinMmAgd7cPiaQ5aG2lUBc/)
[Sue’s opinion]  The non-key information complicating RFC 7606 procedures to find the NLRI in the stream is a concern to the me (and to my fellow IDR chairs).   IDR needs to understand the trade-offs and choices on error handling we working on.   Some of this is operational preference (and belongs on Adoption Mail thread 3).
[Sue] The IDR chairs felt operational choices for error handling ought to be based on the IDR WGs agreement on good trade-offs.


  *   The MPLS scaling method proposed by CAR puts additional load on edge devices which

may be low end legacy devices. They need to do recursive nexthop resolution,

push deep label-stacks, and support large number of ECMP nexthops. This does

not really solve the scaling problem.
[SA] CT proposes completely new and complex “BGP signaled private MPLS-labels” which is individual draft and has no deployment experience from operational and scale point of view. On other hand CAR draft evaluates different well known hierarchical scaling designs and based on use case/scale an option can be picked. CAR draft does not introduce any new requirement on legacy device for label stack and ECMP. It is similar to already deployed BGP LU from any device support point of view.

[Sue: This scaling discussion is an operational difference and needs more detail when stating “does not solve”.
To constructively discussion, go through the process of:

  1.  Start defining your topologies and use case – (you can/should refer to your document if topologies are there).
  2.  Discuss the operational pros/cons based on those topologies
  3.  Work out the issues with all topologies proposed.



  *   CAR proposes new set of families towards CE devices also, which is a major

hindrance in deployment. And re-invents existing mechanisms in new family.
[SA] CAR draft provides additional benefit of running color-aware routing between customer sites and orthogonal to transport CAR.  VPN CAR is a separate SAFI from transport – so maintain the same layer separation as VPNs and BGP-LU today. Further, there is no RD overloading so the PE implementation is simpler. It’s not hindrance but an additional capability.

[Sue: This is a valid difference of operational process.  Both authors groups should discuss these issues on Adoption Mail thread 3 using the process mentioned above.]




  *   CAR also proposes to re-invent filtering mechanisms using new route-types.

As against CT working with existing mechanisms like RTC.
[SA]  CAR filtering can always work on RTC but our analysis show RTC is not suited for transport use case. It was developed for VPNs. It also breaks packing for transport as it requires CT route to carry loopback address in NLRI as RD:PE and in route-target(attribute).

[Sue: Again, statements like “reinvent”, “always”, “not suited” – do not help the IDR WG discover the pros/cons of operational issues.

  *   If you speak about one of the drafts, please specify the reference in one of these two drafts.
  *   If you believe something works better in a topology, specify the topology.
  *   Give specifics scenarios and benefits.



  *   CAR uses brand new unproven procedures that will take time to mature, and incur

Operational and training cost to the industry. It seems an unnecessary cost,

given the procedures are not complete and not well thought through.
[SA] BGP CAR procedures are similar to BGP LU. Its IP prefix extended with color and simplest model with all benefits of BGP LU hop by hop routing, multipathing and network stability. Many large scale network has BGP LU experience.

[Sue: BGP-LU has known problems and known benefits.  All revisions to take BGP technology take time to mature.
  Discuss this on thread 3 with specific examples and give your pros/cons due to specific examples.]



Where-as BGP CT solves all these use-cases by adopting existing WG adopted

mechanisms (like RFC-4364, RFC-4684) at transport layer. BGP CT provides

better ROI for the efforts of the WGs.
[SA] CT is trying to retrofit service layer procedures required on PE edge to be executed on all transport hops. Unnecessary import/export complexity for transport prefixes at every hop which adds processing and memory cost. It makes global PE loopback address opaque by adding RD in NLRI and creates problem for faster convergence and network stability as churn is advertised to remote domains. These protocol aspects are already detailed on list by https://mailarchive.ietf.org/arch/msg/idr/R-ockSQHvDojiaEu__OgLBdOxBk/<https://shared.outlook.inky.com/link?domain=mailarchive.ietf.org&t=h.eJxFzEsOgjAUheGtmI6V6wUBYUSIJg5MiLoAc-0DKo-aFsVo3Lt25PT8Od-b3W3H8hlrxvHmcoCedEeWN_ohAy1HFRhbgx-gdzVoYeG4MLw9HXaPjblq2t7P56rel6J6li2w-Yy1nhvk-DviMl4nGYbgGrLSFYN4NQE3PayUipYUIXIZpxJDWivkeElFwhVimAEmcZqEWRanAa68Kr3qJqLa0lRw7bjxkk_Cp__y-QKhK0H6.MEQCIFsHCOy5rslXFGsW5RcCW0gZrnLfYpCJxU2w8GxqdCY2AiAoS-7xvVSRrSHHfCpbHIjbw4F-pAKHCjTVviYFIjBjsw>.

[Sue: It appears that both proposals have been deployed in networks which felt the retrofit costs were acceptable.  However, the

To save time and effort for all, I agree with the request from other WG members
to adopt only one approach (I propose BGP CT).

Thanks
Kaliraj
From: Idr <[e-mail]<mailto:[e-mail]>> on behalf of Susan Hares <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, July 6, 2022 at 11:17 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxFj0trg0AUhf9KlC6rk9GMj3STRYUmrQmUhBY3cp2XwSczkxgt_e-NpdDluR_345wv-6Jqe72wS2N6vUboHhkXvNXcpV2Drj7K8z_GwIBRQCuu3DM3wu2URKyjiCkQxmG6ok7BtXYK2TsU1P3zybL2iQnGFA6OrKzn4NXLkmxf7-o6OR2absoH8pJLOYzQJGPjT9sC5Fv1cTyR9-hW7khnhvRGtllyqY_TZxaVp9tZpX3ZXq47-mA_Luxqbt9ycy-DlyQKYuwhXYLietOyqfxdsRLCX4KPMeUk5NiDSGCKi5AFVGDsxQgHJAy8OCahi1ezlc9WPQBIBcOGnjXtZtOM2Iz-L98_qVdpQg.MEQCIFyMDcd4HtAVn_XWDrB77vTWE-S1zkobeZG1WkxjoFMyAiBrqXtf6KrzPr-TR3riHgMmgTNFJmmywUYgJrjPE-BPAQ>)

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

(https://datatracker.ietf.org/doc/draft-kaliraj-idr-bgp-classful-transport-planes/<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxFj0tPg0AUhf-KJS6F6UCHR910IYmttk1Nq4YNuZ0HIMMjM1MpGP-7YExcnvvlfjnny7ooaS1vrNyYVi8RGiPjgteaO7Sp0KeH0vSPMTBgFNCSK6fgRjiNyhBrKGIKhLFLkIWCD7tgyj5nrU0laC0u0h5_at02ytithJrr0Xg_m-1i4_db2NtZOXvwn9wkTnZyI2V82lfNkHbkMc2yrocq7itvWJ8hey7fjifyEl7zDWlMt72SdRJf5HF4T8L8dC3UNgn6V_9wuLXubqxyWlVzM5bEcxL6EXaRzkFxvarZkP-uWwjhzcHDmHIScOxCKDDF54D5VGDsRgj7JPDdKCKBgxeTlU9W3QFkCroVLTRtJtOE2IT-L98_sixyWA.MEQCIGzkNKZPErr5mV_mrl_71cHKKY29b9nZTJkAq3Q7vVK4AiAWyxLfOgvSEGDimSxu84UaKt-Gzl6FUAaBQHg2-1KMYg>)
The associated drafts may be useful in your consideration.
CAR:

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

https://datatracker.ietf.org/doc/<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxFjl1PgzAYhf_KIF4qXWEtMG92Ick2hRkD0XBDulI-wkdd6Syw-N-lxsTL8z5vnnNu5lW05nZlVlJ-DlsAlpizgvUDsyjvwJcDsuyP5UQSKQhtmLBqJguLixLknC4fj4YRBRJPITk9lI3xhJ_tNEij9ti2QXLq-JwptM_KUk2kC6bOmQ9nUr4073GC3ryxOiIuVTiiQxpc23j-SL0qGWsRXl6jeH9Rd-b9ymz0yp7JpRSukYd9aIOhIoINuz6fq9-1m6Jw1sSBkDLkMmgTr4AUnt0c0wJC2wcQIxfbvo9cC260lWnroAgpBVE7Wg-Ua5NGuUb_l-8f60BgQg.MEUCIQCluWwNL3YRQkhIqxqO-Gq4lWirvKvUw4YvxZ9nGOquPQIgH-14BYeZOqGz1m7bXFhfE9gFtAiV8LuHdJcrBKER9V8> draft-ietf-spring-segment-routing-policy/



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

https://datatracker.ietf.org/doc/<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxFjl1PgzAYhf_KIF4qXWEtMG92Ick2hRkD0XBDulI-wkdd6Syw-N-lxsTL8z5vnnNu5lW05nZlVlJ-DlsAlpizgvUDsyjvwJcDsuyP5UQSKQhtmLBqJguLixLknC4fj4YRBRJPITk9lI3xhJ_tNEij9ti2QXLq-JwptM_KUk2kC6bOmQ9nUr4073GC3ryxOiIuVTiiQxpc23j-SL0qGWsRXl6jeH9Rd-b9ymz0yp7JpRSukYd9aIOhIoINuz6fq9-1m6Jw1sSBkDLkMmgTr4AUnt0c0wJC2wcQIxfbvo9cC260lWnroAgpBVE7Wg-Ua5NGuUb_l-8f60BgQg.MEUCIQCluWwNL3YRQkhIqxqO-Gq4lWirvKvUw4YvxZ9nGOquPQIgH-14BYeZOqGz1m7bXFhfE9gFtAiV8LuHdJcrBKER9V8> 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://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxFj0tvgkAUhf-Kki4L44DDw25clERt1aTRtGVDLvPC8BgzMxbF9L8XmiZdnvvlfjnn7lx07SwmTmnt2SwQGiLjgreGe1Q16CtAef7HGFiwGmjFtXfiVnhKS8QURUyDsC4zFXULboxbyLNLQbtnrYqaN64Z_njDWzu4nqbTXWrD2xb2rqymz-GLn6XZrt7UdXrcN6rPO7LKpexu0KS3JujXBcjX6v1wJG_xtdwQZbvtlayz9FIf-o8sLo_Xk94WMF_Fn-rBeZw41bin5Xaoh2ckDhPsI1OC5mbZsr783TUXIphBgDHlJOLYh1hgiouIhVRg7CcIhyQK_SQhkYfno5WPVtMBSA3dkp4MVaNpRGxE_5fvH1mab8M.MEYCIQDNmk6CRBJ8K6QbT3oPVQzJ1YSwS82I42ZQg2joVvT4ZgIhAPpwpYXX3XAl4_S_RqSiXVBH_w4FDchWRuyPct23GWAM>
CT

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

https://datatracker.ietf.org/doc/draft-hegde-spring-mpls-seamless-sr/<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxFj11LwzAUhv_KVry0zdIu_Zg3Ay246TaQDaU3JUtO0tpPksx2Hf53WxG8e8_7wMN5b9ZFldZqZmXGtHqF0HhyEFBrcFhToS8Ppekf49RQoygrQDk5GOE0SiLeMMQVFcbOQHKwdavyWtpVW2pbA61K0GNQo-VhPt_Hxr_u6MGWxfzJf3GTONmX27KMT4eqGdKOPKdSdldaxdfKGzZnKl-L9-OJvIV9tiWN6XY92STxpTwOH0mYnfpc7R7b3v1c6DvrfmYV05IazPgYXpDQj7CLdEYV6HXNh-x30VIIb0E9jBmQALBLQ4EZPgfcZwJjN0LYJ4HvRhEJHLycrDBZdUepVLRbs1yzZjJNiE_ov_n-AZsKbcg.MEYCIQDiIBOt_kPtloSBckuJepFTaeXTZ1GJsSugCouN614bZAIhAKdjL2MuX9klYb1zgZso24Ltc3DMCWLSzJNWE93EzjEE>



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

(https://datatracker.ietf.org/doc/draft-kaliraj-idr-multinexthop-attribute/<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxFj0tPg0AYRf-KJS6F6UCHR910IYltbZuYNho25Os8YGRgmmEQivG_W4yJy3tPcnLvl9MZ5SzvnNLaS7tE6BYZF7xpuUd1jT4DlOd_jIEFa4BW3HiSW-FpUyCmKWIGhHUrUNLAhyuZcetOWdnwwZb64oK1Rp47y2-qx9lsn9rwuoODW1Szp3DrZ2m2Vxul0tOh1mPek-e8KPor1Om1Dsb1GYqX6u14Iq_xUG6Itv1uIOss7dRxfM_i8jRIs-u2Klvo9b3zcOdU052G29s6PCdxmGAftSUY3q4aNpa_txZCBHMIMKacRBz7EAtM8TliIRUY-wnCIYlCP0lI5OHFZOWTte0BCgP9isqW6sk0ITah_-b7B5UkcDc.MEUCIQDcZIBFinqMqqM7cNYXQeYayjWKZa61Y_n7by9huUPUwgIgQasnrd-6KAz8vEMs8RkCtRaNeQhUn2m4pvT9mRLmIzE>)



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

(https://datatracker.ietf.org/doc/draft-kaliraj-bess-bgp-sig-private-mpls-labels/<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxFj11vgjAYhf-Kkl2u1ILlw914MZLppssWzRZuyEtpC1KEtFWUZf99sizZ5TlP8uScL-eklbOYOKW1nVlgfIsFF_xouMvaBp99nGV_rAALVgOruXYrboXbaomLluFCg7CoBlVpOKCcG4Ny2SFTSdTp6gyWo6ZTBinIuTI34cN0uk1scN3AK5L19DF49tIk3aq1Usn-tWmHrKdPmZT9FZrk2vjDKgf5Un_s9vQ9upRr2tp-c6GrNDmp3fCZRuX-UumNjg5volvdOfcTpx5PHbm9bSQzGgUx8bApQXOzPBZD-XtuLoQ_A58QxmnIiQeRIIzkYREwQYgXYxLQMPDimIYumY9WPlpNDyA19EtWGdaOphEVI_pvvn8A-oNx3w.MEQCIFfo4cIWDuSvZ6yXOhdSFbW2x3frYWi4omQT5Z1dj00cAiAt8jKrQKf-ZPSr3XcHIcT2qakYdfPVBNu68zgXsvMbAQ>)


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/<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxFj11vgjAARf-Kkj1OSoEWcC8uk8WPqYmbzvBCaimFAXZpqwjL_vvssmSP957k5N4v6yxrazywCq0_1RiAW8xYzk6K2VQ04OKBNP1jDSlrImlRXphdMp3bQnJgCtAoDspMgudCLB1_pl67SG-DUuyDx6mzv-C59G-ah-FwHWvcrchmxKvhFC_dJE7W9aKu492mEX3aolnKeduRJu4ar58fCX-p3t92aBteiwUSul1d0TyJz_Vbf0jCYnct5Wr08XRop9WddT-wKnPlxPRtGXRQiCPoAlUQydTklPXF7yU_zz2HeBBShgIGXRLmkMJjkGGaQ-hGAGIUYDeKUGBD31iZsaqWEC5JO6GlosKYDMoM-m--fwAkZGwV.MEYCIQCZ5x-cv2JXgYYYb2V_z_tNk8JAY-nq1xlESq5L5805iwIhAIidtTdpaT1zmddgTq9_vQ8oDjumXRB-RJkY4FJ6uYT8>

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://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxFj1tvgjAAhf-Kkj1u1IIt4F58GPOyqdFJXHghtfTCADEtysXsv88uS_Z4zpd8OedmXVRhTQaWrOuzngBwjynj7KSZTasSXF2QJH-sJFlBFJXZldkZq7ldKQFMAUotQJYqwHCw3qVB5pDZ6BC1r_mHDPl2Hut5ddc8D4frsMbdimyeRD58wW9OHMbrYlkUYbQpqz5p0DwRoulIGXal2y-ORLznh32Edn4rl6iqm1WLFnF4Kfb9Z-zLqM3Uatl159nX9sF6HFi5uXJi9X0ZHCEfB9ABWhLF9PSU9vL30phzd0RcCClDHoMO8Tmk8OilmHIInQBAjDzsBAHybDg2VmasuiFEKNJMaaZpZUwGpQb9N98_kRVssw.MEYCIQDgeNKj73DKsH87pfxwPqrIY25J-QuopeW8o6LxPJ0IPwIhALzlw8CUs8ZSqf_a5754vyno-J04pCwSsX67Rfc_Uo7N>

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