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

[Job Snijders <[e-mail]>]

On Tue, Mar 14, 2017 at 06:39:16PM -0400, Jeffrey Haas wrote:
> 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.

Thank you for sharing this Jeff. I treasure emails like these :)

Kind regards,

Job