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

[Robert Raszuk <[e-mail]>]

Kaliraj,

I am surprised that you say that:

"> CT utilize the existing VPN infrastructure,"

is a correct statement. It is not. Something that looks "similar" is not
the same.

Especially considering operational elements of VPN infrastructure within
any network.

Rgs,
R.


On Sun, Jul 17, 2022 at 9:44 AM Kaliraj Vairavakkalai <[e-mail]>
wrote:

> Robert, Aijun is correct.
>
>
>
> BGP-CT uses a new SAFI code-point, and re-uses VPN machinery (RFC-8277,
> RFC-4364).
>
>
>
> This has been described in the draft in following sections:
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transport-planes-17#section-7
>
>
>
>    The "Classful Transport" SAFI NLRI itself is encoded as specified in
>
>    https://tools.ietf.org/html/rfc8277#section-2 [RFC8277
> <https://datatracker.ietf.org/doc/html/rfc8277>].
>
>
>
>    When AFI/SAFI is 1/76, the Classful Transport NLRI Prefix consists of
>
>    an 8-byte RD followed by an IPv4 prefix.  When AFI/SAFI is 2/76, the
>
>    Classful Transport NLRI Prefix consists of an 8-byte RD followed by
>
>    an IPv6 prefix.
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transport-planes-17#section-9
>
>
>
>    SAFI 76 (Classful Transport) is an RFC8277 <https://datatracker.ietf.org/doc/html/rfc8277> encoded family that
>
>    carries transport prefixes in the NLRI, where the prefixes come from
>
>    the provider namespace and are contexualized into separate Transport
>
>    Route Databases using RFC4364 <https://datatracker.ietf.org/doc/html/rfc4364> procedures.
>
>
>
> This has also been demonstrated with a pcap output shown in following
> IETF-108 ppt (slide 6)
>
>
>
>
> https://datatracker.ietf.org/meeting/108/materials/slides-108-idr-bgp-classful-transport-planes-00.pdf
>
>
>
> You can see the BGP-CT update looks similar to L3VPN, except for the new
> SAFI-value, and new Route-target format code.
>
>
>
> These are the ‘straight facts’!
>
>
>
> Thanks
>
> Kaliraj
>
>
>
>
>
> *From: *Idr <[e-mail]> on behalf of Aijun Wang <
> [e-mail]>
> *Date: *Saturday, July 16, 2022 at 5:26 PM
> *To: *Robert Raszuk <[e-mail]>
> *Cc: *idr <[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
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi,Robert:
>
>
>
> OK. The more concrete description should be:
>
> CT add “RD” field to the RFC8277 encoding(BGP-LU) to make the encoding
> similar to the existing VPN prefixes encoding, while CAR put the color
> directly into the NLRI key.
>
>
>
> In my opinion, the service intent should be decoupled from the underlying
> transport class division. As discussed in the list, the service intent may
> be described as some combinations/preferences of the transport class.
>
> Should we slice the network in advance or on demand, and then steer the
> customer’s intent traffic on them?
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> On Jul 17, 2022, at 07:29, Robert Raszuk <[e-mail]> wrote:
>
> 
>
> Aijun,
>
>
>
> > CT utilize the existing VPN infrastructure,
>
>
>
> That is completely not true.
>
>
>
> Both solutions define new NLRIs and use new SAFI.
>
>
>
> Let's keep the facts straight.
>
>
>
> Thx,
> Robert.
>
>
>
>
>
>
>
> On Sun, Jul 17, 2022 at 1:21 AM Aijun Wang <[e-mail]>
> wrote:
>
> Hi, All:
>
>
>
> It seems that we need more additional comparisons based on the same use
> cases and topology that described in
> https://datatracker.ietf.org/doc/draft-hr-spring-intentaware-routing-using-color/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hr-spring-intentaware-routing-using-color/__;!!NEt6yMaO-gk!D_IrkzqOB860taEuBjySOQwUAZVSYhV_vGXrIesviGHst3h4BDP-HAU1cPenT-0c45aCE9md6V20xfOFvG_wHpGn$> to
> make better judgment on the selection of different approaches.
>
> As operator, we are glad to select one solution that can interoperable
> with other among the key vendors. I think this can also reduce the
> implementation efforts for the vendors to support both of them.
>
>
>
> Regarding to the current two approaches, the followings are my thoughts
> and concerns:
>
> 1) The key difference for CT and CAR is where to put the color/transport
> class/intention within the BGP encoding.
>
> CT utilize the existing VPN infrastructure, CAR design one new NLRI
> encoding.
>
> 2) Then CT can utilize some existing mechanism(RTC) to filter the unwanted
> colored route, but CAR need to invent some new tools to achieve the same
> goal.
>
> 3) CAR can be easily accepted/incorporated with the SR/SRv6 Policy,
> whereas CT can easily be understood with the wide deployed RD/RT based VPN
> services.
>
>
>
> There are also some others technical differences between these two
> approaches, but as operator we have concerns more on the deployment
> scalability, operation complexity and the pressure on the edge, transit and
> border routers.
>
> For example, if the transport class in CT can be triggered automatically
> based on the received service intent, it can certainly release the operator
> from tedious configuration.
>
> Let’s continue the comparison on the 3rd part of this adoption call that
> raised by Sue.
>
>
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!D_IrkzqOB860taEuBjySOQwUAZVSYhV_vGXrIesviGHst3h4BDP-HAU1cPenT-0c45aCE9md6V20xfOFvBN8W_hq$>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!D_IrkzqOB860taEuBjySOQwUAZVSYhV_vGXrIesviGHst3h4BDP-HAU1cPenT-0c45aCE9md6V20xfOFvBN8W_hq$>
>
>
> Juniper Business Use Only
>