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 <kll@dev.terastrm.net> Tue, 18 October 2016 15:49 UTC

Return-Path: <kll@dev.terastrm.net>
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 90FBB1296B2 for <idr@ietfa.amsl.com>; Tue, 18 Oct 2016 08:49:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUsbT8xNOYkP for <idr@ietfa.amsl.com>; Tue, 18 Oct 2016 08:49:06 -0700 (PDT)
Received: from smtp.dev.terastrm.net (smtp.dev.terastrm.net [80.159.241.61]) by ietfa.amsl.com (Postfix) with ESMTP id 571401296B9 for <idr@ietf.org>; Tue, 18 Oct 2016 08:49:05 -0700 (PDT)
Received: from Kristians-MacBook-Pro.local (unknown [IPv6:2003:1b3b:ffde:1::5]) by smtp.dev.terastrm.net (Postfix) with ESMTPSA id 03F9E3A011F; Tue, 18 Oct 2016 17:49:03 +0200 (CEST)
To: Michael H Lambert <lambert@psc.edu>, IETF IDR WG <idr@ietf.org>
References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <20161018153047.GJ95811@Vurt.local> <B62FC422-C298-469D-BC99-E36EEC004DE3@psc.edu>
From: Kristian Larsson <kll@dev.terastrm.net>
Message-ID: <85865e76-c48f-1164-2602-1ace0a515a30@dev.terastrm.net>
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: <B62FC422-C298-469D-BC99-E36EEC004DE3@psc.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/uv68rk8iUfI-LnrptbC5YRinZ1M>
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-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 15:50:08 -0000


On 2016-10-18 17:44, Michael H Lambert wrote:
>> On 18 Oct 2016, at 11:30, Job Snijders <job@ntt.net>; 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,
    Kristian.