Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt

[Jeffrey Haas <[e-mail]>]

On Wed, Oct 12, 2016 at 09:56:23PM +0000, heasley wrote:
> Wed, Oct 12, 2016 at 09:45:52AM -0400, Jeffrey Haas:
> > Arguably this was one of the motivations for doing scoping of attributes or
> > communities themselves: If the effective operational behavior is almost
> > always going to be AS-non-transitive, it'd be nice if the cleanup just
> > happens automagically.  Unfortunately people are rather enamored with their
> > existing cleanup mechanisms.
> 
> Please, no automatic clean-up.  A community may be 100% legitimately used
> to affect a decision 2 or 3 AS-hops away and it is extremely useful.
> Operators already know how to alter communities.

Experience has shown that a lot of people are simply bad about cleaning up
their trash.  (And also how it was found that some particular bit of code
had a hash table poorly sized...)

This is really more an issue in the scope of VPN related (extended)
communities, but the analogy generally holds.

What I think is being missed in the conversation is just because something
has a scoping bit (i.e. AS-non-transitive), nothing stops you from using
policy to say "don't enforce it for *this* thing".  However, I think that
use case is a bit weaker once you move into the federated AS scoping case.

-----

I do want to make one partially orthogonal comment here:
A number of the highly opinionated operational folk that are participating
on IDR follow or set current best operational practices for dealing with
communities.  

However, you're not the only set of users of these features.

Forcing protocol feature sets to stay to your current strictures because
you've rigorously instrumented their behavior may not be the right answer.
But whether "doing better" comes via protocol changes, or getting better
common practices embedded in running (policy) code is a longer conversation.

-- Jeff