Re: [Idr] Growing BGP-LS Attribute

[Robert Raszuk <[e-mail]>]

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