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)

Job Snijders <job@ntt.net> Tue, 18 October 2016 15:52 UTC

Return-Path: <job@ntt.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 9F59A1296BD for <idr@ietfa.amsl.com>; Tue, 18 Oct 2016 08:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.366
X-Spam-Level:
X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] 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 GtFi2BYF-lfa for <idr@ietfa.amsl.com>; Tue, 18 Oct 2016 08:52:28 -0700 (PDT)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 649BF1296B9 for <idr@ietf.org>; Tue, 18 Oct 2016 08:52:28 -0700 (PDT)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <job@ntt.net>) id 1bwWgk-0000f5-Sq (job@us.ntt.net); Tue, 18 Oct 2016 15:52:27 +0000
Date: Tue, 18 Oct 2016 10:52:26 -0500
From: Job Snijders <job@ntt.net>
To: Michael H Lambert <lambert@psc.edu>
Message-ID: <20161018155226.GM95811@Vurt.local>
References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <20161018153047.GJ95811@Vurt.local> <B62FC422-C298-469D-BC99-E36EEC004DE3@psc.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <B62FC422-C298-469D-BC99-E36EEC004DE3@psc.edu>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.0 (2016-08-17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/sAKtejUM_aBSjaDAEmEw3XU5VOc>
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:52:29 -0000

On Tue, Oct 18, 2016 at 11:44:44AM -0400, 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.

Yes. I don't think the project's license has anything to do with this.

I started testing Large BGP Communities in the wild [1], and attached a
Large BGP Community to my home LAN prefixes. My significant other
discovered that we can't reach parts of the internet. It doesnt matter
which vendor caused the unreachability - the fact that there is a
reachability problem is sufficient reason for this course of action.

Kind regards,

Job

[1]: http://largebgpcommunities.net/2016/beacon/