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

[Antonio Cianfrani <[e-mail]>]

Dear WG,
I support the adoption of BGP CAR draft (draft-dskc-bess-bgp-car-05) since
it is based on the same routing model of BGP for IP routing, enhancing it
with color extension, and it works seamlessly across traditional networks.
Moreover, SRv6 is used (or it is planned to be used) by many network
operators and CAR provides BGP to efficiently support multiple transport
solutions.

I don't support the adoption of BGP Classful Transport Planes draft
(draft-kaliraj-idr-bgp-classful-transport-planes-17) since it solves
similar use cases with lower efficiency than BGP CAR solution, due to its
VPN-based mechanism.

Regards,
Antonio Cianfrani

Il giorno mar 19 lug 2022 alle ore 12:14 Stefano Salsano <
[e-mail]> ha scritto:

> 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]
> *******************************************************************
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>

-- 
**Fai crescere le giovani ricercatrici e i giovani ricercatori*

**con il 5 
per mille alla Sapienza
*Scrivi il codice fiscale dell'Università 
*80209930587
Cinque per mille <https://www.uniroma1.it/it/node/23149>*