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

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
https://bgp.guru/ - https://hextet.net/
http://mbix.ca/ - http://mbnog.ca/

> On Mar 15, 2017, at 10:47 AM, Susan Hares <shares@ndzh.com> 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 [mailto:idr-bounces@ietf.org] 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 <jhaas@pfrc.org <mailto:jhaas@pfrc.org>> 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 http://bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/ <http://bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/> 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
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr