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)

Jared Mauch <jared@puck.nether.net> Tue, 18 October 2016 15:49 UTC

Return-Path: <jared@puck.nether.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 A47041296AB for <idr@ietfa.amsl.com>; Tue, 18 Oct 2016 08:49:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.633
X-Spam-Level:
X-Spam-Status: No, score=-4.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-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 1WNJbt6biimj for <idr@ietfa.amsl.com>; Tue, 18 Oct 2016 08:49:00 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 96E491295F3 for <idr@ietf.org>; Tue, 18 Oct 2016 08:49:00 -0700 (PDT)
Received: from [IPv6:2620::ce0:101:921:7e08:1435:8b08] (unknown [IPv6:2620:0:ce0:101:921:7e08:1435:8b08]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id B1CCC540AD4; Tue, 18 Oct 2016 11:48:58 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3246\))
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <B62FC422-C298-469D-BC99-E36EEC004DE3@psc.edu>
Date: Tue, 18 Oct 2016 11:48:56 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <84F3251A-9947-409A-8347-E541FBF196F3@puck.nether.net>
References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <20161018153047.GJ95811@Vurt.local> <B62FC422-C298-469D-BC99-E36EEC004DE3@psc.edu>
To: Michael H Lambert <lambert@psc.edu>
X-Mailer: Apple Mail (2.3246)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/1OVzAjBwWw7PlkksPEDbnotn0rI>
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 15:49:01 -0000

> On Oct 18, 2016, at 11:44 AM, Michael H Lambert <lambert@psc.edu> 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.

Yes.

As Job said, there is no winning move here.  I’d like to see the vendor taken to the woodshed as well, but without a new allocation everyone suffers.

- Jared