Re: [Idr] Growing BGP-LS Attribute

[Robert Raszuk <[e-mail]>]

Hi Ketan,

The discussion is not turning .. it has always been about questioning
principle to use BGP where and when there are better alternatives.

And while I am not against code reuse (same code as BGP) I am highly
against two things:

1. Using IGP and TE information propagation together with routing SAFIs in
the same process - hence I proposed
https://tools.ietf.org/html/draft-raszuk-mi-bgp-00 to at least short term
allow to run BGP-LS on *completely* separate and isolated process

2. Waisting IDR precious time which if I recall used to stand for
Inter-Domain Routing WG and not for Inter-Domain Reporting WG to engage
with never ending flood of defining encoding for all IGP and TE and SR and
BFD etc... extensions. That's really sick. We only get 2h 3 times a year
and it would be huge disservice to BGP to take that time for extending it
with new TLVs.

If you like create a new WG dedicated to manage SAFI 71 & 72 making sure it
will run in fully separate process from other use reachability propagation
use cases of real BGP.

Thx,
R.

PS. And your comment that sending this to two or three controllers makes it
multi-point and and that is "one of the key benefit leveraged from base
BGP" is simply amazing :)








On Fri, Oct 26, 2018 at 3:18 PM Ketan Talaulikar (ketant) <[e-mail]>
wrote:

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