Re: [Idr] [GROW] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

Rob Foehl <rwf@loonybin.net> Wed, 02 October 2019 23:45 UTC

Return-Path: <rwf@loonybin.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 35E58120108; Wed, 2 Oct 2019 16:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 8TOtiUC0Jo5N; Wed, 2 Oct 2019 16:45:18 -0700 (PDT)
Received: from jupiter.loonybin.net (jupiter.loonybin.net [IPv6:2001:470:1f07:3b6::f2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 340C61200F4; Wed, 2 Oct 2019 16:45:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by jupiter.loonybin.net (Postfix) with ESMTP id 3D01CA280FE; Wed, 2 Oct 2019 19:45:16 -0400 (EDT)
X-Virus-Scanned: amavisd-new at loonybin.net
Received: from jupiter.loonybin.net ([127.0.0.1]) by localhost (jupiter.loonybin.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNlGPSqY235u; Wed, 2 Oct 2019 19:45:15 -0400 (EDT)
Received: from bugs.loonybin.net (unknown [IPv6:2001:470:e04e:7:ac2a:2317:7e03:435]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by jupiter.loonybin.net (Postfix) with ESMTPSA id 7F301A280DA; Wed, 2 Oct 2019 19:45:15 -0400 (EDT)
Date: Wed, 2 Oct 2019 19:45:15 -0400 (EDT)
From: Rob Foehl <rwf@loonybin.net>
To: Jeffrey Haas <jhaas@pfrc.org>
cc: Warren Kumari <warren@kumari.net>, IDR <idr@ietf.org>, GROW WG <grow@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>
In-Reply-To: <B8F727FE-1155-4FB4-9A29-1740DF048C97@pfrc.org>
Message-ID: <alpine.LFD.2.21.1909262319330.23402@bugs.loonybin.net>
References: <DM6PR09MB3019D019788E916525EDC3DC84D40@DM6PR09MB3019.namprd09.prod.outlook.com> <01c201d54d3c$74375ee0$5ca61ca0$@ndzh.com> <D49ED265-0C25-4FE0-BB02-4F176DA4BE5E@puck.nether.net> <69F03192-CE2E-4126-910D-A7E3B3AA8848@puck.nether.net> <BL0PR0901MB45639533E8F999FD6553191184860@BL0PR0901MB4563.namprd09.prod.outlook.com> <CAHw9_iJr=NaEWjMqmZjeWEwGmKfSNoAM58spsY+BSEa9ze3qYQ@mail.gmail.com> <B8F727FE-1155-4FB4-9A29-1740DF048C97@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/FNVRL4kmnsxvbdud6aLqss4nCQM>
Subject: Re: [Idr] [GROW] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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, 02 Oct 2019 23:45:20 -0000

On Thu, 26 Sep 2019, Jeffrey Haas wrote:
>> On Sep 26, 2019, at 6:43 PM, Warren Kumari <warren@kumari.net> wrote:
>>
>> This is nice, but what would make it more useful would be if it also
>> reported if there are *useful* AS_SETS / if the AS_SET means anything.
>>
>> For example, from Jared's email below:
>> AS path:  14061 3356 6762 23487 27738 27738 27738 27738 27738 27738
>> {27738} -- the 27738 AS already shows up as a non-AS_SET in the path.
>
> This one is on the buggy end of things, but still reasonably valid.  It smells like something that passed through remove-private of some flavor.

I'd wager this explains nearly all of the "set of one" instances seen in 
the wild -- there are currently a half dozen or so with a set containing a 
private AS at the end of the path.

> It'd be interesting to find out what code these folk are running. Hopefully not one of my bugs. :-)

I've never had an interaction with AS_SET that could be described as 
anything other than broken -- like, ever, from any vendor.  I'd prefer to 
see them disappear entirely, but if that doesn't happen, at least having a 
"no-as-sets-under-any-circumstances" policy knob would be helpful...

-Rob