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

[Tony Przygienda <[e-mail]>]

we're in agreement here (speaking strictly for myself) and it was the
original argument made when the work was being pushed.

Or ideally use Tony's new SSAP discovery stuff to actually tell via BGP
where the IGP topology conduit is and hook up to it (some kind of topology
publish/notify) as you alluded and we spoke behind the lines. The problem
there is that policies may prevent you to get places (one of the original
BGP-LS argument as in "BGP can get anywhere and cross AS boundaries easily
while other mechanisms need hole punching")

--- tony

On Wed, Jun 8, 2022 at 10:41 PM Robert Raszuk <[e-mail]> wrote:

> Tony,
>
> ... just to get something perhaps productive out of this thread ...
>
> >  it should be a raw data conduit
>
> I have spoken with a number of people about it. I must share that all but
> one agree that what BGP-LS transports should be an opaque payload ...
> perhaps in a form of bin chunks. BGP should never look at it, never
> understand it.
>
> IGP could zip it and give configurable chunks to BGP to carry it p2p.
>
> Does it solve the problem - no. But does it free BGP dev and dev-test
> resources from becoming IGP shadows - YES. And that would be a small step
> win.
>
> All 100% transparent to customers and they do not care if BGP parses each
> IGP TLV bit or not.
>
> So what's next ? Should we write a small draft and propose it to IDR ?
> Before I or you spend any time on it - do we have formal rough consensus on
> such an approach. Or maybe those who think BGP should act as IGP' should
> speak up now - in this or new thread here ?
>
> Kind regards,
> Robert
>
>
> On Wed, Jun 8, 2022 at 10:32 PM Tony Przygienda <[e-mail]>
> wrote:
>
>> Don't blame me for BGP-LS, read the RFC authors' list and go from there
>> ;-)  I didn't sell it as "don't need a parser, it's secure, it's inter-AS,
>> it's singing & dancing" ... And I was vocal if BGP is abused to carry IGP
>> topology it should be a raw data conduit and about other problems it will
>> cause down the road.
>>
>> And the answer for questions below is yes and many times over many, many
>> years. actually before BGP-LS customers were running passive sessions and
>> such things as lots of IGP folks now and actually, some customers who got
>> disillusioned by BGP-LS I raw-streaming IGP via gRPC (whereas I think redis
>> or some such thing is possibly a better choice but it's a deeply technical
>> discussion for high performance IGP coders and realistic boundaries of
>> automation code to consume IGP speed feeds) ... But few and far inbetween
>> ;-)
>>
>> So, can we now go back and make sure we have a standardized version of
>> this draft/technology in BGP-LS before we end up building it sideways stuff
>> or have to squat points ?
>>
>> And you may observe we kept the stuff hre to super/duper minimum (just
>> cluster ID) rather than stuffing things like client/FR/tunnel stuff into it
>> since only the boundary is of interest really and correlation L1/L2 BGP-LS
>> feed can happen with that minimum already in place.  Unless I hear opinions
>> that we should put more stuff in.
>>
>> chiming out ...
>>
>> -- tony
>>
>> On Wed, Jun 8, 2022 at 10:22 PM Robert Raszuk <[e-mail]> wrote:
>>
>>> Tony,
>>>
>>> Yes - let's keep adding to BGP stuff which does not belong there and
>>> continue to keep crying how BGP is slow and how BGP  interdomain
>>> convergence takes minutes for full table.
>>>
>>> Why do we need the Internet at all ? After all - you never sold anything
>>> to "The Internet".
>>>
>>> Let me ask you a question - Did you ever presented to customers an
>>> alternative to BGP-LS ? Did you demo it ? Did you discuss pros and cons?
>>>
>>> With such myopic view we can sit and watch how this train which left
>>> years ago goes slower and slower ..
>>>
>>> Or maybe this is after all good news ... I am sure inventors of SCION
>>> can be super happy to see such growing abuse of BGP to be happening in IETF
>>> over and over again.
>>>
>>> Cheers,
>>> R.
>>>
>>> On Wed, Jun 8, 2022 at 10:05 PM Tony Przygienda <[e-mail]>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jun 8, 2022 at 8:47 PM Robert Raszuk <[e-mail]> wrote:
>>>>
>>>>>
>>>>>
>>>>>> train left the station ages ago pushed by original authors who
>>>>>> dissipated leaving us with this contraption ...
>>>>>>
>>>>>
>>>>> So perhaps time to cut this car out of the locomotive ? Before it
>>>>> causes the entire train to derail damaging fun and joy for many ?
>>>>>
>>>>
>>>> Robert, good luck with that then ... Let me know how it goes after you
>>>> talked to a bunch of really large customers having lots automation built
>>>> around it already ;-) Ooops, I forgot you're fortunate enough these days to
>>>> not be with a vendor running a large part of the planet.
>>>>
>>>>
>>>>>
>>>>>
>>>>> genuinely funny that this 5 pages tiny TLV draft is causing such a
>>>>>> deep soul searrching in IDR ;-)
>>>>>>
>>>>>
>>>>> For one this is not about this draft but any new IGP protocol
>>>>> extension seen in ISIS or OSPF messages to go to BGP-LS -- as it turns out
>>>>> this is really what it is.
>>>>>
>>>>> For this very draft irrespective if this is a separate document or you
>>>>> copy and paste it into the main ISIS reflection spec - I am still not
>>>>> seeing the need to send it anywhere by BGP.
>>>>>
>>>>>
>>>> first, IGP draft is in publication already
>>>>
>>>> second, BGP-LS is IDR domain  unless there are plans to move it into
>>>> LSR charter ?
>>>>
>>>> yes, I'm just mildly acerbic/flippant but please, let's stay real here
>>>> though I know you go to arbitrary lengths often to get a laugh/raised
>>>> eyebrows ;-)
>>>>
>>>> -- tony
>>>>
>>>