Re: [Idr] Comments, review of - draft-dskc-bess-bgp-car-01 presentation

[Kaliraj Vairavakkalai <[e-mail]>]

Hi Dhananjaya,

The limitations you mention below does not exist when using RD. Let me explain:

RD is an ‘identifier of convenience’. Which means:

  *   We use it to avoid path-hiding during BGP route propagation, and to identify the originator uniquely across the domain.
  *   And we can strip it when not required (in the transport-RIBs where they are imported to), so that we can
     *   Do path-selection across IP-prefixes after stripping the RD, in order to find the ECMP or alternate-paths, for PIC like scenarios. And
     *   Use the IP-prefix as the key for label-allocation, such that any churn stays local.


So the limitations you note below do not exist when using RD. This is also explained in the CT draft. ( https://tools.ietf.org/html/draft-kaliraj-idr-bgp-classful-transport-planes-07#page-13 )
Also, such usage of RD is nothing new; e.g. it is common for BGP-VPN implementations to strip RD and do path-selection on IP-prefixes in the VRF.

Using RT to populate transport-RIBs on the BNs nicely organizes the colored transport-RIBs with transport-endpoints, our experience so far shows it is nice for troubleshooting and analytics, among other things.

About precedence of mixing key and non-key values in NLRI, I’ll let the WG decide whether we should avoid going further in that direction. I was just noting that I think we should avoid adding more non-key fields to NLRI. How much update-packing we may get in the real world by doing such micro-optimizations is questionable; considering the routes may contain distinct communities used to identify the originating-region and other such operator policies.

Thanks
Kaliraj
From: Dhananjaya Rao (dhrao) <[e-mail]>
Date: Thursday, March 25, 2021 at 1:11 PM
To: Kaliraj Vairavakkalai <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Idr] Comments, review of - draft-dskc-bess-bgp-car-01 presentation
[External Email. Be cautious of content]

Hi Kaliraj,

Thank you for reviewing the BGP CAR draft and your comments. I am top posting my responses for better readability since the comments were quite long ☺

1.
BGP CAR extends existing BGP-LU flat hop-by-hop routing semantics by adding color-awareness to the NLRI. This approach addresses the requirement for diverse color-aware paths using the simplest and most efficient design.

We find this simplicity beneficial both for an implementation and more importantly for deployment.

2.
We don’t see a need for using L3VPN semantics with RD/RT and import/export at every underlay hop.

While using RD may have been a convenience as you stated, it brings unnecessary complexity and limitations.

A good example is the inability to achieve multipathing at an ingress BR (e.g., ABR3) within the local domain when two egress ABRs originate BGP routes for a PE with different RDs. This leads to slower traffic convergence since an egress ABR failure (e.g., ABR1) will need to be propagated across the domains all the way to an ingress PE before that path stops getting used. It also causes unnecessary churn across multiple domains. (See simplified topology below)


                                              _ _                         --- ABR1 ---
                                 PE1 –( _ _  ) --- ABR3 --|                    |------- PE2
                                                                            --- ABR2 ---

The CAR proposal does not have this limitation.

3.
From your comments, there appears to be a basic misunderstanding of the CAR proposal and the presentation.

We refer to the solution architecture described in [draft-ietf-spring-segment-routing-policy] as the deployed SR-TE solution. It specifies a pull model <section 8.5, and also 5.2> for a PE (policy head-end) to query SR-PCE and get a path with label-stack or SID-list in response. This avoids the PE needing to learn any state for all remote PEs by default.

You seem to assume a narrow reference to [ietf-idr-segment-routing-te-policy] which is not correct. The BGP-TE SAFI defined there is simply a means to enable a controller to signal a path for a policy to a specific SR policy headend using BGP instead of PCEP (see Section 2.3 of [draft-ietf-spring-segment-routing-policy]).

BGP CAR is regular BGP distribution for hop-by-hop routing (ala BGP-LU), but with color/intent-awareness. However, the data model defined for BGP CAR is inherently consistent with the one defined for SR-policy regardless of protocol.

4.
Mixing key and non-key values in BGP NLRI is not new, it’s been there since RFC3107 (label/label-stack) at least. Other SAFIs have had this too, for example, EVPN. There are cases of both fixed and variable values.

In the CAR proposal, we added structured TLVs to support multiple values and extensibility, instead of adding ad-hoc definitions and overloading of fields. It reduces complexity and provides for consistent handling.

That said, as I mentioned during the presentation, we have received suggestions for alternative encoding, and are evaluating them.

5.
Inherently, there is a variable degree of packing with BGP updates. That does not mean one should break it by default.

Similarly, just because we are being fore sighted by defining an extensible NLRI does not mean that it will invariably lead to a worst-case scenario ☺

Any extensions, such as new route-types that are proposed will go through WG review which should ensure proper gatekeeping. Again, there is precedence for this with other SAFIs.

And thank you for acknowledging that having route-types is acceptable.

6.
The CAR proposal does support domains with different color diversity. The Appendix describes a few examples.

7.
I will defer responding to the specific use-case and filtering comments since they are not yet specified in the draft. It will be much easier to discuss once we post them. Just a quick comment that the proposal does not at all preclude supporting anycast use-cases.

Thank you again for your patient review of the proposal and your feedback.

