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)

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 26 October 2016 07:43 UTC

Return-Path: <brian.peter.dickson@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 02CD0129A33 for <idr@ietfa.amsl.com>; Wed, 26 Oct 2016 00:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, MIME_QP_LONG_LINE=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 XMu8j31anBwG for <idr@ietfa.amsl.com>; Wed, 26 Oct 2016 00:43:39 -0700 (PDT)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 9586F1299FC for <idr@ietf.org>; Wed, 26 Oct 2016 00:43:39 -0700 (PDT)
Received: by mail-pf0-x233.google.com with SMTP id n85so18684448pfi.1 for <idr@ietf.org>; Wed, 26 Oct 2016 00:43:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-transfer-encoding:from:mime-version:date:message-id:subject :references:in-reply-to:to:cc; bh=t5i9X/zAXcV+ELOr6lvQzECpiWo3BiQShwYRoFG0rFQ=; b=XnjJfhBKTY5WnHedG0seSGEwtEOasGl02/TN/Suu5BzZXXy94hod0k0Ko7XYnlnFsw rmO6IrbSVUzuUv5T5psjXHBsK74+qW39VCFIaGk8zl3upgZu1D56sSZDHK+g+S2FTcJw zzwrY5TVi5VYqmdLPzh3sEGsI0HyQdsunIeZ3N1HMVArHgGXJ6aIrds/M8ggztJbjRna E+2SXGk7x6j+SEfnHO9wBkcVd67efQX9tw/uXa0gZBfkSvpl3b2bD1y8cjvOjC7wg3t0 RxjsGuuZE/R1pnaPaZqWgpZqX4XYQXXEI/0xB0+gI2RbGpvqBMdHgmhlngHPlO2lTNoF DYTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :message-id:subject:references:in-reply-to:to:cc; bh=t5i9X/zAXcV+ELOr6lvQzECpiWo3BiQShwYRoFG0rFQ=; b=f8QQGAOmplgKENEhzJ3Nw5Pn+Qml/I7iO/d0HMijhBjglJdB610nULO2FjYoJGXP/a 8XSKXwTHWdeb8UlLQIXLFay5Ng2J1FSWo8gQo+3IPFTWzcU3tmxUbanVSK/nM8ZHlADP 4CYc4PqmeXdxXWYyu99wiO+0Ohvk7lECMzzhftbZMZmdYWUhcIx6JQ8ecvH5pQMQP/kY BACMD5etMp0sSXJp47BRIIY7qTgbn5ruIyMgMeleaONjXlLGnEfmzbJZQl9gjbYWK/Gx bVcROylzu1U1xvTqgvWem5Hl0gCLoSBqb0cPACIdKelOL/09vI/q0LMSI7mwqBHGeN2h IdKg==
X-Gm-Message-State: ABUngvdMPd9U2BYZGPphT8W5eiHfihqaiEEFgayS7hGkxgKJwum3ivYBDU0PXZT5L2Wweg==
X-Received: by 10.99.123.90 with SMTP id k26mr1368166pgn.153.1477467819162; Wed, 26 Oct 2016 00:43:39 -0700 (PDT)
Received: from ?IPv6:2601:646:9100:5d70:6010:468d:d73b:d62b? ([2601:646:9100:5d70:6010:468d:d73b:d62b]) by smtp.gmail.com with ESMTPSA id q23sm1853057pfg.95.2016.10.26.00.43.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 26 Oct 2016 00:43:37 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-121CC894-7EC4-4EFB-AA82-8DD63C392B33"
Content-Transfer-Encoding: 7bit
From: Brian Dickson <brian.peter.dickson@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 26 Oct 2016 00:43:23 -0700
Message-Id: <EBCE3CE8-1295-4CB2-9A1A-8BA2E154033D@gmail.com>
References: <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <db7a17a288aa4a3288dc6ec8f032b687@XCH-ALN-014.cisco.com> <CAL9jLaZcCwBhUEs7cvsx3HfiPSRPXrcvOguCeuV2opSns9OZMw@mail.gmail.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com>
In-Reply-To: <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
X-Mailer: iPhone Mail (14A456)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/1aHIJUgM49jbCAUfBNChD0kNcIk>
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 07:43:43 -0000

Rather than deprecate the two sequential values, why not reserve a small range which includes those values, for non-permanent reservations for vendor development use? Say 30-35 inclusive?

A fixed range would be not much worse in terms of consumed code points than a few more squatting incidents. However, it would allow defensive coding against known bad code points.

The idea of temporary reservations by vendors (e.g. For 6 month intervals) would allow easier identification of vendors that leak their test stuff. It would encourage vendors to use the range set aside. And the temporary nature would make deliberate squatting inside that range a doomed effort.

Easing the rules for reservations would help the squatting issue generally. The easier it is to reserve , the harder it would be to justify squatting.

Maybe have another small range for no-reservations use, with no guarantee of global uniqueness? Maybe re-purpose 129-130 for that?

Those code points are already toast, this would give them an alternative use. 

Thoughts?

Brian

Sent from my iPhone

> On Oct 25, 2016, at 10:51 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
> 
> Because then we wouldn't own up to it and innocents would suffer.
> We would hope we could fix as much of it as possible and hope the rest wouldn't notice.
> Actually, the intended purpose of the NXOS line is for the data center, not the Internet and we can very likely fix all of the deployed ones. However, users have a right to deploy them wherever they want without notifying us and they have the right not to apply patches, so I chose to own up to the problem.
> Honest, we didn't mean it. Sorry.
> 
> Thanks,
> Jakob.
> 
> 
> On Oct 25, 2016, at 6:50 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
> 
>> 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
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr