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

[Tony Przygienda <[e-mail]>]

As mildly another lens to Jeff's ruminations (which I agree with obviously
having kind of same profile in terms of taking my input to decide "what
things make sense to build and deploy and what's just a wish list") ...

There are largely two classes of customers:

a) they like BGP-LS because they don't have to parse IGP stream or want all
the excruciating IGP-as-garbage-bin details being carried around (which can
come in thick and fast and if you have tons nodes in network and
perturbation and the implementation pumps as fast as it can you can see
lots seqnr# of same thing, de facto you have to build a flooding peer),
they can throw BGP session far out and keep them up and by judicious use of
instances and sessions they can decouple fate sharing. That's the largest
part of customers, by far. Yes, BGP-LS has warts but what is proposed here
will not change any of those, it's just a different encaps because
"somebody likes Yang better".

b) they know of BGP-LS but they are sophisticated or solving really hard
real time problems and want to get the IGP view and are willing to
parse/compute/etc. The conduit over this is delivered is kind of
orthogonal, often religious but basically, as Jeff says, matter of tooling.
Yang? well, is it fast enough normally? PCEP? yeah, makes sense if you have
your whole ecosystems grown around it. But so does passive IGP session
(which some such customers did/do). Or just stick raw IGP PDUs into
BGP-LS-BMP-like-thingy which probably will appeal to lots of people (having
the advantage as well that just like BMP we cuold annotate stuff and
actually carry other interesting things like e.g. computed local RIBs).
That's actually work taht could be really useful.  The IGP PDUs are small
so we don't blow BGP MTU Out BTW. Just carryuing IGP PDUs however is a
fairly trivial conduit/encaps discussion and since it's a such of course it
can generate a hundred flavors of "standards" per Alia's quote "the beauty
of IETF standard is that we have so many of them for everything "  ;-)
This will IMO not improve anything really except lot of -00 drafts flying
and my-encaps-better-than-yours discussions ;-)

So, yes, there is a market for streaming IGP raw but people who are
sophisticated enough solved it already by their encaps-du-jour AFAIS and
BGP-LS pressing problems are not that it's going over BGP or Yang or
whatever. The actual problems are not pressing enough for now to guarantee
a lot of work AFAIS but if they become such such interesting work will need
to go on in BGP-LS which will however break the existing stuff and carry
with it IGP extensions as well.  And something like IGP BMP could be in
fact a somewhat interesting discussions if it's withint the scope of this
threaed ...

my rusty (i.e. "experienced" ;-) 2c

-- tony


On Wed, Jul 6, 2022 at 8:09 PM Jeffrey Haas <[e-mail]> wrote:

> 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
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>