Regards,
-Dhananjaya






Hi CAR authors,



Thanks for the presentations in IDR and BESS meetings at IETF-110 last week.



We could not discuss in detail during the session because of time constraints. So

sharing my comments to the mailing lists.



Starting with follow-up on what Ketan mentioned in the IDR meetecho chat,

regarding SRTE is pull model vs CAR is push model:



I wanted to clarify, that may not be accurate. SRTE is also push model. PCE

provides the ‘pull’ part, which SRTE responds to. So, I think the question

Linda was alluding to remains.



viz: Why do we need another SRTE like family, when we have SRTE already?



Further, following are my own thoughts on the CAR encoding proposal, and challenges:



1/ The claim on better packing, and NLRI extensibility:



IMHO, micro-optimizing the NLRI wanting to support better packing introduces complexity in

a different dimension. Mixing key and non-key values in the NLRI increases implementation

complexity and hampers debuggability.



More-over, the claim of packing goes away when attributes like AIGP need to be carried in the

CAR routes. Because AIGP value may be different for different EP:Color NLRIs, those cannot be

packed.



One could suggest to put AIGP like attributes also into the NLRI to support better packing.

But you can easily see where this leads us. Having per-NLRI attributes leads us to the notion

of having “zero packing”. Because now everything is per-prefix. The SID, label, SRv6-SID,

other attributes. Etc..



About carrying SRv6 SIDs per NLRI: not being able to share the same SRv6 SID for different EP:C

NLRIs (i.e. per-prefix label/sid) may also be inefficient, it may cause huge size BGP updates,

which may increase Control plane convergence time.



So, we need to be cautious. Having a kitchen sink NLRI that can have “anything” could become a

reason to abuse the protocol in unforeseeable ways. IMHO, it is OK for a BGP family to have a

typed NLRI as long as it avoids non-key fields.



2/ using Color in the NLRI as both “Identifier/Distinguisher” as well as the “Route-Target” equivalent.



This tight-coupling has the problem that we cannot form Venn diagram of Colors to support cases,

where core-network has more colors than access networks. Have the authors considered such use-cases?



This also has the problem of not being able to strip color out, to do path-selection on EP alone,

as is possible when using RD like distinguisher. When an Anycast EP-address is present in multiple

domains, that don’t agree on the same color-namespace, such problems may become evident. Albeit a

corner-case, not impossible to conceive in real world.



Also, it is worth noting that IDR has seen similar proposal in the past (BGP LCU from Juniper) which

was not pursued further after self reflection on such considerations.



3/ Claim on wide SRTE deployment experience.



I would like to note that, SRTE has so far been used as a single BGP-hop family, between

controller and BGP-speaker. And it has no deployment experience doing hop by hop readvertisement

and carrying forwarding state thru the inter-domain networks. So applicability of ‘SRTE

deployment experience’ in inter-domain BGP networks is questionable.



Comparing it to L3VPN/LU, which CT derives of – it is widely deployed in such a role in inter-domain networks.

Authors of CT recognize the scaling challenges that Seamless-MPLS networks see today on the transport-layer.

And have proposed multiple ways on how that can be dealt with. Some of those mechanisms not only help CT,

but existing LU deployments as-well.



To me, re-using existing functionality, and start improving on the scaling challenges seems like a better

approach, than re-inventing existing mechanisms, making them work functionally and then coming to the scaling

part.



4/ Filter routes vs CAR routes.



Mechanisms of the Filter-routes is not clearly described yet in the draft.



But taking a guess, it could be either



  *   a new route-type in the same family? (more likely)
  *   OR, uses RTC family routes to provide filtering for CAR routes



If Filter routes are a separate RouteType in the same CAR family,



  Please note that the Filter-routes need to be propagated in the opposite direction

  as the CAR transport-advertisements.



  And learning from RTC mechanisms, the initial transport-route-advertisements may need to wait for

  EOR of Filter-routes. If those are just different route-types in same NLRI, such EOR based

  mechanisms cannot be employed, unless we introduce a per-route-type EOR (EORT).



  This also means that the rules for dealing with each route-type needs to be specified separately,

  In essence each route-type becomes a new family equivalent, with its own distinct needs and rules.

  This looks difficult to comprehend, implement, troubleshoot. Imagine specifying both RTC and VPN

  procedures in same bgp-family, carrying them in same RIBs.



 This is just a thought experiment on why putting many different functionalities in the same family as

  different route-types may not necessarily make things ‘simple’.



  Instead, following the age old principle of “doing one functionality well”. That keeps things simple, IMHO.



If Filter-routes are just RTC family routes working on CAR routes,



  That could be made to work for the case where the LCM community exists on the route, but LCM community

  doesn’t always exist on the route. It is only a special case. So it may not work for the typical cases.





Finally, I feel the CAR draft proposes enough changes to basics of BGP, how BGP NLRI encoding is done,

and is basically a Transport-layer family which intends to provide common infrastructure that is used by

by all BGP Service-families.



So it may be more suitable for review by the IDR WG which deals with common infrastructure pieces of BGP,

than the BESS WG which deals with BGP services. Request the WG chairs to consider this.



Thanks,

Kaliraj


Juniper Business Use Only


Juniper Business Use Only