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

bruno.decraene@orange.com Mon, 13 June 2022 12:52 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B8EC15AAC1 for <idr@ietfa.amsl.com>; Mon, 13 Jun 2022 05:52:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1TqutDlhWYN for <idr@ietfa.amsl.com>; Mon, 13 Jun 2022 05:52:01 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 255A1C157B3B for <idr@ietf.org>; Mon, 13 Jun 2022 05:52:01 -0700 (PDT)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar24.francetelecom.fr (ESMTP service) with ESMTPS id 4LMBKV5Hxtz5vcN; Mon, 13 Jun 2022 14:51:58 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1655124718; bh=pganZoOgQuJyTETMEg1/8kR4732hvf9RojgfxLFXB3g=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=KLGrvJ5qXYB3SFp6Yjh911MiXpUrDAS7Ijd2QM6TwVreZ3/0VPdlRwYKnnc6O8WJi CQU5WsEB0aosA3KIY9J4Fw7uzkQrlXMzYLrY/LpQPyPlLntVaiRdarkfgwL8u9B2rz vDqlKAKheqqtkGcvRiMz2WCqykAbriXypK8vmPygs3FkMzZdatWLfZP9Y8+HmO3Ejd Wx4RbWqOeixgeAb3FOC2nniPtf2PDuftKPEoV6s1jaxqyUUmk7wzSvQhKiclOyb+Px J/Z8YHWK1V3eOenM7w0yiAvDWQ9Ig70fIVcIgKLeJk7zXRovoZKoUpqhbS+vo1R+a4 yb594MoeNIUsg==
From: bruno.decraene@orange.com
To: Susan Hares <shares@ndzh.com>
CC: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, "idr@ietf.org" <idr@ietf.org>, Robert Raszuk <robert@raszuk.net>, Tony Przygienda <tonysietf@gmail.com>
Thread-Topic: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)
Thread-Index: AQHYe2F2Cwf/zvFUqUiMOPLcqbFfqK1Fq8oAgAAMWgCAABWTgIAABN4AgAACugCAB3GcoA==
Date: Mon, 13 Jun 2022 12:51:58 +0000
Message-ID: <23807_1655124718_62A732EE_23807_213_17_3cf4e891a6fc4922b1da262e7fead11a@orange.com>
References: <BY5PR11MB4337153D1D387C125A822F12C1A59@BY5PR11MB4337.namprd11.prod.outlook.com> <BYAPR08MB487281C781BB66A00803B9ECB3A59@BYAPR08MB4872.namprd08.prod.outlook.com> <BY5PR11MB43370655CE2A2406B394C901C1A49@BY5PR11MB4337.namprd11.prod.outlook.com> <BYAPR08MB4872AB7D94218FFD4FF236D5B3A49@BYAPR08MB4872.namprd08.prod.outlook.com> <BY5PR11MB4337E9C8F39A7512FC8808DEC1A49@BY5PR11MB4337.namprd11.prod.outlook.com> <CAOj+MMFA+_2p0jucZJzDencS1KRnSVJPwK8SryV1nqf12M7VLA@mail.gmail.com> <CA+wi2hOnDrrFcpDFJGbBs412rP8-FgJ_ga-YPj3xhRgwu_ngEA@mail.gmail.com> <CAOj+MMEejRipew3CnxG9L9iZ1yBFxy1ewuDzDe+VgJN3_YCG+w@mail.gmail.com> <CA+wi2hMHdhrAhU3dP82XHh=W71TGxnCKUXVgZJEcE61N8J-0Pg@mail.gmail.com> <CAOj+MMFjfQmX-DLxgK01OcaMHVwCp3UrmXhbFhouz_SPRMbJBw@mail.gmail.com> <YqDjcrsoiCc0Sz58@Space.Net> <CA+wi2hOHuSqh6RwTEExxZnAbSCBRkcAccSN9u7XG86G3yaz6rA@mail.gmail.com> <CAOj+MMGn-N+qBkYGPMDzUvHCPgn_cQ3xsttjhAvhmabys0nsOQ@mail.gmail.com> <CA+wi2hMDwXnT8LdDVo+xQvcD9NwXNhnNguCywxEQNXP4k+Vd3g@mail.gmail.com> <CAOj+MMFqNG03Bo3PBhyq+9LFPg9E=ExEMEnJbHeG_SGQLLj+1g@mail.gmail.com> <CA+wi2hOjaZGVVJYDLESsn6Quj-ZBk6ouGT-1Um9AOZduibRrZA@mail.gmail.com>
In-Reply-To: <CA+wi2hOjaZGVVJYDLESsn6Quj-ZBk6ouGT-1Um9AOZduibRrZA@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-06-13T12:51:56Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ActionId=6db80402-9fe6-4ac7-8f15-3507f3db0e34; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2
x-originating-ip: [10.115.27.53]
Content-Type: multipart/alternative; boundary="_000_3cf4e891a6fc4922b1da262e7fead11aorangecom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/P_GwpqIjG_e0185Wr6kaqmTHiEA>
Subject: Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jun 2022 12:52:05 -0000


From: Idr <idr-bounces@ietf.org> On Behalf Of Tony Przygienda
Sent: Wednesday, June 8, 2022 10:32 PM
To: Robert Raszuk <robert@raszuk.net>
Cc: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org>; idr@ietf.org; Susan Hares <shares@ndzh.com>
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 <robert@raszuk.net<mailto:robert@raszuk.net>> 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 <tonysietf@gmail.com<mailto:tonysietf@gmail.com>> wrote:


On Wed, Jun 8, 2022 at 8:47 PM Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> 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.