Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

bruno.decraene@orange.com Fri, 30 October 2020 10:00 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 0614F3A0D91 for <idr@ietfa.amsl.com>; Fri, 30 Oct 2020 03:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXlbqvKoHqAg for <idr@ietfa.amsl.com>; Fri, 30 Oct 2020 03:00:20 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB1F3A0D93 for <idr@ietf.org>; Fri, 30 Oct 2020 03:00:20 -0700 (PDT)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 4CMyVB4d4Xz7tL9; Fri, 30 Oct 2020 11:00:18 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1604052018; bh=KlcKjqO8unOx/lHPpmkatUi1WtPO8kJNFyEhZJAfohI=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=MP20uTSJQ/UIlP7e3HcG2wcEx0oIOUhIyx8gbZRDoo7v2TRhFwEsd3W0gFjkujnEy oa6djm1dyYO5NHXQM5PhsnOlkkNl8Yy3qIntdEZ7XntjKx4acRJ+BCy2kBpjXiVLtd CW9ghf1ZoCLLt0Wpv95EkEC2TsVrbWsrpdil9R27T39xftjm4OSPcT1SaBWHuaMVKM bmi1mjlq2PEaU9nkRjVwcPl5hL8xAjpU8clI3B4Ca9htxAq3np7CqMNFLNZC4/73gI ZiKjpyCtx93ji9HxwM5SRHiA8jbJEz4He5UUQnqZyXDKyK9b8xUQLuRZG8iWx4xtoS FRsIQPkpKHeLw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 4CMyVB2fDZzCqks; Fri, 30 Oct 2020 11:00:18 +0100 (CET)
From: <bruno.decraene@orange.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>, "'Jakob Heitz (jheitz)'" <jheitz=40cisco.com@dmarc.ietf.org>, 'Robert Raszuk' <robert@raszuk.net>, 'Jeffrey Haas' <jhaas@pfrc.org>
CC: 'John Scudder' <jgs=40juniper.net@dmarc.ietf.org>, 'IDR List' <idr@ietf.org>, 'Donatas Abraitis' <donatas.abraitis@hostinger.com>
Thread-Topic: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25
Thread-Index: AQHWlcPPSkgfBrYsfkmOoQ0fOdVLAqmtvfAAgACv0ICAADVOAP///3EAgACzxKCAAE/7AIAAas3g
Date: Fri, 30 Oct 2020 10:00:17 +0000
Message-ID: <8560_1604052018_5F9BE432_8560_210_1_53C29892C857584299CBF5D05346208A48FDBBFD@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <081E5E98-8D7B-452E-8517-EECBE72E3D7F@juniper.net> <64E754F4-CB63-4F2E-92A3-43ADEA1EC4AB@juniper.net> <20201028215313.GA8863@pfrc.org> <CAOj+MMFH35TB10gpeX80645qEZF3irFk0XVyyLZzkXagcTtwAA@mail.gmail.com> <20201029113316.GB8863@pfrc.org> <CAOj+MMHvVgP0SSTSLqcUHizfk_kR1tUjo0u8p3AnKiuHFr=VaQ@mail.gmail.com> <BYAPR11MB3207AE20610604C5310C0BBAC0140@BYAPR11MB3207.namprd11.prod.outlook.com> <007c01d6ae71$4513eec0$cf3bcc40$@tsinghua.org.cn>
In-Reply-To: <007c01d6ae71$4513eec0$cf3bcc40$@tsinghua.org.cn>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A48FDBBFDOPEXCAUBM43corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/fwWWUlAEhqtzGn0Sm2K1DcbR0Cw>
Subject: Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 30 Oct 2020 10:00:23 -0000

Now could this be a static pointer?
e.g., standardized OID, well-known URI [1], standardized yang model?

That would probably still require an RFC, but no change to the BGP protocol, nor eating space in the capability, no mandatory 2 implementations…

Bruno

