Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 drafts)

Theodore Baschak <> Wed, 15 March 2017 20:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B145913181F for <>; Wed, 15 Mar 2017 13:17:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.419
X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qivB_xx_qA4t for <>; Wed, 15 Mar 2017 13:17:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 483F613181A for <>; Wed, 15 Mar 2017 13:17:00 -0700 (PDT)
Received: by with SMTP id g138so27216719itb.0 for <>; Wed, 15 Mar 2017 13:17:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=iRk3ku0okqtZ90COKEzDoN/elY8IjETYBJxoHLmv2UU=; b=nAE+wOiJ6YERE8zGKIpB7wWMiteuI1PggD6HrwGEG2DZSsOSWLKjqqE4DWiaj/Xjvz W6eUMYW02z391IqIpIsZLMFMNrnvu0+wbmqzuC4Fwjp15T7NUQEdw4gthx4N1PZzR5rv sSCauU8cRkAxS4CNb1ngn5pmXP0oyRICB12OtQfip22DqEdIQS1k/+Ejgc/S5TF2zJFE NvjqnltQLXBbtmJCkefcyO6sEMKmIoQ77POgih6HC68bf3Kw9pAeKVyUhtEPTWNt8Egz L5taML84AKq8Wg2fnoR38Mycuk2rS9sm/acY2lFNgRiszattrOiZtD/CVnB+qA1rTot1 27pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=iRk3ku0okqtZ90COKEzDoN/elY8IjETYBJxoHLmv2UU=; b=UhjxV7HJ+OIxGwxbJRVO2X3lxGjM3Ew8PWbt62yadnQLTCr530IjcAov5NN7AKxmYH Q71MeX2xuC220L9A8+YWphVX2YxJbdqIIub5BLi1s6LHMTgoUe3mJKolDk63c6twksS7 mg0TDNCqe2iOS2IzfqnkbOAS2AuO/nESHV1+tbowq1waGZHNWoDu2ZdShN0TSRUPFEtX gEhyJ95Md6KJakikfrpLmrdCJYpjAaYi9l8OC0pi+B5c9n+yUI6U/Xqt67OsTORt9vn8 EwEIc7vNT/DzYkiF3axwM9DjgaFk3zi6NoZxrZ+E3SC71xA2glDU0tTfnUEos3uXnRKH 4x4g==
X-Gm-Message-State: AFeK/H2m/keOrvZE5D+f6iar+/Z4JPdCmzGADNbid4nf8lcI7AbCLeYWIukNqbn0kdSoPw==
X-Received: by with SMTP id b1mr21702429itb.86.1489608959316; Wed, 15 Mar 2017 13:15:59 -0700 (PDT)
Received: from ( []) by with ESMTPSA id g103sm1946500iod.44.2017. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Mar 2017 13:15:58 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_9EE84703-504D-48D3-A537-38382720F212"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Theodore Baschak <>
In-Reply-To: <028b01d29da3$85fb8890$91f299b0$>
Date: Wed, 15 Mar 2017 15:15:54 -0500
Cc: Job Snijders <>, Jeffrey Haas <>, idr wg <>
Message-Id: <>
References: <03ae01d29c3e$6c5d87a0$451896e0$> <> <> <028b01d29da3$85fb8890$91f299b0$>
To: Susan Hares <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Subject: Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 drafts)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Mar 2017 20:17:03 -0000

The big incumbent Telco in my area, AS7122, went from overboard on de-aggregation (several /16's advertised as /16+/19's + /24's +/32's) to overboard on aggregation, using the atomic aggregate attribute. 

Overnight on 2015-09-13 AS7122 enabled atomic aggregate for all blocks, despite having 6 downstreams advertising /24's and whatnot from those blocks. Just coincidentally, none of those downstreams were multi-homed at the time so no one noticed anything and there was no pushback. However, now some of these ASNs have been wanting to multi-home and will have trouble doing so because their one path will now be squashed in a atomic aggregate.

Theodore Baschak - AS395089 - Hextet Systems - -

> On Mar 15, 2017, at 10:47 AM, Susan Hares <> wrote:
> Job and Jeff: 
> Thank you for the feedback.  You are having the same conversation I had with myself about deprecate.  After IETF97, I came down on the side of “getting rid of features that do not exist”.   If we are going to a BGP version 5, this would be one of the things we would get rid of.   I’d like to hear more from other people.  
> Job - I’m happy to work with you on such a document that provides history for atomic-aggregate since I was in the original discussions.   I will start a document and we can discuss it at IETF 98 prior to publishing.  
> Sue 
> From: Idr [] On Behalf Of Job Snijders
> Sent: Tuesday, March 14, 2017 6:08 PM
> To: Jeffrey Haas; idr wg
> Subject: Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 drafts)
> On Tue, 14 Mar 2017 at 20:24, Jeffrey Haas < <>> wrote:
>> Sue,
>> On Mon, Mar 13, 2017 at 05:11:45PM -0400, Susan Hares wrote:
>> > I'd like to follow-up on our "clean up" the attribute area discussion.
>> >
>> > I've published:
>> [...]
>> >
>> > draft-hares-deprecate-atomic-aggregate-00
>> I'd actually recommend against outright deprecating AA.  Mostly it'll lead
>> to confusion of compliant implementations of 1771/4271 without a lot of
>> benefit.
>> A significant amount of the controversy around the feature while
>> standardizing 4271 had to do with the rules by which AA was attached to
>> routes.  I suspect very few people besides Tony Li ever had a strong opinion
>> about the behavior, especially once we got beyond the BGP-3 transition.
>> (And I wasn't there at the time.  The Tony observation is driven mostly by
>> him popping up a few years ago with a proposal that included AA behavior.)
>> The current behavior of 4271 with regard to AA is pretty mild: If you're
>> dropping out ASes from the path as part of aggregation, you SHOULD add this
>> thing.  If you see it, don't de-aggregate.
>> People generally don't de-aggregate magically these days and those who do
>> generally expect to have to be very careful.
>> The document that I thought was worth writing at some point, even if it only
>> was a draft and never got published, was a short discussion about the origin
>> of the feature, what its original intent was, what was broken about its
>> original rules to be attached and why we ended up where we did.  This is
>> arguably a history document intending to document a rather ugly bit of
>> living history that confuses newcomers to the protocol.
>> I'm happy to contribute to such a document.  But I don't recommend we
>> proceed down the path to deprecation.
> Hi Jeff,
> Isn't the path to deprecate a poorly understood feature ("poorly" as in ugly, that there is a disconnect between expectations), to just.. deprecate it? I'd welcome historic perspective in such a deprecation document for newcomers, it would be helpful for my edification to learn of the rise and fall of a protocol complications.
> However I don't see a compelling reason in itself to not touch 4271, for the purpose of touching 4271. There have been a number of updates to 4271 over the years, and compliant implementations need to continue to monitor IETF documents to remain complaint, right? 
> In context of internet-wide EBGP operations I'd view both aggregation (aggregation through snipping globally unique ASNs from the as_path) as well as de-aggregation as most unwelcome. At this point especially de-aggregation is real threat to the DFZ, stuff like <> comes to mind.
> Is there a legitimate use case for keeping atomic aggregate around? if not, we should clean up.
> I'm usually in favour of deleting things that are not used.
> Kind regards,
> Job
> _______________________________________________
> Idr mailing list