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

From: Qin Wu <[email-masked]>
Date: Wed, 11 Sep 2013 09:25:56 +0000

Hi, authors:
Sorry for late review again. I think this draft is very useful draft.
Here are a few minor comments:
1. Section 2 paragraph 2,3.
It is not obvious that the relationship between paragraph 2 and 3.
It is not clear the relationship between two registries in paragraph 2 and the registry in the paragraph 3.
It looks some extended community type has extended community sub-type while some not.

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.

3. Section 4, it said:
"
When an allocation from both registries is requested, 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?

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.

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?

If multiple Extended Community Sub-Type can be allocated for the same Extended Community Type,
Why it should be mandatory to allocate a value in IPv6 address specific Extended Community registry?
What about other Extended Community Sub-types? Is there any mandatory Extended Community Sub-type?

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 the
   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.
"

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.

Regards!
-Qin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, August 23, 2013 10:57 PM
To: idr wg
Cc: 'Yakov Rekhter'; [email-masked]
Subject: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt

This messages starts a 2 week WG Last call for:

IANA Registries for BGP Extended Communities
draft-ietf-idr-extcomm-iana-00.txt
https://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-iana/

What this document does:

   This document reorganizes the IANA Registries for the type values and
   sub-type values of BGP Extended Communities attribute and the BGP
   IPv6-Address-Specific Extended Communities attribute.

Comment early, frequently and often.

Sue and John
Idr-co-chairs

---

From: Eric Rosen <[email-masked]>
Date: Thu, 12 Sep 2013 11:43:15 -0400

Thanks for reviewing this draft!

> 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.

> 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

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

> 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.

> 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 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.

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.

---

From: Qin Wu <[email-masked]>
Date: Fri, 13 Sep 2013 02:22:33 +0000

Hi,Eric:
Thanks for your clarifications. I have removed the comments I have no issues.
Here are two followup comments.

Regards!
-Qin
-----Original Message-----
From: Eric Rosen [mailto:[email-masked]] 
Sent: Thursday, September 12, 2013 11:43 PM
To: Qin Wu
Cc: Susan Hares; idr wg; 'Yakov Rekhter'; [email-masked]
Subject: Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt

[Qin]: Really? by reading RFC5701, I think IPv6 Address Specific BGP Extended Community Attribute
Follow the similar format as Extended Communities Attribute, to identify IPv6 address specific BGP
Extended Community Attribute, you also only need to look at the first two octets, the first octet
Is used to indicate whether it is transitive or non-transitive attribute, the second octet is used
To indicate subtype. It doesn't matter whether the value is 6 octets or 18 octets, doesn't it?

So why not use similar syntax and format of section 5.2.6 and section 5.2.7 and change section 5.3 as follows:
OLD TEXT:
"

5.3. Registries for IPv6-Address-Specific ECs

5.3.1. Transitive Types

   This registry contains values of the two high-order octets of an
   IPv6-Address-Specific Extended Communities attribute.

Registry Name: TRANSITIVE IPV6 ADDRESS SPECIFIC
               EXTENDED COMMUNITY TYPES

     RANGE                REGISTRATION PROCEDURE

     0x0000-0x00FF        First Come, First Served

     TYPE VALUE           NAME

     0x0002               Route Target
     0x0003               Route Origin
     0x0004               OSPFv3 Route Attributes (deprecated)
     0x000B               VRF Route Import
     0x0010               Cisco VPN-Distinguisher
     0x0011               UUID-based Route Target

5.3.2. Non-Transitive Types

   This registry contains values of the two high-order octets of an
   IPv6-Address-Specific Extended Communities attribute.

Registry Name: NON-TRANSITIVE IPV6 ADDRESS SPECIFIC
               EXTENDED COMMUNITY TYPES

     RANGE                REGISTRATION PROCEDURE

     0x4000-0x40FF        First Come, First Served

     None assigned

"
NEW TEXT:
"

5.3. Registries for IPv6-Address-Specific ECs

5.3.1. Transitive Types

   This registry contains values of the second octet (the "Sub-Type
   field") of an IPv6-Address-Specific Extended Communities attribute,
   when the value of the first octet
   (the "Type field") is 0x00.

Registry Name: TRANSITIVE IPV6 ADDRESS SPECIFIC
               EXTENDED COMMUNITY TYPES

     RANGE                REGISTRATION PROCEDURE

     0x00-0xFF        First Come, First Served

     TYPE VALUE           NAME

     0x02               Route Target
     0x03               Route Origin
     0x04               OSPFv3 Route Attributes (deprecated)
     0x0B               VRF Route Import
     0x10               Cisco VPN-Distinguisher
     0x11               UUID-based Route Target

5.3.2. Non-Transitive Types

   This registry contains values of the second octet (the "Sub-Type
   field") of an IPv6-Address-Specific Extended Communities attribute, 
   when the value of the first octet (the "Type field") is 0x40.

Registry Name: NON-TRANSITIVE IPV6 ADDRESS SPECIFIC
               EXTENDED COMMUNITY TYPES

     RANGE                REGISTRATION PROCEDURE

     0x00-0xFF        First Come, First Served

     None assigned

"

[Qin]: I can live with your explanation however I think the first sentence 
" It is recommended that the allocation policy described in section 2 be
 used. " I quoted above is sufficient.

    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. 

[Qin]: One or both is referred to transitive or both transitive and non-transitive?
If it is, it should be clear in the text.

 The requester

[Qin]: Good example. From this example, I can see the codepoint as subtype 
allocated in IPv6-address-Specific Extended Community is same as the codec 
allocated in other three registries.
So I believe IPv6-address-Specific Extended Community should use the similar
Syntax as the other registries, i.e., using 1st octet to indicate type and 2nd
Octet to indicate subtype.

Also I believe it is better to add a reference to each registry to point out
Where the attributed is defined and how to use this attribute.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 16 Sep 2013 14:26:31 -0400

> I believe it is better to add a reference to each registry to point out

These references should appear on the IANA web page (where the line length
is not restricted to 72 characters), but we didn't think it necessary to
include them in the draft

> I believe IPv6-address-Specific Extended Community should use the similar
> Syntax as the other registries, i.e., using 1st octet to indicate type and
> 2nd Octet to indicate subtype.

To me, there's not much value in having separate Sub-Type registries for the
IPv6-address-specific extended communities, as an IPv6-address-specific
extended community always begins with two octets of registered codepoint.
This is much simpler than the case of the "ordinary" extended communities,
which may begin with either octet or two octets of registered codepoint.  So
I think what we have proposed is satisfactory.  Of course, your proposal
would work also.

(What makes it complicated to administer the codepoints for the  "ordinary"
extended communities is that fact that the sub-type field isn't necessarily
present; sometimes the second octet is part of the value field.  The
IPv6-address-specific extended community doesn't have this issue.)