On Wed, Feb 05, 2014 at 09:02:52AM -0500, Jared Mauch wrote:
On Feb 5, 2014, at 8:52 AM, Jeffrey Haas <jhaas@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