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

[Gyan Mishra <[e-mail]>]

Jeff

On Wed, Jul 6, 2022 at 2: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.
>

    Gyan> Agreed and understood.  The question for the WG is are we really
overloading BGP with BGP-LS, and what is the impact or adverse effects of
doing so and is there a better more robust solution.

>
> 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.
>

    Gyan> This is commonly done by operators to avoid control plane
overloading and shifting heavy weight AFI/SAFI to separate session.

>
> 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.


Gyan> Moving to separate protocol agreed you don’t help with fate sharing.
What is commonly done is creating a protocol cluster and maybe an
application cluster layer on top of that so moving all IPv4 AFI/SAFI  PE-RR
to separate IPv4 RR cluster and moving all IPv6 AFI/SAFI to a separate IPv6
RR cluster and then taking the chatty heavy weight AFI/SAFI like BGP-LU,
Flowspec and maybe even MVPN or any other heavy hitter app  and move to
their own dedicated RR clusters.  So that helps circumvent the overloading
tremendously with BGP.

This is a possibility for a solution but it definitely comes with
complexity and cost overhead and increased OPEX.

Thus the idea of alternatives..

>
>
> 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.


    Gyan> Understood

>
>
> > 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.
>

     Gyan> Agreed

>
> 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.
>

    Gyan> Agreed

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

    Gyan> Agreed. Makes sense

>
> > 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.)
>

    Gyan> Understood

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

   Gyan> Ack

>
> > 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
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*