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

[Job Snijders <[e-mail]>]

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