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

[Jeffrey Haas <[e-mail]>]

Gyan,


> On Jul 7, 2022, at 12:35 AM, Gyan Mishra <[e-mail]> wrote:
> On Wed, Jul 6, 2022 at 2:09 PM Jeffrey Haas <[e-mail] <mailto:[e-mail]>> wrote:
> Gyan,
> 
> 
> > On Jun 30, 2022, at 7:53 PM, Gyan Mishra <[e-mail] <mailto:[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.

Your question could be equally argued whether we should keep BESS around or decide that they've polluted BGP enough with their work. :-)

(Note to the bess chairs, clearly I don't agree!)

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

And also part of the discussion regarding prioritization features, implicit or explicit, in stacks.  Implementors are certainly aware of such considerations.  

I'm also quite happy to discuss prioritization with interested parties at the upcoming IETF.  It might make a good IEPG talk, but many of these conversations are so deep in implementation considerations that are vendor-specific that standardizing them is problematic.

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

I generally refer to this as "structural segregation".  It's a good story for resiliency, somewhat problematic in terms of how different layers interact with each other, and certainly increases operational complexity.

But again, the question isn't strictly "does this belong in BGP".  Much like what you describe above, if you have a BGP-LS plane that's responsible for separately distributing the state... why does it matter?

Where it matters, of course, is when the same device needs both BGP-LS state along with other things BGP carries.

-- Jeff