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)

"Jakob Heitz (jheitz)" <> Wed, 26 October 2016 05:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 517B812970A for <>; Tue, 25 Oct 2016 22:51:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.951
X-Spam-Status: No, score=-14.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7y-5uN4NWEzV for <>; Tue, 25 Oct 2016 22:51:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92C5D129621 for <>; Tue, 25 Oct 2016 22:51:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=15169; q=dns/txt; s=iport; t=1477461111; x=1478670711; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6hK+8rwLwbDBhAbXBZEGDlvABqD7MucceSCwdB4jb/A=; b=XmHGDrgvfEdwmcTsuG3WrYzI0i0d+tFynbCEpZOdsHzaBtnOktX+LE9E 4ptCpB7vI13e2zHn4vwU7/mUrfI9BK9Zu5ZHoKNBEHBo8AdKo/Le6zRo4 Awi1WyByZssup1O3BBj8WhCqKqhmkjEmMDHJFkPnCRTMcKDDIeNo5/tc0 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.31,549,1473120000"; d="scan'208,217";a="338459597"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2016 05:51:50 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u9Q5poUj001192 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Oct 2016 05:51:50 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Oct 2016 00:51:44 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Wed, 26 Oct 2016 00:51:44 -0500
From: "Jakob Heitz (jheitz)" <>
To: Christopher Morrow <>
Thread-Topic: [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)
Thread-Index: AdIt7WzqvhUzKEQ4QuObgT18xFaIJQBIJyAwABHPSoD//++DIQ==
Date: Wed, 26 Oct 2016 05:51:44 +0000
Message-ID: <>
References: <1d8301d22df0$cee63500$6cb29f00$> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_677CE346EFED42B68A9F75ABD2B4D6B4ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, Susan Hares <>
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-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Oct 2016 05:51:54 -0000

Because then we wouldn't own up to it and innocents would suffer.
We would hope we could fix as much of it as possible and hope the rest wouldn't notice.
Actually, the intended purpose of the NXOS line is for the data center, not the Internet and we can very likely fix all of the deployed ones. However, users have a right to deploy them wherever they want without notifying us and they have the right not to apply patches, so I chose to own up to the problem.
Honest, we didn't mean it. Sorry.


On Oct 25, 2016, at 6:50 PM, Christopher Morrow <<>> wrote:

So, what's the downside to having IANA pick the next available (from the current list, prior to the 2 squatting incidents) value in cases like this?

I think it's: "Some routers somewhere do bad things"
  (or sometimes cause other remote people to do 'bad things' .. where sometimes that other person is 'me')

and when that happens: "some people quickly upgrade code to avoid the 'bad things'"
(presuming that the code is available, I mean... and I do hope that vendors, all of them, are telling their DE folk: "Hey, don't do this, it's super painful...srsly!")

Is that about it? Why don't we just go back to assigning the next available and deal with the problem(s) as they arise?


On Tue, Oct 25, 2016 at 6:27 PM, Jakob Heitz (jheitz) <<>> wrote:
I have discovered that Cisco has used BGP attribute code 31
for an internal experiment in certain NXOS routers,
but unfortunately some of the code leaked into production.
The code does not send the attribute,
but it receives it incorrectly. We are creating patches for the
faulty code, but cannot guarantee that all affected routers will
be patched. Consequently, we request deprecation of attribute
code 31 as well.

I apologize on behalf of Cisco for the oversight.


From: Idr [<>] On Behalf Of Susan Hares
Sent: Monday, October 24, 2016 5:19 AM
Subject: [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)

IDR Working group:

Thank you for your input on the question of whether Large communities should be reassigned another attribute number due to Huawei squatting on attribute 30.  The WG consensus is that the IDR WG wishes to have IANA deprecate attribute 30, and reassign large communities another attribute number for its early allocation.

Alvaro should request a new attribute number for wide communities.

If wide communities implementers request an early allocation, the WG consensus was unclear.  Therefore,  the code point of 129 is deprecated for now.  The full discussion on this point is at:

The following other attributes were seen in the wild with the comments we saw:

#        BGP function                                      Reference
----    -----------------------------------------------   ---------------
20     Connector Attribute (deprecated)   [RFC6037]
21      AS_PATHLIMIT (deprecated)           [draft-ietf-idr-as-pathlimit, unknown]
30     (deprecated)                                       [variant of draft-ietf-tunnel-encaps, Huawei router]
129   (deprecated)                                       [draft-ietf-idr-wide-bgp-communities, Huawei router]

Attribute  AS Attribute Observed
-----------   --------------------------------
20           AS 22742  (Peter Hessler)
21           AS 14706, AS 11720, AS 22490

30   -  in trials reported by Job
129 -  self-reported by Huawei

Sue Hares

Idr mailing list<>