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
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
