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

[Aijun Wang <[e-mail]>]

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