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

[Susan Hares <[e-mail]>]

Bruno:

You raise a good point on squatting.

As you know, the IDR along with the Grow WGs continue
to try to help stamp out squatting.   I agree that it hurts the Internet.

IDR WG spent time trying to make registries FCFS or Expert Review to
reduce the time-lag.   If there is some delay causing people to
squat rather than request, I would like to know.

One conundrum is how to squatting reported for widely deployed applications.
Ask you put it, do we put "squatted by X" after a number squatted?
Let me know if you are interested in chatting about this topic
Either in person at IETF-114 or via email (on-list or off).

A few authors are generating a list of BGP parameters that have been
squatted on.   I hope to see it by IETF-114.

Cheers, Sue

From: [e-mail] <[e-mail]>
Sent: Monday, June 13, 2022 8:52 AM
To: Susan Hares <[e-mail]>
Cc: Les Ginsberg (ginsberg) <ginsberg=[e-mail]>; [e-mail]; Robert Raszuk <[e-mail]>; Tony Przygienda <[e-mail]>
Subject: RE: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Tony PrzygiendaSent: Wednesday, June 8, 2022 10:32 PMTo: Robert Raszuk <[e-mail]<mailto:[e-mail]>>Cc: Les Ginsberg (ginsberg) <ginsberg=40cisco.com
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tL2FhYjQ4MDBlN2ZhMTAzNzNmMzM0M2U0NDhiNWE4MWZjLzE2NTUxMjQ3MjQuNTI=#key=1703aafa249cc7426848db2a875281dd>  FAQ<https://www.inky.com/banner-faq>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>



From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Tony Przygienda
Sent: Wednesday, June 8, 2022 10:32 PM
To: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Cc: Les Ginsberg (ginsberg) <ginsberg=[e-mail]<mailto:ginsberg=[e-mail]>>; [e-mail]<mailto:[e-mail]>; Susan Hares <[e-mail]<mailto:[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/<https://shared.outlook.inky.com/link?domain=mailarchive.ietf.org&t=h.eJxNzEEOwiAQheGrGNaGgQK2ujLGjQuNNzBTOrTVFhqoxmi8u7Jz-_K_783ucWCbBevmeUobgBH7AaPt-gfxnmbHQ2whDzCmFoYUYTrtglXiejg_TZguSbWv4ZD27ny0wJYLdsucp_l3lMJUq7UsIHUYKW198-q4DSMg1roSgkqHUqhSOaW0Iq2r2mAlnQW5MkYWuiw0N0VWKat1vPvAG7IRydM2RPQtZTAXTS7-ps8XrmREsg.MEQCIGpzCIwYkjUSnNdt4NiqB72DlIygD6dSUkMCk1Yv0DyyAiBXhCyeflfoU-fgoxzmZFaxHY2rJt-LqTo3W-y0FtDfrA>
[2] https://www.rfc-editor.org/rfc/rfc8093.html<https://shared.outlook.inky.com/link?domain=www.rfc-editor.org&t=h.eJxNjMsOgyAURH_FsG55o-jKX0G5SlOF5oIxadN_r-y6mMVMzpwPOXAjQ0NCKa88MHaeJ8VlvoN_lIQ04cquWmN5r2go-0ZuDXnWT4QLWQU3tu2FZDk4hDxG_w50TjtzbtKWc-gWJ7jq1KKUVqC1nYyz4pKK1hghdSc1NbJaoVonPGKiHmZ0EGFM6OIKVVgJX4m_6fsDua86xw.MEQCIE8vHEOBRJGG4_2Gp0cFsb8yu6MnuvStmbs0pqgv2P3xAiAOdQeYGXgzDX9ZPRLN3RJYD8KbQ_rZQOeeDkeBSV-4tQ>

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]<mailto:[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]<mailto:[e-mail]>> wrote:


On Wed, Jun 8, 2022 at 8:47 PM Robert Raszuk <[e-mail]<mailto:[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.