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

Jared Mauch <jared@puck.nether.net> Wed, 02 October 2019 23:48 UTC

Return-Path: <jared@puck.nether.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 E353B1200FF; Wed, 2 Oct 2019 16:48:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 sxRmpZrhQpzw; Wed, 2 Oct 2019 16:48:18 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A163A1200F4; Wed, 2 Oct 2019 16:48:18 -0700 (PDT)
Received: from [IPv6:2603:3015:3606:cbe1:50d8:efdb:6bdd:85d9] (unknown [IPv6:2603:3015:3606:cbe1:50d8:efdb:6bdd:85d9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id A43CF540160; Wed, 2 Oct 2019 19:48:16 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <alpine.LFD.2.21.1909262319330.23402@bugs.loonybin.net>
Date: Wed, 2 Oct 2019 19:48:15 -0400
Cc: Jeff Haas <jhaas@pfrc.org>, IDR <idr@ietf.org>, GROW WG <grow@ietf.org>, Warren Kumari <warren@kumari.net>, "sidrops@ietf.org" <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E587C579-BECF-40C7-A60A-670C16E9AB04@puck.nether.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> <alpine.LFD.2.21.1909262319330.23402@bugs.loonybin.net>
To: Rob Foehl <rwf@loonybin.net>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/qrbwLa1WNRPekjpVuD8srMPQqe0>
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:48:21 -0000


> On Oct 2, 2019, at 7:45 PM, Rob Foehl <rwf@loonybin.net> wrote:
> 
> 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…

I think back in the days when ANS was still a major player and if you were routed depended upon did you follow the rules that Curtis required, they were still valid.  I think in most modern cases they’re likely not intended or some weird hybrid AS_SET+CONFED setup, likely with remove-private as Jeff speculates.

I’ve not yet composed e-mail to the people originating these, but it shouldn’t be hard to contact them.  They may not know about the issue.  (Generally operators lack awareness of what they route).

- Jared