BGP Extended Communities Attribute
Note: This ballot was opened for revision 09 and is now closed.
(Harald Alvestrand) Discuss
Discuss (2005-02-17 for -)
Got a review from Mark Allman just before telechat, indicating that stuff needs to be cleared up. This is a placeholder.
(Thomas Narten) Discuss
Discuss (2005-03-09 for -)
High-level: this document could be a lot clearer in terms of what it does. After re-reading multiple times, I conclude that what this document could/should do is: Defines a 1 octet type field (not 2-octet), but that some of the attributes have a 1-octet "code" field (ala ICMP). The codes are specific to the type message, and some type codes don't even bother defining any codes. Thus, what IANA needs to do is create a type registry, where types are 1-octet values, and that each assigned value may (or may not) have code field, as defined by the specifically defined type. So there is no "extended type" per se. It's just that some types have a sub-type or "code". > I - IANA authority bit > > Value 0: IANA assignable type using the "First Come First > Serve" policy > > Value 1: IANA assignable type using the IETF Consensus > policy and experimental I don't understand the value of this or what the technical point is. Is there a _technical_ distinction between types with the high-order bit set? I think no. But in that case, a better way to specify the above is to just say: Types 0-127 are assigned through "FCFS", types 128-255 are assigned via "IETF Consensus". Finally, the above policies make me a little uncomfortable. We have a number of exmaples where FCFS means someone goes to IANA and gets an assignment. No Internet draft. No IETF review (even cursory). Is this _really_ what the WG wants? I.e., couldn't you at least require an Internet-Draft with (say) approval of the WG? While this isn't an RFC2434 policy, the WG can certainly invent one, tailered to its needs. For example, something like: Types 0-127 are assigned through "Expert Review" per RFC 2434. The intention is that the Expert Review consist of review of an Internet Draft (for which there is an expectation that an RFC will eventually be publishd), with approval of the IDR WG of the allocation. In the event that the IDR WG no longer exists, Expert review would include consultation with the IDR mailing list or appropriate follow-on list where the BGP community can be openly consulted. Finally, "experimental" use has a very specific meaning (see RFC 3692) and IANA doesn't assign them. IF you want to reserve some for experimentation, this document should just do so by saying something like: Types 250-255 are reserved for Experinemtnal use as defined in RFC 3692. > T - Transitive bit > > Value 0: The community is transitive across ASes > > Value 1: The community is non-transitive across ASes Here is a bit that does have technical significance. Too bad its not the most significant bit, so that you coudl say something like: types 0-127 are transitive across ASes, types 128-255 are non-transitive. But with the bit where it is, you really want to split the registry into sub-registries, one for transitive and one for non-transitive. Can this bit be made the most significant or is it too late for that? I.e., I think what you need to say now is something like: There are two kinds of types, transitive and non-transitive. Transitive types include the ranges 0-63, 128-192, Non-transitive types are in the range 64-127 and 193-255. Future requests for assignment of a Type value must specify the specific type of assignment that is requested. Finally, I assume the1 T-bit really does need to be part of the type value itself? I.e, can the specific type (as part of its definition) state whether an attribute is transitive or not, or is the intent that an implementation be able to specify how to handle unrecognized types? (I suspect so)
Comment (2005-03-09 for -)
Editorial (some of the following may be irrelvant based on the discuss comments): abstract could be a bit more descriptive > The Extended Community Attribute provides two important enhancements > over the existing BGP Community Attribute: Reference to bgp communities? > I - IANA authority bit > > Value 0: IANA assignable type using the "First Come First > Serve" policy > > Value 1: IANA assignable type using the IETF Consensus > policy and experimental Don't understand what the "and experimental" means here. > Remaining 6 bits: Indicates the structure of the community Are these actually reserved? Or undefined? or? > 3.2. IPv4 address specific extended community > > This is an extended type with Type Field comprising of 2 octets and > Value Field comprising of 6 octets. How will we get interoperability if the sub-type is not even defined? What values/semantics does it have? > This sub-field contains an IPv4 address assigned by IANA. what is this? a globally unique unicast address (IANA doesn't hand out addresses directly anymore) > The two members in the tuple <Type, Value> should be enumerated to > specify any community value. Based on the value of the Type field, > the remaining octets of the community should be interpreted. hard to parse: reword as: The remaining octets of the community are be interpreted based on the value of the Type field. > The Type could be either regular or extended. For a regular Type the > IANA allocates an 8-bits value; for an extended Type the IANA allo- > cates a 16-bits value. This document defines some sub-types (apparently, but doesn't tell IANA what values to register. This seems in conflict with the above. > The value allocated for a regular Type MUST NOT be reused as the > value of the high-order octet when allocating an extended Type. The > value of the high-order octet allocated for an extended Type MUST NOT > be reused when allocating a regular Type. This suggests to me, that the "sub-type" is not actually a type, but like the "code" for an ICMP type. I.e, it has meaning only relative to a specific type. If that is the case, the document should just say that (and eliminate a bunch of unclarity) > Future assignment are to be made using either the Standards Action > process defined in [RFC2434], or the Early IANA Allocation process > defined in [kompella-zinin], or the "First Come First Served" policy > defined in [RFC2434]. I'm not sure I understand the motivatoin for the above... I.e., it looks like the entire name space can be allocated FCFS. If so, why have more restrictive policies as well? (and is FCFS really the right policy?) > The Type values 0x80-0x8f and 0xc0-0xcf for regular Types, and > 0x8000-0x8fff and 0xc000-0xcfff for extended Types are experimental, > and are not to be assigned by IANA. The range reserved for experimentation is huge... not really what it was intended for.
(Bill Fenner) Yes
(Brian Carpenter) (was Discuss) No Objection
(Ted Hardie) No Objection
(Sam Hartman) No Objection
(Scott Hollenbeck) No Objection
Comment (2005-02-15 for -)
The text in section 2 could be clearer about what actually identifies a regular type and an extended type. After reading the text I half expected to see something like a bit flag being used to ID one or the other, but there's no bit flag and little additional text included to explain what distinguishes one type from the other. It might be a good idea to supplement "The value of the high-order octet of the Type Field determines if an extended community is a Regular type or an Extended type" with some additional words to note that the value registered with IANA determines if a type is extended or regular.
(Russ Housley) (was Discuss) No Objection
The Abstract is insufficient. It does not even mention the Extended Community Attribute. The document authors need to turn off hyphenation.
(David Kessens) (was Discuss) No Objection
This document lacks an index and contains non US ASCII characters. --- Value Field: The encoding of the Value Field is dependent on the "type" of the community as specified by the Type Field. Two extended communities are declared equal only when all 8 octets of their encoding are equal. --- the word 'encoding' is used in slightly different ways. I suggest to avoid the word in the second sentence.
(Allison Mankin) No Objection
(Jon Peterson) No Objection
(Mark Townsley) (was Discuss) No Objection
(Margaret Wasserman) No Objection
(Bert Wijnen) No Objection
No further objections