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)

Susan Hares <shares@ndzh.com> Wed, 19 October 2016 02:19 UTC

Return-Path: <shares@ndzh.com>
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 1A193129517 for <idr@ietfa.amsl.com>; Tue, 18 Oct 2016 19:19:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 1IWfVj8FltP5 for <idr@ietfa.amsl.com>; Tue, 18 Oct 2016 19:19:41 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8EE5129512 for <idr@ietf.org>; Tue, 18 Oct 2016 19:19:40 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.177.186.123;
Date: Tue, 18 Oct 2016 22:19:29 -0400
Message-ID: <eu211bemaimltf2xgct7l46w.1476843569677@email.android.com>
Importance: normal
From: Susan Hares <shares@ndzh.com>
To: Michael H Lambert <lambert@psc.edu>, IETF IDR WG <idr@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_5362982961720410"
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/b3Nvn31P6kDINmfIz9afzDba_HQ>
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: Wed, 19 Oct 2016 02:19:43 -0000

Michael
<individual contributor hat on>After listening to numerous talks at nanog about open source bgp implementations - it is equally important to consider open source since it is being used in many networks.
What is most important is to protect large communities from having problems.
Sue


Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone
-------- Original message --------From: Michael H Lambert <lambert@psc.edu>; Date: 10/18/16  11:44 AM  (GMT-05:00) To: IETF IDR WG <idr@ietf.org>; 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) 
> 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

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr