IETF Logo Mail Archive

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 17:29 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 4A605129713 for <idr@ietfa.amsl.com>; Tue, 18 Oct 2016 10:29:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.945
X-Spam-Level:
X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no 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 cL8zSn7Zkjg9 for <idr@ietfa.amsl.com>; Tue, 18 Oct 2016 10:29:30 -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 346F4129666 for <idr@ietf.org>; Tue, 18 Oct 2016 10:29:30 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.187.221.190;
From: Susan Hares <shares@ndzh.com>
To: 'Nick Hilliard' <nick@foobar.org>
References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org>
In-Reply-To: <5806484F.5080006@foobar.org>
Date: Tue, 18 Oct 2016 13:27:37 -0400
Message-ID: <010a01d22964$ec1233d0$c4369b70$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGxOA6e5ti/ZI3ng6LJlnwAiipARgH9+98qoOBo/uA=
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ZiFG_jBoBsr9wglKSWIcVY2j1Go>
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 17:29:31 -0000

Nick:

In my understanding, all deprecations are temporary.   A vendor range for
attributes is something that is possible if the working group wishes.  

I do agree operators should beacon 31 or 32.  

Sue 

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Nick Hilliard
Sent: Tuesday, October 18, 2016 12:06 PM
To: Susan Hares
Cc: 'IETF IDR WG'; 'Kristian Larsson'
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)

Susan Hares wrote:
> IDR should recommend that the following attribute numbers be deprecated:  
> 
> BGP Attribute 30
> BGP attribute 129

unless this is a temporary deprecation, I'm not sure if this is a good idea,
as it could be interpreted as sending a message to vendors that squatting
path attribute code points will result in being told, "that's very naughty
and we're going to punish you by ensuring that no-one else gets these
numbers, so don't do it again!"

There is an objective problem here, namely that there is no vendor-specific
range for path attributes.  Given the nature of path attribute
interpretation, it could be argued that this might be a good thing because
different vendors will interpret TLVs in different ways, which is a
potential source of bgp session instability.  On the other hand, it means
that if vendors need to go off and do something new, there are no options
other than squatting.  A vendor-specific range will at least contain this
problem, so that IANA won't run into the same problem in future.

On a related issue, it would probably be a good idea to run beacon tests
with other path attributes to see how they affect reachability, i.e.
have any other vendors squatted any other path attribute values, and if
large-communities is moved to 31 or 32, will it suffer the same problem?

Nick

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

v2.23.0 | Report a Bug | By Email