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

Robert Raszuk <robert@raszuk.net> Wed, 23 September 2020 20:00 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 033593A1444 for <idr@ietfa.amsl.com>; Wed, 23 Sep 2020 13:00:04 -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 j5G24r1xfb8h for <idr@ietfa.amsl.com>; Wed, 23 Sep 2020 13:00:00 -0700 (PDT)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 A79C83A1443 for <idr@ietf.org>; Wed, 23 Sep 2020 12:59:59 -0700 (PDT)
Received: by mail-ej1-x633.google.com with SMTP id u21so1346854eja.2 for <idr@ietf.org>; Wed, 23 Sep 2020 12:59:59 -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=1qyV12MBQVT2xmh3wRSZ5GUPJnVphw3akkHiLT7iMfo=; b=BaE0KBnu41ucygyyQyVLQSXdzszqWSTnROLCXfZzGVQk9uogLxjO/aPArnZp83ozP5 ThryfRbYLiIaDsHJLaBrQtHot6U2jeD8AlbotnBmu37IilRzpx62wd5is/e2otyPaok+ iakXYbNYg7WY58u2b5Y78cMjuy80kVXZ7+a5f5TauJBBLxsP5BYWPJ0AEyFNHE3yw1nK xQIdfWTYuRxSEpp/VV0s/tsxF+T7DXng5dljguIXD47od2SMMTyVJlI+/5DqYh0hoWTd C7wqZBb6gDmdK3EtPydTMFMeml+Lp5RjSyLVzFOCdVcs60WjdulqmqHFesKWVShcAG0d JuAA==
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=1qyV12MBQVT2xmh3wRSZ5GUPJnVphw3akkHiLT7iMfo=; b=ANxcrThpLVRwIjyJMRqtB7LD9JKW7H82kFkfpD51irHlki1a4zTR5xVQ8I5qd2ibU4 nBgsuRo+eLF22b7I5GMe64ef6v+fBQs5wZuv2seBGZCAFyr/VRxot+Y7JgrL63D9mWo5 gy7D8FkvGW63ZBJMGgSrnsYffd3QcHjBp0zhT0FBvhbH6NgCWh1h//zjNo+dlYnFMHnO kAcXng9Yr3KFDJWm4RthdEFhWmZVdgerD3CrTj1OiLLdjX9RDBTMvZnud2LLLD3+AAHA SJZx9bTzkA//DGTQVWsagVXVPxlrdr7MCE2SPkt+IqCc7SkD1qT0PCG53mg/LY5F3Aq5 RrMg==
X-Gm-Message-State: AOAM53257d6XSannhUBcvCEKt9cP/wos0QlqIC79nSXzGO0vORnfwY61 SKbnLyA1ljo57/O/cBWphKf7pwBn1MnyO6VF74bdyQ==
X-Google-Smtp-Source: ABdhPJzQ5JNK7mqaz6w2S1r/gntDYkXiWdBcxGSkS0uhNUsJ7CBgleVVw/zdZyF44UxtsfWiJREjGy7IVrGewFL+D7w=
X-Received: by 2002:a17:906:7f15:: with SMTP id d21mr1291928ejr.470.1600891197745; Wed, 23 Sep 2020 12:59:57 -0700 (PDT)
MIME-Version: 1.0
References: <081E5E98-8D7B-452E-8517-EECBE72E3D7F@juniper.net> <8EFAFA50-BEAC-4F8C-A2CB-293225B3D529@juniper.net>
In-Reply-To: <8EFAFA50-BEAC-4F8C-A2CB-293225B3D529@juniper.net>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 23 Sep 2020 21:59:47 +0200
Message-ID: <CAOj+MMGdSR0+yrzdgLdNhTVVsnO6ZLbNrv_oLiENTdy5f1X-KA@mail.gmail.com>
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org>
Cc: IDR List <idr@ietf.org>, Donatas Abraitis <donatas.abraitis@hostinger.com>
Content-Type: multipart/alternative; boundary="0000000000002a8aa405b00087c5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/zm7dUWYaTpLUa6c5WYdrRo1ry9g>
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: Wed, 23 Sep 2020 20:00:04 -0000

Hi John,


