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]>]

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]> on behalf of Kaliraj Vairavakkalai <kaliraj=[e-mail]>
Date: Friday, July 8, 2022 at 10:42 PM
To: Susan Hares <[e-mail]>, "[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

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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-kaliraj-idr-bgp-classful-transport-planes/__;!!NEt6yMaO-gk!D6K2ZEZNlJllEUOmoz_w5H_ggwyamEym3zIbagLkWTU5R8xhJ5otwMx5IZEulTzXZ8hUxirMZ7yV6QQ$>)

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 and https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-05#appendix-B. Please also refer to our earlier response on list https://mailarchive.ietf.org/arch/msg/idr/N_Mq--wyZTKj2Q5C8qoEzRutj8c/



  *   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.
Also please refer to Jeffs mail regarding the topic and functional similarity https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/ and our response to same question raised earlier https://mailarchive.ietf.org/arch/msg/idr/0RUa-hJ1DNQ76dFfy9V0mgF8gOM/

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


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



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



  *   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).



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



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

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]> on behalf of Susan Hares <[e-mail]>
Date: Wednesday, July 6, 2022 at 11:17 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
[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!D6K2ZEZNlJllEUOmoz_w5H_ggwyamEym3zIbagLkWTU5R8xhJ5otwMx5IZEulTzXZ8hUxirMphnuvJc$>)

·         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!D6K2ZEZNlJllEUOmoz_w5H_ggwyamEym3zIbagLkWTU5R8xhJ5otwMx5IZEulTzXZ8hUxirMZ7yV6QQ$>)
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!D6K2ZEZNlJllEUOmoz_w5H_ggwyamEym3zIbagLkWTU5R8xhJ5otwMx5IZEulTzXZ8hUxirMqPNTHqw$> 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!D6K2ZEZNlJllEUOmoz_w5H_ggwyamEym3zIbagLkWTU5R8xhJ5otwMx5IZEulTzXZ8hUxirMqPNTHqw$> 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!D6K2ZEZNlJllEUOmoz_w5H_ggwyamEym3zIbagLkWTU5R8xhJ5otwMx5IZEulTzXZ8hUxirMba4H8Yo$>
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!D6K2ZEZNlJllEUOmoz_w5H_ggwyamEym3zIbagLkWTU5R8xhJ5otwMx5IZEulTzXZ8hUxirMCpx2j0s$>



·         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!D6K2ZEZNlJllEUOmoz_w5H_ggwyamEym3zIbagLkWTU5R8xhJ5otwMx5IZEulTzXZ8hUxirMuKlZ4oI$>)



·         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!D6K2ZEZNlJllEUOmoz_w5H_ggwyamEym3zIbagLkWTU5R8xhJ5otwMx5IZEulTzXZ8hUxirMr8jQfpI$>)


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

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!D6K2ZEZNlJllEUOmoz_w5H_ggwyamEym3zIbagLkWTU5R8xhJ5otwMx5IZEulTzXZ8hUxirMJyypGjQ$>

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