Re: [Idr] Growing BGP-LS Attribute

[Robert Raszuk <[e-mail]>]

> soon we will have bgp-ls doctors.

Honestly having to read through all of the recent bgp-ls proposals and
extensions there is so much confusion there on what goes to NLRI vs BGP-LS
Attribute, what is TLV and when nesting to sub-TLVs makes sense, why do we
send different BGP-LS Attribute depending to which NLRI it accompanies etc
.. that I think BGP-LS doctor(s) are needed not soon but yesterday. And
some of those documents are at the the WG-LC status too ...

Yes interestingly no one cares to touch on few other BGP aspects which may
come into play. Example: Should BGP-LS be eligible to be packed into BMP
(considering recent BMP extension proposals), how the dynamic IGP data be
of any use if some BGP still uses long MRAI timer for subsequent updates on
the same NLRI etc ...

> as adrian says, if you wanna monitor the igp, then do so directly.

Well as you know in practice this is not always an option - in fact this is
almost never an option in production network ... Controllers running on x86
boxes sit far from routers and are never allowed to connect to them
directly. So bringing IGP adjacency between router and such oracle is hard
... even assuming it would be just passive one. That's why TCP is so
attractive since as long as server is reachable the session will be formed
and bits transferred.


On Sun, Oct 21, 2018 at 8:33 PM Randy Bush <[e-mail]> wrote:

> > I think by all means this is the largest single BGP attribute we ever
> > had and it seems growing daily like a balloon. Most of the TLVs which
> > are defined contain sub-TLVs which can be filled with data in a non
> > limited by any spec fashion.
>
> this is scary.  as adrian says, if you wanna monitor the igp, then do so
> directly.  this bgp-ls thing is trying to funnel all of bgp and igps;
> but to no clear end.  and, as igps and bgp keep expanding, bgp-ls will
> only amplify the problem.  soon we will have bgp-ls doctors.
>
> and i wonder why it does not also funnel dns. :)
>
> randy
>