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

[Qin Wu <[e-mail]>]

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:[e-mail]] 
Sent: Thursday, September 12, 2013 11:43 PM
To: Qin Wu
Cc: Susan Hares; idr wg; 'Yakov Rekhter'; [e-mail]
Subject: Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt

Thanks for reviewing this draft!

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

[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

"


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

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

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

[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
    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)

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