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

[Jeffrey Haas <[e-mail]>]

On Tue, Mar 14, 2017 at 11:07:54PM +0100, Job Snijders wrote:
> 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.

This is one of those things I'd love to say "it's nice on principle" but
usually get followed by "but the consequences are a bit ugly".

Deprecating means largely "don't do that".  You now have to deal with all of
the consequences of those things that still do that or expect such to be
done.  BGP changes are all about incremental rollout headache after all.

Implementations will still be required to understand the attribute and
minimally to ignore it.  This means you don't really get rid of much code
there.

Conformance tools will still probe for what we do for things and have to be
revised to not flag as non-conformant an implementation that doesn't pass
the attribute along if it's been set.  Or that it's added if the as-path is
truncated or otherwise incomplete.

And while deaggregation isn't typically done automatically by routers, it's
still good to signal that doing so may be a bad idea.  I'll let you dig out
your favorite deaggregation traffic shaping tool presentation from the *NOG
of your choice.

So, the benefits don't really outweigh the consequence of leaving it in.

If we'd been having this conversation as part of trying to get 1771 style AA
semantics working right[1], I might have had a somewhat different opinion.

> 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?

See above.

> 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.

See above. (I generally agree.)  It's also likely to get worse.

> 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.

You're also not the one that gets the bug reports from this sort of thing.
:-)  

At best, I'll acknowledge your network won't fall over from it not showing
up the few times it actually does in the DFZ these days.

-- Jeff

[1] As part of Sue's crash course to how to participate in the IETF process,
I was encouraged to try to work out issues we'd found in our implementation
of the specification (draft-ietf-idr-bgp4-XX) on the mailing list.  As part
of working through inconsistencies in the text regarding how AA was set, I
tried to contact our venerable authors on BGP to get them to work through
those inconsistencies with me.  Being busy at startups, most didn't respond.
This left a rather inexperienced protocols implementor trying to intuit
"what is this thing for?" and supplying various bits of text toward the
draft to try to rectify the discrepancies.

It turns out that if done using the intent of 1771 and earlier, AA would be
set on *most* things, especially when policy was involved.  However,
discovering this set of things resulted in at least 3 churns of the draft.
Eventually that was overcome by the realization that this is an appendix, in
the anatomy sense; a vestigial organ.  It's mostly useful to prevent
auto-deaggregation in implementations that were transitioning from the
classful BGP-3 to CIDR BGP-4.  Such things didn't seem to be common even
back in the day, and the transition from -3 to -4 seemed to take very little
time across the backbones.

What eventually remained was "this is a good idea to signal truncation or
loss of information from the as-path" in the event that deaggregation would
happen. While gross, people did and still do it.  And even otherwise, having
it as a handy note that "information was lost" during aggregation is still
handy.[2]  Having lost most of the crazy text about the rules with which you
set AA based on what you learned, we now have a relatively quiet feature
that's easy to implement with some minor operational benefit.

This exercise in archaeology was my first, and a lingering introduction to
Internet standards.  I've almost foriven my second introduction, which
involved SNMP.

[2] An interesting side effect of extened UPDATES in our other thread will
be that aggregation that results in sets from gateD family software will
mean we have even LONGER AS_SETs today than before.  While such
implementations support "brief" aggregation, the transitional behavior of a
long AS_SET on a extended message speaker to a 4k speaker will make for an
interesting edge and conformance case.