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:30 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 034581295EF for <idr@ietfa.amsl.com>; Tue, 18 Oct 2016 08:30:54 -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 25k3P-D5H1XB for <idr@ietfa.amsl.com>; Tue, 18 Oct 2016 08:30:52 -0700 (PDT)
Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 BD9A8129562 for <idr@ietf.org>; Tue, 18 Oct 2016 08:30:52 -0700 (PDT)
Received: by mail3.mlpsca01.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 1bwWLs-000CIg-3q (job@us.ntt.net); Tue, 18 Oct 2016 15:30:52 +0000
Date: Tue, 18 Oct 2016 10:30:47 -0500
From: Job Snijders <job@ntt.net>
To: Susan Hares <shares@ndzh.com>
Message-ID: <20161018153047.GJ95811@Vurt.local>
References: <01f401d22950$7f988470$7ec98d50$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <01f401d22950$7f988470$7ec98d50$@ndzh.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.0 (2016-08-17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/MixVX-R-fVsQPGfE5tNrmsHPUec>
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:30:54 -0000

On Tue, Oct 18, 2016 at 11:01:20AM -0400, Susan Hares wrote:
> Early testing of the Large Communities draft
> (draft-ietf-idr-large-community-03.txt)  with attribute value of 30
> detect that we had an implementation squatting on attribute 30 by a
> Huawei router.  "Squatting" on an attribute is anti-social behavior in
> the Internet in any release of software.  
> 
> Now what shall we do? The large community draft is critical for several
> networks. After talking with the developers and operators, John and I would
> like to recommend we do the following: 
> 
> IDR should recommend that the following attribute numbers be
> deprecated:  
> 
>   BGP Attribute 30 
>   BGP attribute 129 
> 
> IDR should ask IANA to assign BGP Large Communities (currently
> Attribute 30) to a new attribute number.  This is a 1 week call to
> determine if the IDR approves this action.   This call will allow the
> large communities draft to still continue with the 2 week WG LC.  

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.

Kind regards,

Job