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

[Robert Raszuk <[e-mail]>]

Hi Jeff,

Few points on your note ...

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

I would add use of BGP development and devtest resources to keep adding new
BGP extensions along with any IGP extension. That simply does not make
sense.

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

I am not sure this is a valid concern. Reason being that the right model is
that IGP data stay within IGP. No need to send it across different
processes or subsystems.

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

No one is prohibiting to normalize this across IGPs And BGP-LS actually
does almost good job here. So my proposal (which I still plan to post
before the deadline) is to leavarge it.

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

Included day one in my proposal :).

Best,
R.