Route Server Filters at IXPs and 4-byte ASNs

Wed Feb 5 14:21:59 UTC 2014

On Wed, Feb 05, 2014 at 09:02:52AM -0500, Jared Mauch wrote:
> 
> On Feb 5, 2014, at 8:52 AM, Jeffrey Haas <jhaas at pfrc.org> wrote:
> 
> >> This draft does not cater for the use case of describing a 32-bit ASN peering
> >> with a 32-bit route server, which would require a 4-byte Global Administrator
> >> as well as a 4-byte Local Administrator sub-field.
> > 
> > I think that's the first clear articulation I've read about why some people
> > want wide comms vs. a simple replacement for existing regular communities as
> > extended communities.  Thanks.
> 
> I suspect the operator confusion is that?s how they?ve been using 16-bit ASNs
> all along, so how did the IETF end up with something different.
> 
> http://www.onesc.net/communities/ is a fairly comprehensive list of how they are used today.

Thanks for the list.  Browsing the first several entries somewhat supports
the reason why I'm acting "surprised".  While there are some cases where the
right hand side of the community is an AS number, a significant amount of it
was either an arbitrary value or something more structured.

The generic 4-byte draft I'm part of is intended to be "low hanging fruit".
We don't need to deploy a new attribute, the format specifier is already
present in code.  All that was needed was a code point to say "go use this
like existing RFC 1997 comms".  

The wide comms draft (and flex comms, where some of the ideas were pulled in
from) was intended to address the messier case where the meaning of a
community was already structured.  To pick on one of the items in the list:
http://www.onesc.net/communities/as209/

Coding these using regexes is a PITA, both as an implementor of the
underlying policy and as a sender who has to remember what the magic value
means.  Ideally the operator should end up with something simple: 
Tell AS209, Do not announce to AS foo. Prepend N times to PST peers. Etc.
Right now, these things are magic values.

The last few rounds of wide comms were attempts to get encoding formats in
place that accommodated some amount of grouping logic 
(peer-class CUSTOMER & North America, e.g.).  We did manage to work out a
way to do that encoding correctly.  But it turned out that the real killer
was transitive manipulation - you can't meddle with such a thing without
breaking logic.  So, back to a simpler drawing board.

An update to the wide-comm draft should be out by end of this week.  We'd
welcome some constructive criticism on it.

-- Jeff