Re: [Idr] Growing BGP-LS Attribute

["Ketan Talaulikar (ketant)" <[e-mail]>]

Hi Robert,

I think the discussion is again turning from encoding (i.e. handling of growing BGP-LS attribute size) to questioning the role and use of BGP-LS.

I agree with what Adrian has stated (except the part about p2p – it can be used p2mp to feed multiple/redundant controllers and that is one of the key benefit leveraged from base BGP). There is damping at IGP but then also one that can be applied at BGP(-LS) level in the implementations that I know. We could document guidelines for use and applicability.

However, coming to the topic of the BGP-LS attribute. We do need to consider

a)      The 4K limit and therefore perhaps enabling a BGP-LS NLRI to be split across multiple update messages. Similar to how we have LSP fragments in ISIS or multiple instances of the LSA (e.g. RI LSA) in OSPF. This would also enable splitting of information across updates and perhaps segregate information into static or dynamic or based on application.

b)     Another aspect not documented/discussed is filtering out of Attribute TLVs that are not of interest.

Thanks,
Ketan

From: Robert Raszuk <[e-mail]>
Sent: 26 October 2018 20:36
To: [e-mail]
Cc: [e-mail]; Ketan Talaulikar (ketant) <[e-mail]>
Subject: Re: [Idr] Growing BGP-LS Attribute

Adrian,

Is all fine what you are describing. But tell us why it has to be BGP job ?

You already have efficient telemetry streaming out of the router. Why it can not be used as transport for all this information p2p between router and controller ?

Best
R.

On Fri, Oct 26, 2018, 09:59 Adrian Farrel <[e-mail]<mailto:[e-mail]>> wrote:
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