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

[Natrajan Venkataraman <[e-mail]>]

Hi Susan,

As a co-author, 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/)

I DO NOT support the adoption of BGP-CAR for the same reasons
that Kaliraj has pointed out below, and I am in total agreement
with that.

I wouldn’t want our customers to go through the pains of
deploying BGP-CAR (in any shape or form) anywhere in their network.

As a developer, I am strongly against using the BGP NLRI keys and fields
as a dumping ground (learning from other BGP families that did the same),
implementing brand-new untested procedures for BGP-CAR, spend a lifetime
of solving complex issues, customer escalations, security considerations,
malformed TLVs, incomplete use-case handling, patch work for unsupported
use cases and suggesting meaningless workarounds to customers.

I would rather use my time to develop customer requested features
that enhance BGP-CT further, which reuses time-tested procedures and
easily interoperates with other BGP features seamlessly, easy to deploy
alongside BGP-LU, has multidimensional ECMP, scaling and protection
aspects that tie in the same way as BGP LU and last but not the least,
save time, money and frustration for both our customers and myself.

Cheers,
-Nats-

From: Kaliraj Vairavakkalai <[e-mail]>
Date: Friday, July 8, 2022 at 10:11 AM
To: Susan Hares <[e-mail]>, [e-mail] <[e-mail]>
Cc: Natrajan Venkataraman <[e-mail]>, Reshma Das <[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.



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



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



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



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



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

As against CT working with existing mechanisms like RTC.



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



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.

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


Juniper Business Use Only