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

["Susan Hares" <[e-mail]>]

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:[e-mail]] 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 <[e-mail]> 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/ 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