Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25)

Susan Hares <shares@ndzh.com> Tue, 18 October 2016 21:41 UTC

Return-Path: <shares@ndzh.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 BC0F512989B for <idr@ietfa.amsl.com>; Tue, 18 Oct 2016 14:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no
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 SzeYw-zqaVsy for <idr@ietfa.amsl.com>; Tue, 18 Oct 2016 14:41:05 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 DBB461298C6 for <idr@ietf.org>; Tue, 18 Oct 2016 14:40:53 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.137.219.91;
Date: Tue, 18 Oct 2016 16:40:44 -0500
Message-ID: <0aqugaxqujqb9pjsxq892t95.1476826844624@email.android.com>
Importance: normal
From: Susan Hares <shares@ndzh.com>
To: Robert Raszuk <robert@raszuk.net>, Jeffrey Haas <jhaas@pfrc.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_5308894176352130"
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/U0DO5BZQQ78tLlHos8-bm671O5E>
Cc: IETF IDR WG <idr@ietf.org>, Kristian Larsson <kll@dev.terastrm.net>
Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25)
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: Tue, 18 Oct 2016 21:41:08 -0000

Robert
See the iana rules on how long early allocations can be kept and renewed.  RFC was listed in earlier email.
Sue

Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone
-------- Original message --------From: Robert Raszuk <robert@raszuk.net>; Date: 10/18/16  3:50 PM  (GMT-06:00) To: Jeffrey Haas <jhaas@pfrc.org>; Cc: Job Snijders <job@instituut.net>;, IETF IDR WG <idr@ietf.org>;, Kristian Larsson <kll@dev.terastrm.net>;, Sue Hares <shares@ndzh.com>; Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) 
Hi Jeff,
IDR has a rule to progress any doc which demonstrates two implementations. That means that each draft which requires new BGP attribute and is accepted as an IDR WG doc should get IANA code point such that implementations could be delivered without risking any further inter-operability or deployment issues. 
Not sure how long WG should wait before such code point is depreciated though ... but without it being allocated in some way it is going to always be a challenge.
/RR.

On Tue, Oct 18, 2016 at 10:42 PM, Jeffrey Haas <jhaas@pfrc.org>; wrote:
Robert,
On Oct 18, 2016, at 2:14 PM, Robert Raszuk <robert@raszuk.net>; wrote:

I would tend to agree with Job here. 
I see no point to reserve already known to be "overloaded" code point for wide or for that matter any new BGP attribute. 
That's the price we pay for no BGP Police or BGP FBI/GBI  ... (G=global)
To clarify my original point, I think holding onto it for early allocation makes sense.
Whether or not the code Huawei is working on is ready for such an allocation is a different matter.  But if the code point is otherwise associated with the feature, incremental rollout issues aside, seems reasonable to not waste that code point.
-- Jeff (I don't feel super strong about this, but see other threads)