> - Does the WG want to put work into fixing the problem, of sending version
> information to a peer? I think if the question were limited to that, the
> consensus would probably be “yes”.
>

Even that question is a bit loaded IMO

Say yes maybe I see the value of sending this between 100s of virtual peers
and a TOR. But is BGP main used this application ?

On the other hand I see limited value to just send it between client and RR
... I would rather like to see passed between clients.


> - Does the WG like this approach? So far the responses I’ve seen divide
> into a “pragmatic” camp (it’s quick and easy, let’s just do it), and an
> “architectural” camp (let’s have a more general solution with fewer corner
> cases). I’m not sure it will be possible to reach consensus between these
> two views, but I don’t think we’ve tried very hard yet.
>

Frankly I have not seen much support except from Jakob for encoding it in
capabilities. And that support comes mainly from the fact that "it is easy
to do".

Thx.
R.

PS1. And on the other hand if it is not adopted here it will likely get
published as an RFC anyway in the ISE track. So honestly I have no idea
what's best for BGP. If it would be my call in such a situation I would
perhaps recommend to adopt it and repackage in a different encoding
envelope. But who will work on it if authors would not be interested to
change the draft once it becomes a WG doc ?

PS2. Assume this goes on as ISE RFC. And perhaps magic happens and IDR
defines a different encoding for exactly the same information down the
road. Would IDR or GROW have power to move ISE RFC to historic or obsolete
status at that point ?



> I have a lot of sympathy for keeping it simple, but as Einstein may or may
> not have said, “everything should be made as simple as possible… but no
> simpler”. We are asked to decide whether the current draft is “as simple as
> possible” or even simpler. From that point of view, if you think it’s too
> simplistic, it would be helpful for you to explain what specific harm its
> excessive simplicity causes, and what you’d prefer as a “simple as
> possible, but no simpler” alternative.
>
> Thanks,
>
> —John
>
> > On Sep 8, 2020, at 3:11 PM, John Scudder <jgs=
> 40juniper.net@dmarc.ietf.org> wrote:
> >
> >
> > Hi All,
> >
> > You may recall that we had a recent discussion about
> draft-abraitis-bgp-version-capability-07, which was on the ISE track. After
> some discussion both on and off list, the author has updated the document
> and requested WG adoption of
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-abraitis-bgp-version-capability-08__;!!NEt6yMaO-gk!WoDk_v2eZvQXLUQzQJ6wuGJfnX3PrXgjTEuSzOrPZemMeRV2jticFxEkbOH_dg$
> .
> >
> > This begins the usual two-week discussion period. Please send your
> support, opposition, comments, discussion, before September 25.
> >
> > The recent thread is here:
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/idr/q4pUI7jKnYEL_5Cr0mUfoHopY74/__;!!NEt6yMaO-gk!WoDk_v2eZvQXLUQzQJ6wuGJfnX3PrXgjTEuSzOrPZemMeRV2jticFxGnDkHeFQ$
> and an earlier thread, when Donatas first brought the subject up on the
> list, is here:
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/idr/zHNioWl24mdTthQA0O4OatZ2uy4/__;!!NEt6yMaO-gk!WoDk_v2eZvQXLUQzQJ6wuGJfnX3PrXgjTEuSzOrPZemMeRV2jticFxG1g7uXDA$
> >
> > It’s my impression from these two threads that there’s potentially
> interest from the WG in tackling the problem; it’s less clear to me that
> the WG supports the particular design outlined in the current draft. It
> would be helpful if you’d address both of these when commenting, and keep
> in mind that as usual WG adoption of the draft wouldn't mean “this is the
> exact solution”, it would mean “this is a good starting point.” Finally, as
> a result of the recent discussion, there’s been some renewed interest in
> draft-ietf-idr-operational-message. One suggestion (which I can’t put my
> finger on in the archives right now, sorry) was to turn
> draft-ietf-idr-operational-message into a pure framework document, i.e.
> define no TLVs in it, just the transport. If done, IMO that might open the
> door to more easily allowing a draft like the present one to adopt it as a
> transport.
> >
> > The floor is open for your comments!
> >
> > Thanks,
> >
> > —John
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>