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

[[e-mail]]

Hi Sue,

 

I support the adoption of BGP CAR.

The two proposals are too close from a functional perspective to justify two
solutions that would create more burden/complexity in the
industry/deployments. Then I have two oppose to WG adoption of BGP CT.

Speaking with my long experience of large network operations and
engineering, I find BGP CAR better because:

- it's more straightforward in term of operations: with BGP services on top
(which is the primary/only case), it becomes really similar to BGP services
over BGP LU that seamless MPLS networks are using today. It is also allowing
to reuse the same "autosteering" mechanism that SR-TE uses today (BGP
service route with color ext community C and NH E is steered over a
transport path that satisfies C and has an endpoint of E)

I don't see the point of introducing VPN like mechanism for transport. It
brings more confusion to me than helping the operations. 

 

- from a technical point of view:

- As the NLRI uses the same components as SR-TE policies, it integrates very
well with SR networks while at the same time still working with RSVP-TE or
any other technology. But the trend of the industry is towards Segment
Routing so this is good to design in such a way while keeping compatibility
with older technologies.

- BGP CAR learns lessons/mistakes from the past and provide a more flexible
encoding (supporting various dataplanes) while keeping packing efficiency.
While designing as legacy and repeat mistakes when we can do better ?

 

- I hear the arguments on the list about what's happening when there are
network interconnections with different administrations of colors. BGP CAR
addresses it through the use of LCM. While nobody can say that this scenario
cannot happen, people cannot say that this will be the norm. If the two
networks are under a completely different administration point of view,
likely there will not be a BGP CAR interco but rather a BGP service interco
like option A because of security/non-trust issues (even option B is
sometimes challenging because of security purposes). If networks are
interconnecting using BGP CAR, likely they trust each other and likely
belonging to the same company and there are a lot of cases where color usage
can be synchronized (company-wide network design guidelines.). Of course,
there are cases, where it's not possible (independent affiliates.) and this
is where LCM/color mapping can be used, but this makes it a corner case, not
the norm. So, it's good to have a very simple solution that doesn't use any
BGP community and that will address most of the cases, and "corner cases"
are addressed using LCM.

 

Brgds,

 

Stephane

 

From: Idr <[e-mail]> On Behalf Of Susan Hares
Sent: mercredi 6 juillet 2022 20:17
To: [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/>
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-p
lanes/>
https://datatracker.ietf.org/doc/draft-kaliraj-idr-bgp-classful-transport-pl
anes/) 

The associated drafts may be useful in your consideration. 

CAR:

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

 <https://datatracker.ietf.org/doc/> https://datatracker.ietf.org/doc/
draft-ietf-spring-segment-routing-policy/

 

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

 <https://datatracker.ietf.org/doc/> 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/
>
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/>
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/>
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-la
bels/>
https://datatracker.ietf.org/doc/draft-kaliraj-bess-bgp-sig-private-mpls-lab
els/)

 

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/

 

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://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?