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

Jeffrey Haas <jhaas@pfrc.org> Wed, 23 October 2019 18:20 UTC

Return-Path: <jhaas@pfrc.org>
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 42DD0120CC6; Wed, 23 Oct 2019 11:20:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 DLs72mL7W-n5; Wed, 23 Oct 2019 11:20:27 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 05FD1120CD1; Wed, 23 Oct 2019 11:20:23 -0700 (PDT)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 42EBA1E2D2; Wed, 23 Oct 2019 14:23:50 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <BL0PR0901MB4563AD37675891343119D058846B0@BL0PR0901MB4563.namprd09.prod.outlook.com>
Date: Wed, 23 Oct 2019 14:20:21 -0400
Cc: Jared Mauch <jared@puck.nether.net>, 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: <5844BA80-217F-45AD-8FC5-48CCCED33926@pfrc.org>
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> <20191003202515.GE28365@pfrc.org> <BYAPR11MB37516DBEEE3BE2DE9787E11FC09F0@BYAPR11MB3751.namprd11.prod.outlook.com> <BL0PR0901MB4563AD37675891343119D058846B0@BL0PR0901MB4563.namprd09.prod.outlook.com>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram=40nist.gov@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3594.4.19)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/mxLLaWJ01QyyVEwGFMvffC7rhSQ>
Subject: Re: [Idr] [Sidrops] [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, 23 Oct 2019 18:20:30 -0000

Sriram,


> On Oct 23, 2019, at 11:45 AM, Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram=40nist.gov@dmarc.ietf.org> wrote:
> Out of the 477 routes with AS_SETs:
> 	*** Identifying Routes with AS_SET that seem meaningless or malformed ***
> 	# Routes with only one AS in AS_SET : 383
> 	# Routes with Reserved ASN in AS_SET : 131
> 	# Routes with common AS in the AS_SEQUENCE and AS_SET : 139

The three of these have a strong feeling of bugs related to aggregation interacting with either confederations or private internal AS numbers and remote-private.

Operators with diverse labs may wish to play around and see what they can generate. :-)
(I don't claim our implementation is bug-free here.  But I know what I'd look for if doing a code audit.)



> 	# Routes with repeated ASes in the AS_SET : 0

This one is somewhat expected.  The practice of canonicalizing sets in most people's code base should generally ensure that if you have a single sane BGP implementation in the path of the route to the observatory that the duplicates would be pruned.

-- Jeff