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)

Christopher Morrow <morrowc.lists@gmail.com> Wed, 26 October 2016 01:50 UTC

Return-Path: <christopher.morrow@gmail.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 7E8B41299F1 for <idr@ietfa.amsl.com>; Tue, 25 Oct 2016 18:50:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Ix4-t11ufhgL for <idr@ietfa.amsl.com>; Tue, 25 Oct 2016 18:50:52 -0700 (PDT)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 81B991299F0 for <idr@ietf.org>; Tue, 25 Oct 2016 18:50:46 -0700 (PDT)
Received: by mail-qt0-x234.google.com with SMTP id 23so15885520qtp.5 for <idr@ietf.org>; Tue, 25 Oct 2016 18:50:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6UbYMmD9qdOLcW10lTED58Nth0WEC5pTYM2SUiwhkmk=; b=IxxLSaTTLv6W1utB7Jre7RdFBR+MzmFR6XXo4I8EQueqZg7X5fZ2YNYgbiL+1/Isq5 ACBVTVLGj1eTDIDkn/t6E+vVSaG5+TV04A1HYRLAbT4NUtEg7HRcTk3gSSaE+nrlWsis GP2B7pYn8wDHb8wFZeuUb9gdYkHf02xhTDV4pjjw/lvRPYExCPAFXPmnGf85g2XdUDY1 umOWMKjZwKDsAqfpStbqFRqxteURrXrSGx+MgZagI/bpD4R4zp6/HcknuJAQhk7+39Sl 7hlscPoxKPWcbkxgKcKELLgmnf0ggSlxmoegqXrDi69gHybIgNHLJK7txtwAwq0Bcmvz YrOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6UbYMmD9qdOLcW10lTED58Nth0WEC5pTYM2SUiwhkmk=; b=TIaHuLT3Lt2j46GVNSOeftcKQGszBN8U/BF73z8J2qUa+ZcAjQoNnXM7CikeAKk1Cj Va4hjsZ3mj9Iv7ZkmqRGTP9iqGiWmqyXZZXfjCrM4S3tIh1YwTCgATjL2UJnmOEqK40+ 8prrCvCW45DvYGekdRIXBQdRd3DfbP+JFCLqixKKy0RRwGtSldi5oqvu79Z8bsET1vD/ CSNX7AtGpzowP87goCkNiXE00feIrOyvTSFoykRbZZXRvxphfx1GWIcTl6wLZ/JPQYnS LslZbGKXlxXwKtdwwH78vSuLlCSMwwcav4Oujp1cZcwRZCMXjhn42mkLGjCmi9TiyKJ9 PHgg==
X-Gm-Message-State: ABUngvdHrRFxVJ/V1K7nlUuM0uCYYwy1urQlUHGUFDJzfmtYx33DjxJOwoOIHOaD6DoCgPzZOOMAijbPQvsTuw==
X-Received: by 10.237.38.68 with SMTP id z62mr22922208qtc.73.1477446645619; Tue, 25 Oct 2016 18:50:45 -0700 (PDT)
MIME-Version: 1.0
Sender: christopher.morrow@gmail.com
Received: by 10.140.105.244 with HTTP; Tue, 25 Oct 2016 18:50:45 -0700 (PDT)
In-Reply-To: <db7a17a288aa4a3288dc6ec8f032b687@XCH-ALN-014.cisco.com>
References: <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <db7a17a288aa4a3288dc6ec8f032b687@XCH-ALN-014.cisco.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
Date: Tue, 25 Oct 2016 21:50:45 -0400
X-Google-Sender-Auth: OrzuC0dumRAroF0AUfGmME174fU
Message-ID: <CAL9jLaZcCwBhUEs7cvsx3HfiPSRPXrcvOguCeuV2opSns9OZMw@mail.gmail.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
Content-Type: multipart/alternative; boundary="94eb2c12299c7ca2e9053fbadafa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/QHtqtDJfgRvh8NoyjBSyP7nGZzQ>
Cc: "idr@ietf.org" <idr@ietf.org>, Susan Hares <shares@ndzh.com>
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, 26 Oct 2016 01:50:56 -0000

So, what's the downside to having IANA pick the next available (from the
current list, prior to the 2 squatting incidents) value in cases like this?

I think it's: "Some routers somewhere do bad things"
  (or sometimes cause other remote people to do 'bad things' .. where
sometimes that other person is 'me')

and when that happens: "some people quickly upgrade code to avoid the 'bad
things'"
(presuming that the code is available, I mean... and I do hope that
vendors, all of them, are telling their DE folk: "Hey, don't do this, it's
super painful...srsly!")

Is that about it? Why don't we just go back to assigning the next available
and deal with the problem(s) as they arise?

-chris

On Tue, Oct 25, 2016 at 6:27 PM, Jakob Heitz (jheitz) <jheitz@cisco.com>
wrote:

> I have discovered that Cisco has used BGP attribute code 31
>
> for an internal experiment in certain NXOS routers,
>
> but unfortunately some of the code leaked into production.
>
> The code does not send the attribute,
>
> but it receives it incorrectly. We are creating patches for the
>
> faulty code, but cannot guarantee that all affected routers will
>
> be patched. Consequently, we request deprecation of attribute
>
> code 31 as well.
>
>
>
> I apologize on behalf of Cisco for the oversight.
>
>
>
> Thanks,
>
> Jakob.
>
>
>
> *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of *Susan Hares
> *Sent:* Monday, October 24, 2016 5:19 AM
> *To:* idr@ietf.org
> *Subject:* [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)
>
>
>
> IDR Working group:
>
>
>
> Thank you for your input on the question of whether Large communities
> should be reassigned another attribute number due to Huawei squatting on
> attribute 30.  The WG consensus is that the IDR WG wishes to have IANA
> deprecate attribute 30, and reassign large communities another attribute
> number for its early allocation.
>
>
>
> Alvaro should request a new attribute number for wide communities.
>
>
>
> If wide communities implementers request an early allocation, the WG
> consensus was unclear.  Therefore,  the code point of 129 is deprecated for
> now.  The full discussion on this point is at:
>
>
>
> https://www.ietf.org/mail-archive/web/idr/current/msg16556.html
>
>
>
> The following other attributes were seen in the wild with the comments we
> saw:
>
>
>
> #        BGP function                                      Reference
>
> ----    -----------------------------------------------   ---------------
>
> 20     Connector Attribute (deprecated)   [RFC6037]
>
> 21      AS_PATHLIMIT (deprecated)           [draft-ietf-idr-as-pathlimit,
> unknown]
>
> 30     (deprecated)                                       [variant of
> draft-ietf-tunnel-encaps, Huawei router]
>
> 129   (deprecated)
>         [draft-ietf-idr-wide-bgp-communities, Huawei router]
>
>
>
> Attribute  AS Attribute Observed
>
> -----------   --------------------------------
>
> 20           AS 22742  (Peter Hessler)
>
> 21           AS 14706, AS 11720, AS 22490
>
>                  https://www.ietf.org/mail-archive/web/idr/
> current/msg16583.html
>
>
>
> 30   -  in trials reported by Job
>
> 129 -  self-reported by Huawei
>
>
>
> Sue Hares
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>