BGP Extended Communities Attribute
RFC 4360

Summary of changes in -09: - 4 byte AS communities removed, since there are no implementations. - Link Bandwidth community removed, since there is no description how ...

Summary of changes in -09:
- 4 byte AS communities removed, since there are no implementations.
- Link Bandwidth community removed, since there is no description how to use it.
- Equality comparison update
- Clarify that the Class (Regular or Extended) is not in the structure of the type but in the registration
- Abtract rewritten
- Add a reference to [BGP-MPLS-VPN] for the Route Target & Route Origin
- Clarify that the security considerations are the same as for RFC 1997

[Ballot discuss] 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 ...

[Ballot discuss]
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)

[Ballot comment] This document lacks an index and contains non US ASCII characters. --- Value Field: The encoding of the Value Field is dependent on the ...

[Ballot comment]
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.