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)

Kristian Larsson <> Tue, 18 October 2016 15:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 90FBB1296B2 for <>; Tue, 18 Oct 2016 08:49:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WUsbT8xNOYkP for <>; Tue, 18 Oct 2016 08:49:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 571401296B9 for <>; Tue, 18 Oct 2016 08:49:05 -0700 (PDT)
Received: from Kristians-MacBook-Pro.local (unknown [IPv6:2003:1b3b:ffde:1::5]) by (Postfix) with ESMTPSA id 03F9E3A011F; Tue, 18 Oct 2016 17:49:03 +0200 (CEST)
To: Michael H Lambert <>, IETF IDR WG <>
References: <01f401d22950$7f988470$7ec98d50$> <20161018153047.GJ95811@Vurt.local> <>
From: Kristian Larsson <>
Message-ID: <>
Date: Tue, 18 Oct 2016 17:49:03 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Approved-At: Tue, 18 Oct 2016 08:55:04 -0700
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: Tue, 18 Oct 2016 15:50:08 -0000

On 2016-10-18 17:44, Michael H Lambert wrote:
>> On 18 Oct 2016, at 11:30, Job Snijders <> wrote:
>> I support this course of action.
>> background: Some in the working group might wonder why Large should
>> change instead of Huawei.
>> Huawei routers are treating routes with Large BGP Communities as
>> "withdraw", which makes Large BGP Communities deployments suffer. Large
>> BGP Communities users become unreachable on attribute 30.
>> Had the squatting resulted in Huawei routers crashing or some other form
>> of damage on the Huawei side, the onus would be on Huawei users. This is
>> not the case unfortunatly.
>> There are no winners if either side holds their ground and remains on
>> the codepoint. For Large BGP Communities it is still early enough to
>> update the implementations. Changing the Large BGP Communities path
>> attribute value is a risk adverse strategy.
> Would the same course of action be recommended if it were an
> open-source project (eg bird or quagga), rather than a commercial
> router vendor, squatting on attribute 30?  If the answer is an
> unequivocal yes, then I agree with the proposed course of action.
> Otherwise, I think the burden falls on the vendor to fix their (with
> respect to standards) broken implementation.

I think the issue is that we might have a lot of Huawei routers deployed
on the Internet with this code so in practical terms it's probably 12-18
months away to have all of them upgraded to a version where they will
not drop prefixes with large BGP communities.

This will leave networks that want to use large BGP communities with the
choice of
  * using large and not becoming reachable from networks that use Huawei
  * OR not use large and reach the whole Internet

I think a lot of network operators will choose the latter so in the end
we'd be slowing down the implementation speed of large rather than
punishing Huawei.

Kind regards,