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

[Tony Przygienda <[e-mail]>]

Jeff T gave you one example of what the input of a customer with deep
pockets is for foreseeable future. IME this is a pretty representative
sample for the remaining ones ...

if you manage to standardize in IGPs something that can replace BGP-LS by
something more "sane" (the term to be defined in this context ;-) then
great, I'm all ears. Until then IETF peddles BGP-LS basically and that's
the slope we're sliding for better or for worse ...

--- tony

On Tue, Jun 21, 2022 at 5:37 PM Robert Raszuk <[e-mail]> wrote:

> Tony,
>
> The main problem here is that you are not proposing a better alternative
> in LSR WG. You keep riding on a hijacked train purely for convenience. And
> till you are no longer allowed to board it no other alternative will
> surface.
>
> Yes the sooner you start with a different solution to send LSDB to the
> controller the smoother the switch will be for your customers. So now let's
> see how much you care about "customers with deep pockets".
>
> Best,
> R.
>
> On Tue, Jun 21, 2022 at 5:14 PM Tony Przygienda <[e-mail]>
> wrote:
>
>> no, it's not a valid argument. it's just a fact of life like bees and
>> birds when customers with deep pockets need their stuff working. and no
>> better alternative meeting their needs is available or rather they went
>> down the slope of something like BPG-LS IETF sent them barrelling down so
>> they just need mo' stuff in it to make new stuff they use work. And to be
>> mildly cynical here, BGP-LS at time of creation got the warnings about
>> re-encoding and being always behind the IGP curve ultimately and ignored it
>> so BGP-LS gets to live it down now ...
>>
>> Jeff H. can sing an opera about the squatting and how to address it via
>> temporary/experimental etc ... ;-)
>>
>> -- tony
>>
>> On Mon, Jun 13, 2022 at 2:51 PM <[e-mail]> wrote:
>>
>>>
>>>
>>>
>>>
>>> *From:* Idr <[e-mail]> *On Behalf Of *Tony Przygienda
>>> *Sent:* Wednesday, June 8, 2022 10:32 PM
>>> *To:* Robert Raszuk <[e-mail]>
>>> *Cc:* Les Ginsberg (ginsberg) <ginsberg=[e-mail]>;
>>> [e-mail]; Susan Hares <[e-mail]>
>>> *Subject:* Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption
>>> call (6/6 to 6/20)
>>>
>>>
>>>
>>> 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 ?
>>>
>>>
>>>
>>> I don’t think that the threat to squat on codepoints is a valid
>>> argument. (Although it has already been used in the IETF/LSR WG to push for
>>> the adoption of the corresponding IS-IS draft [1].)
>>>
>>>
>>>
>>> More generally, there is a number of BGP attributes which have been
>>> squatted recently [2]. Are we fine with this? (e.g. yes, this is allowed
>>> for a couple of companies) If not, what could we do to improve on this?
>>> (More code points reserved for development?  Name and shame in the IANA
>>> registry (e.g. Squatted by Foobar)?...
>>>
>>> Speaking for myself, I’m not fine with this. This hurts interop [2],
>>> sometimes networks [2], fairness…
>>>
>>>
>>>
>>> [1]
>>> https://mailarchive.ietf.org/arch/msg/lsr/pNBoc30jIPx5op_s3gzlIsDfPMc/
>>>
>>> [2] https://www.rfc-editor.org/rfc/rfc8093.html
>>>
>>>
>>>
>>> Regards,
>>>
>>> --Bruno
>>>
>>>
>>>
>>> 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
>>>
>>>
>>>
>>> Orange Restricted
>>>
>>> _________________________________________________________________________________________________________________________
>>>
>>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>
>>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>>> they should not be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>>> Thank you.
>>>
>>>