Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

[Robert Raszuk <[e-mail]>]

Tony,

To address your last three emails.

What I am proposing as a first step is not to use any other protocol (just
trying to make smooth small step evolutionary improvement). Yes we spoke
about alternatives to BGP-LS offline but let's put it aside for now.

So what I am proposing is that we add a two new TLVs to BGP-LS which will
be used to carry exactly what you carry today except it will be completely
opaque to BGP. Say for starter it will be HEX block.

>From sessions intra and inter domain nothing changes. Nothing changes from
security pov.

IGP can encode this hex block as it would give this to BGP today - so no
need to worry about writing smart ISIS or OSPF parsers on the controllers.

Gain - BGP does not need to do anything new each time LSR WG invents a new
link state protocol extension. BGP does not need to worry about malformed
updates if such malformation would happen inside the IGP data.

Do you think this is pragmatic enough approach that we could write small
draft and propose ? Or do you still see an issue with taking such direction
? Again "you" here is a question to everyone.

Thx,
R.















On Wed, Jun 8, 2022 at 11:05 PM Tony Przygienda <[e-mail]> wrote:

>
>
> On Wed, Jun 8, 2022 at 10:41 PM Robert Raszuk <[e-mail]> wrote:
>
>> ...
>>
>> All 100% transparent to customers and they do not care if BGP parses each
>> IGP TLV bit or not.
>>
>>
> so for sake of completeness and to be fair to BGP-LS as it stands since it
> seems this "pinata" thread got a bit too one-sided ;-) There were more good
> arguments than the BGP is inter-AS ...
>
> Writing a good IGP parser is NOT trivial (especially ISIS) and then you
> still have to stitch e'thing together from all the fragments flying around.
> And that parser needs be maintained with IGP changes as well. And it's not
> easy to get your hands on really good maintainable IGP parsers in open
> source properly chopped off the main protocol implementation on top (unless
> you enlighten me). And you have to keep up with flooding possibly &
> tie-breaking and so on. For large operators at scale and so on arguably  a
> viable path, for lots of folks with limited resources BGP-LS is arguably a
> much easier thing to consume to monitor some things/get some data.
>
> Also, there seem to be assumptions here that the code MUST be hacked into
> BGP. That ain't so, arguably you can architecture independent code that has
> read-only access to IGP and builds a projection of it as BGP-LS stuff that
> is given to BGP to push out without BGP understanding really how the thing
> comes about.
>
> so, 7752 was a trade-off. given how successful it got arguably a viable
> trade-off as non-perfect things go ;-)
>
> -- tony
>