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

Robert Raszuk <robert@raszuk.net> Fri, 30 October 2020 13:53 UTC

Return-Path: <robert@raszuk.net>
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 143BB3A0EBE for <idr@ietfa.amsl.com>; Fri, 30 Oct 2020 06:53:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 yH6nG2VeSd98 for <idr@ietfa.amsl.com>; Fri, 30 Oct 2020 06:53:56 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4F573A0EBC for <idr@ietf.org>; Fri, 30 Oct 2020 06:53:55 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id y184so6027279lfa.12 for <idr@ietf.org>; Fri, 30 Oct 2020 06:53:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sBwoWY6YBzHwLdGshECgumuGHf7SHkIk4nEZVCv7S6I=; b=aboo7J228UV+4kIHPQJxg8do+6fH6ZsapZ/FHsdc/1jSkGRNA0DMHUNX16eH4KEpCB lFdKgciLCv9Ugt8nOSXPt6Yhx7zLIc6vNBMjweR1DkjhzM5H8Otq1NdQV+ZEb7I7J3H8 jzboLe64GNfadgfiAhZ57auQa34jPxMx63136fjIBRQlFlcKeyyBJcjjkep3r85pYVcl Ha6Y/1tK24y1h3qv/fd3oYuJF7jwV2XbHI/sbK4IRqOXM5tIZHqRyGBfr0RBFkmLjdvf zAJElzgSHY2gRXDZz4hkpDwUCWcBIsZny2egyY+0tJ7KV9TxdYv21LvPgxXBkfZJWnv0 JD3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sBwoWY6YBzHwLdGshECgumuGHf7SHkIk4nEZVCv7S6I=; b=pa4Tyfyzqka8v7r/s1zwVybg1XbgESJYacGn5x7BLAzFfsfAqK/nXxUdokVO85nvnP B7HGcWwHgkm/E5PgJxEXaIu+PGRAVJGwuUHHKGn73encfL7niWg4rnIRsXBaICCD5URb sMg37zf7qriiqHoOZksAd405SOhXC58Rma054bKfTstBIq4XR5HcNfhkxoKuHixNvyNK /+41IWtgDpw3k6e/XFGlK9jglZhjQeNZnHbYbMAV1+X8+9kQDln3qF0Jfjh25Y/A/Fs7 VSEmxggDw6iZrbfeaq1smN2Q9Ra/6IIX3rYnIm91k8QpYZzZkARoV7uF3xB+3Z+34307 QZtw==
X-Gm-Message-State: AOAM532kom3i4l8QS7l4ZNw0d91W75ZOEOnGrITuk6dp3iqS/m33NVI6 XmOdG0uXH3pdzF7AUhyfmb/wPkfA6tBsT8gOtKlTf74PbsQ=
X-Google-Smtp-Source: ABdhPJyAt0TD3UxX6b+bZIiPM4clFcwCsRTRkdRw9CU3eAyLc6bv9sKkoZsxYYwRgCMmdp0O3ekSI7w1eQYG4FxHfhk=
X-Received: by 2002:a19:87c3:: with SMTP id j186mr939238lfd.574.1604066033429; Fri, 30 Oct 2020 06:53:53 -0700 (PDT)
MIME-Version: 1.0
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> <8560_1604052018_5F9BE432_8560_210_1_53C29892C857584299CBF5D05346208A48FDBBFD@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
In-Reply-To: <8560_1604052018_5F9BE432_8560_210_1_53C29892C857584299CBF5D05346208A48FDBBFD@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 30 Oct 2020 14:53:43 +0100
Message-ID: <CAOj+MMGn1sZhyBxFaWjoT3xhhCjr25ZzjC-r9OWdcrsbDSNs1w@mail.gmail.com>
To: Bruno Decraene <bruno.decraene@orange.com>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>, "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>, Jeffrey Haas <jhaas@pfrc.org>, John Scudder <jgs=40juniper.net@dmarc.ietf.org>, IDR List <idr@ietf.org>, Donatas Abraitis <donatas.abraitis@hostinger.com>
Content-Type: multipart/alternative; boundary="0000000000001e85e005b2e3ba3c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/RiakbFHX9FarZyKaccO5CuV9-qo>
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 13:53:58 -0000

Hi Bruno,

Yes it could be well known pointer indeed. So all would be required in such
a case is a one bit flag (perhaps indicating that such info is here and
waiting for collection. That's sort of ultimate compression :)

We could also generalize it a bit and have such pointer to a json file.
Such file may in turn contain number of nested objects one of them
perhaps defined in the subject draft could describe BGP-OS related info.
Some other extension could add local GPS coordinates of the BGP speaker etc
...

Moreover fetching such information could happen either inbound of already
established TCP session for BGP or out of band by different TCP session. In
the former case as a bonus all security related concerns go away :)  We
could also allow both methods such that mgmt station could fetch such
information directly outside of the routing protocol channel.

Thx,
R.

On Fri, Oct 30, 2020 at 11:00 AM <bruno.decraene@orange.com> wrote:

> 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>gt;; '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
> <idr-bounces@ietf.org>] *On Behalf Of *Jakob Heitz (jheitz)
> *Sent:* Friday, October 30, 2020 6:18 AM
> *To:* 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>gt;; Donatas Abraitis <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> *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, October 29, 2020 4:31 AM
> *To:* Jeffrey Haas <jhaas@pfrc.org>
> *Cc:* John Scudder <jgs=40juniper.net@dmarc.ietf.org>rg>; IDR List <
> idr@ietf.org>gt;; Donatas Abraitis <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.
>