Re: [Idr] BGP-LS alternatives - problems and solutions

[Jeffrey Haas <[e-mail]>]

Gyan,


> On Jun 30, 2022, at 7:53 PM, Gyan Mishra <[e-mail]> wrote:
> I believe the goal here is as the subject states is to investigate an alternative to BGP-LS to avoid overloading of BGP so BGP remains clean for internet routing functions only.

That boat has sailed long ago, and for the most part it's been fine.  But only after it hit rough waters.

This discussion of "I don't want it in BGP" really has two main operational points to it:
1. Is the state coupled enough with other data in BGP that it's useful to have it on the same session?
2. If it's a "separate application", do I want to risk having that application share the same stack as other important BGP data?

The "separate session" argument regularly sees applications like BGP-LS and BGP Flowspec deployed on dedicated sessions.  The one bit of operational awkwardness is it requires different IP addresses for the sessions if you have two different BGP applications between the same pair of boxes.

The "separate application" argument is a common software engineering discussion for fate-sharing, not just one of "same stack" or even "same protocol".  Moving things to a separate protocol doesn't help the fate sharing conversation if it's simply a different encapsulation that lives in the same code base.  Adding more encapsulations just adds more things to debug in many cases.  And certainly, structural separation of the code bases can be done to attempt to address resiliency considerations... but then you have to pass that data from application A to B anyway, and that's just another channel for performance issues - and often yet another encapsulation involved.

Personally, I'm more bothered by some of the heavy-weight telemetry options we've been shoving into routing than I am bothered by yet another BGP address family module.  But that's experiences of life in my own code base.

> Regarding new IGP extensions to be encoded for stateful PCE that come up, all solutions end up requiring a separate parser for OSPF and ISIS as the TLVs are different.  So you are in the same boat regardless of if it’s BGP-LS, PCEP-LS, IGP of Yang.

As at least one party commented to me off-list (who I suspect wants to stay out of this discussion) that we will have this particular headache no matter what the encapsulation for the state becomes.  BGP-LS did a fair job of providing a high level representation of important IGP state without deep ties to one particular IGP.

That level of abstraction also impacts the discussion of "put the state for this extension in BGP-LS along with the IGP".  For many of the things that have been simultaneously standardized in LSR since they decided to do work for both protocols in tandem, we don't have the headache about the mechanisms being different for common features.  Does this mean we'll want EVERYTHING LSR does in BGP-LS?  Possibly not.  We should make it easy to do so.

Similarly, operators might want to start to demand features to provide filtering of some state.  It's a reasonable idea.

> I think it’s a good idea to have multiple alternative to BGP-LS for operators.

My perspective has a different bend to it than yours does.

I tend to discuss these things in customer meetings in terms of "people will have preferences about the ecosystem they live in".  Some consumers want state in raw and efficient PDUs, some in simple structured YANG, some in their not-IETF-protocol transport with not-IETF-schema because their toolchains live in it.  Accommodating ecosystems is fine.

But for IETF discussions, we're mostly discussing how to get stuff between and out of routers efficiently.  There's plenty of room for middle-layers that can re-marshal data into your ecosystem component.  Do you really want that done by the router?  (See my comments above.)

Or, as I gripe when dealing with some of these encapsulations, "printf is expensive!"

> One major advantage of PCEP-LS is that if you already have a Centralized PCE/SDN controller deployed you already have a PCEP session NBI to all the nodes in each domain across H-PCE parents and child PCEs, do to the PCEP infrastructure beong already present and now can be reused for PCEP-LS instead of BGP-LS.

This is a great example of the ecosystem perspective.  And, similarly, how leveraging common encodings can let you deliver things quickly.

-- Jeff