Subject: extended communities - extended vs. regular types

From: Jeffrey Haas <[email-masked]>
Date: Mon, 8 Apr 2002 19:12:33 -0400

I've deliberately separated this from the previous questions
since this is more opinion than "how is this supposed to work?"

In the extended communities documentation, the distinction between
"regular" and "extended" types are confusing, especially when
attempting to avoid collisions in the regular vs extended space
when creating new ones.

It would greatly simplify things if we used a bit to distinguish
regular vs. extended types.  This would clarify the spec and,
I believe, can be made to be backwards compatable with the current one.

Thus:

Third bit: Extended bit:
     Value 0: The community is extended and the value field is of length 6.
     Value 1: The community is regular and the value field is of length 7.

The remaining 5 bits incicate the structure of the community.

In the case of extended types, I'd suggest referring the 5 bits
as "format" bits.  We have already defined 0-3.  This leaves 28
formats that can be assigned.  This would work for IANA and Vendor
assigned.

Continuing the extended type example, this leaves the next octet
of the extended type field to be the extended community type.
Three are currently defined: route target, route origin and
link bandwidth.

This would limit regular types to 32 IANA assigned values.
This may be unacceptable for the authors since there was presumably
a motivation to introduce the regular type.

All in all, this is a plea for some regularity in the packet formatting.

-- 
Jeff Haas 
NextHop Technologies