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

[Stefano Salsano <[e-mail]>]

Hi,

I support the adoption of draft-dskc-bess-bgp-car-05.txt

I have been working on SRv6 standardization and implementation, the BGP 
CAR solution nicely addresses the interoperability with multiple 
trasports including SRv6

I think that there will be no gain in adopting another solution that 
basically supports the same functionality, so I support the adoption of 
one draft only

Stefano


Il 2022-07-19 11:46, [e-mail] ha scritto:
> 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-planes/<https://datatracker.ietf.org/doc/draft-kaliraj-idr-bgp-classful-transport-planes/>) 
> 
> 
> 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-labels/<https://datatracker.ietf.org/doc/draft-kaliraj-bess-bgp-sig-private-mpls-labels/>)
> 
> 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://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? 
> 
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr


-- 
*******************************************************************
Stefano Salsano
Professore Associato
Dipartimento Ingegneria Elettronica
Universita' di Roma Tor Vergata
Viale Politecnico, 1 - 00133 Roma - ITALY

http://netgroup.uniroma2.it/Stefano_Salsano/

E-mail  : [e-mail]
Cell.   : [phone]
Office  : (Tel.) [phone] (Fax.) [phone]
*******************************************************************