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)

Michael H Lambert <lambert@psc.edu> Tue, 18 October 2016 15:44 UTC

Return-Path: <lambert@psc.edu>
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 EC9FF1293EE for <idr@ietfa.amsl.com>; Tue, 18 Oct 2016 08:44:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.433
X-Spam-Level:
X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=psc.edu
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 chh4AU-kYfN9 for <idr@ietfa.amsl.com>; Tue, 18 Oct 2016 08:44:49 -0700 (PDT)
Received: from mailer2.psc.edu (mailer2.psc.edu [IPv6:2001:5e8:2:46::6a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21A4129494 for <idr@ietf.org>; Tue, 18 Oct 2016 08:44:48 -0700 (PDT)
Received: from dengue.psc.edu (dengue.psc.edu [128.182.160.217]) (authenticated bits=0) by mailer2.psc.edu (8.13.8/8.13.8) with ESMTP id u9IFiirh025401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Oct 2016 11:44:45 -0400
DKIM-Filter: OpenDKIM Filter v2.10.3 mailer2.psc.edu u9IFiirh025401
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=psc.edu; s=default; t=1476805485; bh=Fb2LJ+xoR/4OfMck8cUOqCtIt6/lWmV8KkakgEUQYKk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=L7sBbMfKlD07YZXntPWGAgEJq/yIxDdu/XYeU5KTMrlnm9L+i1Ll3uIcH4n+tLATX i7AD/r3fTB6Q32S+MSxs9b1uDdKAyFksxxmWKFXIo3Zq3mnUFcT7+aei1xTou7zwJB L0nsaPVqdArqoaxcRzsuBgMQTgGLCaWX0AL5bH+U=
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset="us-ascii"
From: Michael H Lambert <lambert@psc.edu>
In-Reply-To: <20161018153047.GJ95811@Vurt.local>
Date: Tue, 18 Oct 2016 11:44:44 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <B62FC422-C298-469D-BC99-E36EEC004DE3@psc.edu>
References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <20161018153047.GJ95811@Vurt.local>
To: IETF IDR WG <idr@ietf.org>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/rNpHf6gQlG462f3zE5YJlQ4BRDI>
Cc: 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:44:51 -0000

> 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.

Michael