Re: [Idr] Growing BGP-LS Attribute

["Adrian Farrel" <[e-mail]>]

Sorry for the delay, Robert: travel.

>> IMHO, two fundamental concepts in BGP-LS are summarisation and stability.  
>
> I don't see any summarization in the current encoding as most
> if not all of the information being sent is verbatim taken from 
> IGP drafts and RFCs. 

Encoding does not (and should not) reflect summarization.
Summarization is the process of taking n components and representing them as m (<n) components by;
- omitting
- aggregating
- virtualizing

The summarized things look like links. Some may really be IGP links reported straight through; some might be virtual links. In both cases they use the same encoding: they are presented as links.

Of course, one could use BGP-LS to simply dump the full IGP database, and that is not summarization. I would argue to not use BGP-LS if that is the function you want to deliver.

> Stability is also not there as now we have a lot of dynamic data without
> any new advertise-time thresholds being set - so we are just relying on
> IGP flooding thresholds. 

If summarization is in use, then a small change to the IGP database might cause no change to the summarized information.
Furthermore, the summarization algorithm should (IMHO) be damped with some form of thresholding.
And even if you use BGP-LS to simply dump the full IGP database (against my advice :-), you can apply damping.

Most of the use cases I am aware of use BGP-LS to extract a summary of the IGP information for TE purposes. TE is usually a damped process, and operates on summarized information.

Possibly, another use case is "cross-domain reachability". That is also a form of summarization, and is relatively stable in the face of intra-network changes.

In short, there is no strong binding between the IGP and BGP-LS: neither temporal, nor informational. The use of a common encoding does not imply simultaneous or identical data.

BGP-LS is a protocol spec. We could make a good case that there should be more documentation of how/when to use the protocol, but since it is a p2p protocol, I don't think that material belongs in the protocol spec. With this in mind, I helped to write RFC 7926 for a specific TE scenario, and draft-ietf-bess-datacenter-gateway for a reachability/TE use case.

> BGP-LS has just one fundamental convenience - free TCP transport.
> That's it. If our link state protocols would run over TCP from any node
> to controller (well Henk & Gunter  just proposed it for ISIS) or if there
> would be a BMP analogy to IGPs (get full or filtered feed of LSDB or TED
> over TCP) there would be very limited need for BGP-LS. 
>
> So today we are just growing single BGP-LS Attribute. Such attribute
> content changes depending if it is part of Node NLRI, Link NLRI or
> Prefix NLRI. Say take LInk NLRI there are TLVs which are static and
> which are dynamic - well there is no way to only send dynamic when
> they change as in BGP subsequent update with the same NLRI is an 
> implicit withdraw of the former. So you are forced to repeat everything
> for given link NLRI regardless if even single value changes. You call this
> a "summarization" ?

No, that's not what I call a summarization as I hope I made clear.

> Further imagine controller and operator only needs 10% of the 
> information for his specific application. Well hard luck as there is
> no way in general in BGP to ask for a subset of the attribute 
> content. Neither RTC nor ORF would be of any use. 
>
> What is needed here is an efficient and reliable pub-sub message
> transport - not just load of BGP TCP because it is there. And this
> all applies to trusted or untrusted or hybrid domain types :). 

Adrian