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

[Kaliraj Vairavakkalai <[e-mail]>]

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