Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt

[Eric Rosen <[e-mail]>]

Thanks for reviewing this draft!

> 1. Section 2 paragraph 2,3.

> It is not obvious that the relationship between paragraph 2 and 3.

Paragraph 2 talks about the Extended Community Type  registries; there are
two such registries, as described in sections 5.1.1 and 5.1.2.

Paragraph 3 talks about the Extended Community Sub-Type registries.  There
are currently 10 such registries, as described in sections 5.2.1-5.2.10.  

Separating the Type registries from the Sub-type registries is the major
change proposed by this draft.

> It is not clear the relationship between two registries in paragraph 2 and
> the registry in the paragraph 3.

As stated in paragraph 4: "If a particular Type has Sub-Types, that Type's
entry in its Type registry identifies its Sub-Type registry."

That is, each entry in a Type registry is known as a "Type".  Each Type
is associated with a numerical codepoint, and optionally with a Sub-type
registry.

> It looks some extended community type has extended community sub-type
> while some not.

Exactly correct, some types have sub-types and some don't.

> 2. Section 3 Applicability to IPv6 Address Specific EC Attribute

> It looks IPv6 Address Specific Extended Community is one special example
> of  Extended Community Types since the first one octet indicates Extended
> Community types.  But the second octet indicate extended Community
> sub-type.

> I am wondering why not base on the second octet and see IPv6 address
> specific EC as a IPv6 address specific sub type.

Actually, the IPv6 Address Specific Extended Communities attribute is not an
Extended Communities attribute at all.  It is a completely different BGP
Path attribute.  The Extended Communities attribute consists of 64-bit
extended community values, and those value fields aren't large enough to
hold an IPv6 address.

> 3. Section 4, it said:

> When an allocation from both registries is requested,

Note that "both registries" in this context means the "Transitive Extended
Community Types" registry, and the "Non-transitive Extended Community
Types" registry.

> the requester may find it desirable for both allocations to share the same
> low-order six bits.

> Why make both allocation to share the same low-order six bits? Make them
> easy to be recognized as two allocation related to the same EC type? Why
> should be lower-order six bits?  Is it too restrictive?

To get a new Type codepoint from one of the registries, you have to specify
the registry, and you have to choose one of the assignable ranges for that
registry.  Once you do this, there are only six bits (the low-order six
bits) in the type field for IANA to allocate.

Note for example that "Non-Transitive Opaque Extended Community" has
codepoint 0x43, and "Transitive Opaque Extended Community" has codepoint
0x03.  So there are two types of "opaque extended community", and their
respective codepoints are the same in the low-order six bits.  It is not
really necessary for this to be the case, but it's a convention that some
folks like to follow.

> 4. Section 4, 5th paragraph:
> It said:

    It is recommended that the allocation policy described in section 2 be
    used.  I.e., 0x00-0xBF to be allocated by IANA under the "First Come,
    First Served" policy, and 0xC0-0xFF to be allocated by IANA under the
    "IETF Review" policy.

> It repeats what it said in the section 2 and is a little bit
> redundant. Suggest Remove the second paragraph in this quoted text.

Section 2 describes the allocation policy for the existing Sub-Type
registries.  Section 4 recommends (but does not require) that new Sub-Type
registries created in the future use the same policy.  So I don't think it
is redundant.

> 5. Section 4,
> last two paragraph:  It said:

    When a new Extended Community is defined, it may be necessary to ask
    IANA to allocate codepoints in several Sub-Type registries.  In this
    case, it is a common practice to ask IANA to allocate the same codepoint
    value in each registry. If this is desired, it is the responsibility of
    the requester to explicitly ask IANA to allocate the same value in each
    registry.

    When a new Extended Community Sub-Type codepoint is allocated, it may
    also be desirable to allocate a corresponding value in one or both of
    the IPv6-Address-Specific Extended Community registries.  The requester
    is responsible for requesting this allocation explicitly.  If the
    requester would like the same numerical value to be allocated in an
    IPv6-Address-Specific Extended Community registry that is allocated in
    some other registry, it is the responsibility of the requester to
    explicitly ask this of IANA.

> I don't understand these two last  paragraphs. When we decided the first
> high order octet for Extended Community Type, Then we need to decide the
> second octet for Extended Community Sub-Type?  Can we allocate multiple
> codepoints from multiple Sub-Type registry in this case?

As an example, look at the "Route Target" Extended Community.  There are
four different ways to construct a Route Target:

1. a. Type = Transitive Two-Octet AS-Specific Extended Community
   b. Sub-Type = Route Target (codepoint value 2 from the registry in 5.2.2)

2. a. Type = Transitive Four-Octet AS-Specific Extended Community
   b. Sub-Type = Route Target (codepoint value 2 from the registry in 5.2.4)

3. a. Type = Transitive IPv4-Address-Specific Extended Community
   b. Sub-type = Route Target (codepoint value 2 from the registry in 5.2.6)

4. Transitive IPv6-Address-Specific Extended Community (codepoint value 2
   from the registry in 5.3.1)

Note that if we want to be able to construct Route Targets in these four
different ways, it requires a codepoint allocation in four different
registries.  The same codepoint value happens to be used in all four, but
that is not required.

> 6.Section 5,2nd paragraph
> Suggest the following change:

OLD TEXT:

    Any Extended Community Type or Sub-type codepoints allocated by IANA
    between the date of this document that the date at which registries are
    reorganized must also be incorporated into the new registry
    organization.

NEW TEXT:

    Any Extended Community Type or Sub-type codepoints allocated by IANA
    between the date of this document and the date at which the registries
    are reorganized must also be incorporated into the new registry
    organization.

Fixed.

> 7. Section 5,it said:

    the authors will work with IANA to ensure this this information is
    carried over correctly to the new registry organization. The word this
    repeats twice.

Fixed.