PS: Not that I care for the feature ; either way. N
[1] +IP address of the peer. Possibly with some access control restriction (source IP of the configured peer, AS of the configured peer, TTL hack, possibly TCP-AO like for BGP although at this point I’m well beyond ultracrepidarian [2] )
[2] https://dictionary.cambridge.org/fr/dictionnaire/anglais/ultracrepidarian?q=ultracrepidarian (for non-native speakers like me)


From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Aijun Wang
Sent: Friday, October 30, 2020 5:01 AM
To: 'Jakob Heitz (jheitz)' <jheitz=40cisco.com@dmarc.ietf.org>rg>; 'Robert Raszuk' <robert@raszuk.net>et>; 'Jeffrey Haas' <jhaas@pfrc.org>
Cc: 'John Scudder' <jgs=40juniper.net@dmarc.ietf.org>rg>; 'IDR List' <idr@ietf.org>rg>; 'Donatas Abraitis' <donatas.abraitis@hostinger.com>
Subject: Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

Putting the pointer for the static information for further diagnosis into the capability code is better than putting the static information themselves.
The peer just want to know something about the other peer, let it achieve this by the information pointer.


Best Regards

Aijun Wang
China Telecom

From: idr-bounces@ietf.org<mailto:idr-bounces@ietf.org> [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz (jheitz)
Sent: Friday, October 30, 2020 6:18 AM
To: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>; Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>
Cc: John Scudder <jgs=40juniper.net@dmarc.ietf.org<mailto:jgs=40juniper.net@dmarc.ietf.org>>; IDR List <idr@ietf.org<mailto:idr@ietf.org>>; Donatas Abraitis <donatas.abraitis@hostinger.com<mailto:donatas.abraitis@hostinger.com>>
Subject: Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

Hey Robert,

That's a super cool idea. I like it.

Regards,
Jakob.

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Robert Raszuk
Sent: Thursday, October 29, 2020 4:31 AM
To: Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>
Cc: John Scudder <jgs=40juniper.net@dmarc.ietf.org<mailto:jgs=40juniper.net@dmarc.ietf.org>>; IDR List <idr@ietf.org<mailto:idr@ietf.org>>; Donatas Abraitis <donatas.abraitis@hostinger.com<mailto:donatas.abraitis@hostinger.com>>
Subject: Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

Just to clarify one point ... I was not seeing a need to use domain names. Just either IP address of bgp peer or implicitely use bgp peer's address.

https url would be actually pretty short ... just the path to the opaque text.

I am more interesting on your view of how to do NSR/ISSU with current proposal.

Cheers,
R.



On Thu, Oct 29, 2020, 12:18 Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>> wrote:
Robert,

On Thu, Oct 29, 2020 at 09:22:29AM +0100, Robert Raszuk wrote:
> > - I think requiring extended optional params is a good idea for this.  It
> >   mitigates the necessity for having to do do the math to squeeze stuff in
> >   or not.
>
> How about we would just carry a fixed size URL reference to this
> effectively static and opaque to the bgp protocol information instead of
> actual text string ?

I think this is problematic in a few senses:
- Sure, you could take this idea to the extreme that we'll just have a
  single four-byte field with a FCFS registry that everyone uses and has
  private space for a local registry.  And people would hate that.  You're
  devolving to pre-registration for something that may change frequently.
- Sure, you could just reserve char version[64] in the structure, but domain
  names may vary in length.  And when you move to punycode i18n domains,
  this could be even messier.  See prior issues with RFC 8203.
- I strongly expect that some operators will want to stick in their own
  strings here.  "Role" potentially in combination with "version".

> IMO anything which is static and is not needed for protocol operations,
> best path selection etc ... should be passed as a pointer.
>
> Fetching such string could be done in spare CPU times well before need to
> locally present it or at the run time when someone executes a show cmd or
> other form of query api.

Which is really a lot of typing to say "we're not exchanging this out of
band ... why?"  Which is still a legitimate argument.  It's why I think the
use case, although slightly helpful, has a lot of weaknesses.

The one slight boost I give the core use case that we're regularly seeing in
data center cases is protocol stacks are being spun up with very little
additional components. This provides a push to consolidate channels for
sending critical information.

-- Jeff

_________________________________________________________________________________________________________________________

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.