Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..)

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 27 October 2016 19:05 UTC

Return-Path: <brian.peter.dickson@gmail.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 4393C1296D7 for <idr@ietfa.amsl.com>; Thu, 27 Oct 2016 12:05:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GJnzJSdUff5L for <idr@ietfa.amsl.com>; Thu, 27 Oct 2016 12:05:04 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 8C551129781 for <idr@ietf.org>; Thu, 27 Oct 2016 12:04:14 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id b80so52752368wme.1 for <idr@ietf.org>; Thu, 27 Oct 2016 12:04:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tw56l3CQTRGF3gQrs8vWuEeHMQkvIKR3s4TWFRAl6To=; b=Z/KEYTWCCUxhDFsh/fN8Ky68vpWUiUxXgBfuos5jsGGzfheS1+jcpj9eJMKx4KnSup xvTmZ/OUtjMMjH8xoMFW+Fj9tk/FZQBTdF4htepnHE9mCoZNUTL7c2hDvuSIaMg8jiOY TNrTNrZXqQzahu5AucF75gUGsNfZjIA3cN0DU2D4zT0e3VHL+0P04CW6KeeiKKl86Qcq lnEiPobbByyAWrZP6k8ICJHvaWzHgopQr6PGxnJU6XLYntAZnGNbg626YXvWDVwATMWE XmWinNSuUZ8VkqZ46H0aeG8BRW4mzzyxCymIhtRraWV863AWt5wumAnWk+iXIw+dxxJE xXAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tw56l3CQTRGF3gQrs8vWuEeHMQkvIKR3s4TWFRAl6To=; b=L/uyWUHuIh5g6EPzFkq2YMiYbrsILyXXZsSrab51e70vj9vGTYeGK9thoO8eGCa7Y6 gDP7AEyhyvmW7PvpkcxssqK4B8hCtKTy49Mi87/gHplUG+fTMWrgLZgtoLyA0++bXJdI eBMMMFd3+hBkmGhnvgtKkIkJI3FbEMQUqoLRIHeLCIuFz0+UxeVvjoCyRY06/+Kp+UB9 SaTcM3G+dzDCNayZLT+VQMTnV2ZrUw0xlGs/3bc6tar4kQdiFHwQRE89fyQBKgHIKPSa 9e6eBABekNW7Cp2aeZElgW19U1MwIx+vckU7i9jYTwvYKyzp/lU/9lSI7WsWLlG85Bkc 17vg==
X-Gm-Message-State: ABUngvcQMq1SMThFJxWw9qk8QRJIQz3YP1tmwkmiK6EBu16kwvKoekhcrqhgXeb5hoFeei8tArJGgvRJkIEQng==
X-Received: by 10.28.222.70 with SMTP id v67mr200545wmg.84.1477595052953; Thu, 27 Oct 2016 12:04:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.203.207 with HTTP; Thu, 27 Oct 2016 12:04:12 -0700 (PDT)
In-Reply-To: <20161027095404.GP37101@Vurt.local>
References: <20161026165710.GC58742@shrubbery.net> <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <db7a17a288aa4a3288dc6ec8f032b687@XCH-ALN-014.cisco.com> <CAL9jLaZcCwBhUEs7cvsx3HfiPSRPXrcvOguCeuV2opSns9OZMw@mail.gmail.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <EBCE3CE8-1295-4CB2-9A1A-8BA2E154033D@gmail.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <20161027095404.GP37101@Vurt.local>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 27 Oct 2016 12:04:12 -0700
Message-ID: <CAH1iCipJNye8fpvFwBwoLkL3+=rWVcZac2BUFVcJXQ_9YTrXvg@mail.gmail.com>
To: Job Snijders <job@ntt.net>
Content-Type: multipart/alternative; boundary="001a114b103c40dc66053fdd68d4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/CpXtfz8t-eNJPAyzEHPCZ0T1gv0>
Cc: heasley <heas@shrubbery.net>, IETF IDR <idr@ietf.org>, Susan Hares <shares@ndzh.com>
Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 27 Oct 2016 19:05:06 -0000

On Thu, Oct 27, 2016 at 2:54 AM, Job Snijders <job@ntt.net> wrote:

> On Thu, Oct 27, 2016 at 11:20:38AM +0200, Sander Steffann wrote:
> > Op 26 okt. 2016, om 19:32 heeft marco@lamehost.it het volgende
> geschreven:
> > > October 26, 2016 6:57 PM, "heasley" <heas@shrubbery.net> wrote:
> > >> Wed, Oct 26, 2016 at 12:43:23AM -0700, Brian Dickson:
> > >>
> > >>> Rather than deprecate the two sequential values, why not reserve a
> > >>> small range which includes those values, for non-permanent
> > >>> reservations for vendor development use? Say 30-35 inclusive?
> > >>
> > >> isnt this bgp path attribute 255?
> > >
> > > I was suggesting the same thing out-of-list today.
> > > We should really assign ~5 values to experimental/development puroposes
> >
> > I think this would be useful both to allow for larger-scale testing of
> > new attributes, and for vendors to be more easily be able to test
> > multiple new attributes in-house.
>
> The problem here is that people are not abiding the rules, and offering
> more codepoints will only work if people abide those rules. I have no
> confidence that more dev codepoints resolve the issue.
>

The counter argument is very simple: If we don't offer more code points,
they *definitely* won't use them (and thus abide by the rules).

The consequence of offering already-squatted code points for this purpose,
is that it makes it possible to abide by the rules (if they need multiple
code points
simultaneously).

If the number of squatted code points was truly significant, compared to
the pool
of code points, I'd say concern would be warranted, but we aren't at that
point,
IMHO.

 (Significant, by my estimate, would be ~10% total, or ~10% of remaining,
or at a run-rate of > 5% of remaining per year. Those are roughly 25, 20,
and
10/yr respectively. We've seen 3/yr this year, but it is anomalous when we
consider the last 20 years.)

Providing a non-trivial, but small, fixed pool, would not be harmful, and
would
provide both a good way of enabling those who want to play by the rules, and
greater visibility to who the parties are. If squatting continues after
that pool
is established, then we should think about what to do. Doing so now, is
probably
premature.

Brian