Re: [Idr] Questions/concerns about BGP Color-Aware Routing (CAR)

[Srihari Sangli <[e-mail]>]

Hello,

I am not sure if my email reached the authors and hence resending my email. I would like to know the comments from the authors of draft-dskc-bess-bgp-car draft. Thanks.

Thanks & Regards,

srihari…


From: Srihari Sangli <[e-mail]>
Date: Thursday, 18 November 2021 at 1:06 PM
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Questions/concerns about BGP Color-Aware Routing (CAR)


Hi, Folks:



This is regarding draft-dskc-bess-bgp-car-03 . I have reviewed the previous presentations & discussions on IDR wg meetings and mailer. In preparation for the upcoming IDR interim, I am raising concerns about CAR proposal to establish end-to-end intent-aware paths. Can the authors of the draft respond to these.



IMO BGP CAR is an overkill for what we need.  Some of the proposed changes in CAR proposal look to me as pretty fundamental to BGP. While “any” protocol extensions are possible, IMHO we should review the trade-offs. I see the CAR authors are trying to solve the same problem that BGP Classful Transports aka BGP-CT solves in a different way. My objection is – while we want to provide alternative solution to classful transports, we don’t want to take BGP protocol constructs to orthogonal direction which is not good for both operators and vendors.



Personally, when I compare BGP CAR to BGP-CT, the BGP-CT is a natural extension of existing IP-VPN mechanism. I have not seen much discussion on what’s missing in BGP-CT and I’m sure more discussions may lead to improvements (if any) in that proposal.  I propose we review BGP CT proposal and provide suggestions to improve it. It seems better bang for buck than introducing new concepts in BGP which seems suboptimal and complexity from protocol extensions.



Following is the list comments/objections (not a complete list) to the CAR proposal. Please see below for more details.



1.       Color ambiguity: As per details in section 2.9.3 and 2.8 of the draft, the color represents the intent within the color domain (which can span across IGP/AS domains) and as authors describe it, it is under a common administration. I have following observations and objections related to this.

·         The intent is present in two places : NLRI and attribute. This leads confusion as to which one to believe.

·         Even though we achieve some mapping across domains under common “color” administration,

·         For CAR NLRIs with LCM, implementation can become complicated to deal with color present in NLRI and color present in LCM, the effective color can vary from prefix to prefix and this may end up inefficient data storage and prefix management.

·         It also adds operational complexity for troubleshooting to trace the routes and color across hops, multiple RRs and different domains. The operator has to track the effective color, sometimes it will be the color in the NLRI, and sometimes it may be in LCM, and it has to be tracked on a hop by hop basis along the multi-domain path – thus making it impractical or very difficult to track prefix and its effective color.

·         One may end up with routes as below. These are two different prefixes as the color is different. But LCM makes them comparable. So can they be considered as multipaths ? Can either of the paths be used for route resolution ?  If one has to be preferred over other route, what is the selection criteria and why. The draft does not provide details:
Route1: Prefix:1.1.1.1, Color 100; attribute local-pref 10
Route2: Prefix:1.1.1.1, Color 200; attribute LCM 100, local-pref 20

·         With ADD-PATH, multiple paths for the prefix {E,C} get advertised, but the identity of the originator of the route will be lost. For troubleshooting, it may be very useful to know who originated the route, especially with color mapping across domains.

2.       CAR NLRI encoding: In section 2.9 of the 03 version, the non-key fields can have “Transitive” bit. This is going towards the attribute definition way. While this may be a good idea to provide key and non-key structure for managing prefixes, I am not sure if the added complexity would be justified.

·         This is going towards a mode where NLRI can become very big with many objects can exist within NLRI as non-key fields. This may also lead to more discussions when a new object is introduced as to should it be in attribute-only or as non-key field only in NLRI or both, leading to interoperable issues and misinterpretations. IMHO the use case does not mandate or lead to such a big change in NLRI encoding.

·         I understand that moving label from prefix SID to the NLRI may improve packing, but it is not clear if there is a definite gain.  Even if there is some gain, the number of labeled routes in any network would be relatively small thus making gain insignificant. We know that operators attach communities to NLRIs that may bring in uniqueness, so you may be optimizing for a non-practical use case. I feel this is an academic exercise. The Prefix-SID has been standardized at IDR (rfc8669) and has been deployed in many networks already.  I have not seen discussions on NLRI packing as an issue raised by any operator. Also, I’m not convinced if it is worth going through protocol modifications and implementations across networks, as the so called “packing issue” will continue to exist until old implementations are around. We should not have coded prefix-sid as an attribute IMHO, but it is too late now. Associating label/prefix-SID with next hop is a better way to solve that problem. There is already a draft (draft-kaliraj-idr-multinexthop-attribute). Its worthwhile to look into that.

·         If an operator wishes to attach a community or some identifier to uniquely identify the point of origination of such a color prefix, then packing advantage is lost unless we bring that “attribute” into NLRI as a non-key. This is going to add more complexity.

3.       Path compression: This happens at aggregation/pinch points. Section 2.7 of the draft describes the path availability by proposing add-path. I agree add-path gives the path diversity, but it also has negative effect.

·         ADD-PATH is a router by router feature. It has to be enabled pervasive across networks. We all know that ADD-PATH can be pretty expensive from memory and processing perspective. Not to mention the troubleshooting overhead by tracking path-ids. ADD-PATH is a good feature to avoid route oscillations when it was proposed, but using it for more use cases will be costly for the network. Operators with BGP-LU are painfully aware of this and are careful to turn on ADD-PATH in their networks for this exact reason.

·         ADD-PATH  has been tried and deployed at RR and primarily iBGP peering. We tried solving it for EBGP with edge_discriminator attribute and we do not have deployment experience of this working at inter-AS boundaries.

4.       Forwarding diversity: Section 2.9.2.1 describes how a label TLV can be encoded in the CAR NLRI but the draft does not address the following scenario

·         It is not possible for a router to express different forwarding paths/encapsulations for a CAR NLRI. This can be useful in inter-AS scenarios when you want to expose the diverse paths across domains.
NLRI: 1.1.1.1, color C1, label L1
NLRI: 1.1.1.1, color C1, label L2

5.       Color based resolution: Section 2.5 introduces how CAR route can be resolved, but I’m not too sure if the authors have worked out the details of the scheme.

·         For example if a router has the following routes, cost of computing the best path is not trivial. It is also not intuitive. Implementation wise, this can be inefficient walk all routing information. Either there is a CPU or memory cost to this way of color mapping.
NLRI:1.1.1.1 color 100, attribute local-pref 100
NLRI2: 1.1.1.1 color 200, LCM 100, attribute local-pref 200
NLRI3: 1.1.1.1 color 300, attribute local-pref 300
NLRI4: 1.1.1.1 color 400, attribute LCM 100, local-pref 400

·         Operationally this may be difficult for operator too.

6.       VPN CAR: This may be an interesting concept about extending the color to CE.

·         But, is this requirement real ?

·         The draft proposes replacement of L3vpn family & ipv4-unicast which is the de facto for PE-CE protocol with CAR NLRI. This will bring in operational nightmare.

·         I’ve raised concerns with LCM above and it adds even more complexity when such intent/color is extended to CE routes IMHO from deployment, troubleshooting perspective.

7.       RTC mechanism:

·         In the CAR proposal color is encoded in the NLRI and hence the current RTC mechanism cannot be leveraged. I understand that LCM would not be present for all CAR NLRIs and hence a new mechanism needs to be devised to cover NLRI with and without LCM.

I appreciate comments from the authors and others on this topic.

Thanks & Regards,

srihari…



Juniper Business Use Only