BGP Extended Communities Attribute
RFC 4360

Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.

Note: This ballot was opened for revision 08 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

Types 250-255 are reserved for Experinemtnal use as defined in RFC

>             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

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

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

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

>    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

Comment (2005-02-16 for -09)
  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

Comment (2005-02-17 for -09)
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

Comment (2005-07-06 for -)
No further objections

( Alex Zinin ) (was Discuss) No Objection