Internet DRAFT - draft-rosen-idr-extcomm-iana

draft-rosen-idr-extcomm-iana









IDR Working Group                                          Eric C. Rosen
Internet Draft                                       Cisco Systems, Inc.
Intended Status: Standards Track
Updates: 4360,5701                                         Yakov Rekhter
Expires: November 30, 2013                        Juniper Networks, Inc.

                                                            May 30, 2013


              IANA Registries for BGP Extended Communities


                  draft-rosen-idr-extcomm-iana-00.txt

Abstract

   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.  This is done
   in order to remove inter-dependencies among the registries, thus
   making it easier for IANA to determine which codepoints are available
   for assignment in which registries.  This document also clarifies the
   information that must be provided to IANA when requesting an
   allocation from one or more of these registries.  These changes are
   compatible with the existing allocations, and thus do not affect
   protocol implementations.  The changes will however impact the "IANA
   Considerations" sections of future protocol specifications.  This
   document updates RFCs 4360 and 5701.


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.




Rosen & Rekhter                                                 [Page 1]


Internet Draft     draft-rosen-idr-extcomm-iana-00.txt          May 2013


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Copyright and License Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

































Rosen & Rekhter                                                 [Page 2]


Internet Draft     draft-rosen-idr-extcomm-iana-00.txt          May 2013


Table of Contents

 1          Introduction  ..........................................   4
 2          Types, Sub-Types, and Registries  ......................   4
 3          Applicability to IPv6 Address Specific EC Attribute  ...   5
 4          How to Request EC Type and/or Sub-Type Codepoints  .....   5
 5          IANA Registries  .......................................   7
 5.1        Registries for the TYPE Field  .........................   7
 5.1.1      Transitive Types  ......................................   7
 5.1.2      Non-Transitive Types  ..................................   9
 5.2        Registries for the Sub-Type Field  .....................  10
 5.2.1      EVPN Sub-Types  ........................................  10
 5.2.2      Transitive Two-Octet AS-Specific Sub-Types  ............  10
 5.2.3      Non-Transitive Two-Octet AS-Specific Sub-Types  ........  11
 5.2.4      Transitive Four-Octet AS-Specific Sub-Types  ...........  12
 5.2.5      Non-Transitive Four-Octet AS-Specific Sub-Types  .......  12
 5.2.6      Transitive IPv4-Address-Specific Sub-Types  ............  13
 5.2.7      Non-Transitive IPv4-Address-Specific Sub-Types  ........  13
 5.2.8      Transitive Opaque Extended Community Sub-Types  ........  14
 5.2.9      Non-Transitive Opaque Extended Community Sub-Types  ....  14
 5.2.10     Generic Transitive Experimental Use Sub-Types  .........  15
 5.3        Registries for IPv6-Address-Specific ECs  ..............  15
 5.3.1      Transitive Types  ......................................  15
 5.3.2      Non-Transitive Types  ..................................  16
 6          IANA Considerations  ...................................  16
 7          Security Considerations  ...............................  16
 8          Acknowledgments  .......................................  16
 9          Authors' Addresses  ....................................  16
10          Normative References  ..................................  17





















Rosen & Rekhter                                                 [Page 3]


Internet Draft     draft-rosen-idr-extcomm-iana-00.txt          May 2013


1. Introduction

   RFC 4360 [RFC4360] defines the BGP "Extended Communities" (EC)
   attribute.  This attribute consists of a sequence of eight-octet
   "extended communities".  The high-order octet is defined to be the
   "Type" field.  Each Type has a range of values for "Transitive
   Extended Community Types" and a range of values for "Non-transitive
   Extended Community Types".  Some of these ranges are further sub-
   divided into a sub-range of values to be assigned by IANA under the
   "Standards Action (with Early Allocation)" policy a sub-range of
   values to be assigned by IANA under the "First Come First Served"
   policy, and a sub-range for "experimental use". (See [RFC5226],
   [RFC4020], and [RFC3692] for an explanation of these policies.)

   For some Extended Community Types, the second octet of the Extended
   Community is a "Sub-Type" field, and the remaining six octets are the
   "Value" field.  These are referred to as "Extended Types".  For other
   types, there is no Sub-Type field, and the Value field contains seven
   octets.  These are referred to as "Regular Types".

   RFC 4360 is not very specific about how the IANA registries for
   Extended Community Types and/or Sub-Types are to be organized, and
   this has led to some confusion.  The purpose of this document is to
   reorganize the registries to make the IANA codepoint allocation task
   more straightforward.


2. Types, Sub-Types, and Registries

   The high-order octet of an Extended Community will be known as the
   "Type Field".

   There will be one IANA registry for "Transitive Extended Community
   Types" (see section 5.1.1), and one for "Non-transitive Extended
   Community Types" (section 5.1.2).  Each registry specifies three
   ranges, and each range is associated with a particular IANA
   allocation policy.

   There will be a set of IANA registries for Extended Community Sub-
   Types (see section 5.2).  Each such registry will have a range of
   0x00-0xFF.  Values in the range 0x00-0xBF are assignable by IANA
   according to the "First Come, First Served" allocation policy of
   [RFC5226].  Values in the range 0xC0-0xFF are assignable by IANA
   according to the "IETF Review" allocation policy of [RFC5226].

   If a particular Type has Sub-Types, that Type's entry in its Type
   registry identifies its Sub-Type registry.  Note that some Types do
   not have Sub-Types.  When the request is made to establish a new Type



Rosen & Rekhter                                                 [Page 4]


Internet Draft     draft-rosen-idr-extcomm-iana-00.txt          May 2013


   registry, the request must specify whether or not there is to be a
   Sub-Type registry associated with that Type.

   Whether a given Type has Sub-Types is determined when the Type is
   initially defined; this cannot be changed later.


3. Applicability to IPv6 Address Specific EC Attribute

   RFC 5701 [RFC5701] defines the IPv6 Address Specific Extended
   Community to be a 20-octet quantity whose high order two octets are
   the "Type Field".  The high order octet is either 0x00, indicating a
   transitive Extended Community, or 0x40, indicating a Non-transitive
   Extended Community.  The second octet is said to be a "Sub-Type" and
   it is suggested that the Sub-Types are the same as the Sub-Types for
   the IPv4-Address-Specific Extended Community.  However, the existing
   IANA codepoint allocations for this octet do not always match the
   corresponding allocations for the IPv4-Address-Specific Extended
   Community Sub-Types.

   This document modifies RFC 5701 by removing any requirement for the
   values of the second octet of the IPv6-Address-Specific Extended
   Community Type codepoints to match the codepoints in the
   IPv4-Address-Specific Sub-Types registry.

   This document requests IANA to create two IPv6-Address-Specific
   Extended Community registries, one for transitive communities and one
   for non-transitive communities.  See section 5.3.



4. How to Request EC Type and/or Sub-Type Codepoints

   When a codepoint is needed for a new Extended Community, the
   requester should first determine whether an existing Type can be
   used.  If so, IANA should be asked to allocate a codepoint from the
   corresponding Sub-Type registry, if there is one.

   If a new Extended Community Type is needed, the requester should ask
   IANA to allocate a new type from either the "Transitive Extended
   Community Types" registry, the "Non-transitive Extended Community
   Types" registry, or both.  It is up to the requester to state whether
   an allocation is needed from one or both of these registries.  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.  If so, it is the responsibility of the requester to
   explicitly request this of IANA.




Rosen & Rekhter                                                 [Page 5]


Internet Draft     draft-rosen-idr-extcomm-iana-00.txt          May 2013


   If a new Extended Community Type is needed, and the new Type is to
   have Sub-Types, the requester should specify whether an existing Sub-
   Type registry can be used for the new Type, or whether a new Sub-Type
   registry is needed.  (At the current time, every Type that has Sub-
   Types is associated with a unique Sub-Type registry.  It is possible
   that in the future a new Type registry may be created that is
   associated with a pre-existing Sub-Type registry.)  In either case,
   if a new Sub-Type value needs to be allocated from a particular Sub-
   Type registry, the request should explicitly identify the registry.

   If the creation of a new Sub-Type registry is requested, the range of
   values is always 0x00-0xFF.  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.

   Commonly, a new Extended Community is defined such that it can be of
   several Types.  E.g., one may want to define a new Extended Community
   so that it can be either transitive or non-transitive, so that it can
   be either of the Two-octet AS Number Type or the Four-octet AS Number
   Type, etc.  The requester is responsible for explicitly asking IANA
   to allocate codepoints in all the necessary Type and/or Sub-Type
   registries.

   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.












Rosen & Rekhter                                                 [Page 6]


Internet Draft     draft-rosen-idr-extcomm-iana-00.txt          May 2013


5. IANA Registries

   IANA is to replace the pre-existing BGP Extended Communities
   registries with the registries described in this section.

   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.  The authors will work with IANA to ensure
   that this is done correctly.

   The registries reproduced below do not include the "references" or
   "date" fields of the registries, because it is difficult to
   incorporate those within the 72-character line limitation of RFCs.
   The references and associated dates must be copied from the current
   registries when the new registries are introduced; the authors will
   work with IANA to ensure this this information is carried over
   correctly to the new registry organization.


5.1. Registries for the TYPE Field

5.1.1. Transitive Types

   This registry contains values of the high-order octet (the "Type
   Field") of a Transitive Extended Community.

























Rosen & Rekhter                                                 [Page 7]


Internet Draft     draft-rosen-idr-extcomm-iana-00.txt          May 2013


Registry Name: BGP TRANSITIVE EXTENDED COMMUNITY TYPES

    RANGE               REGISTRATION PROCEDURES

    0x00-0x3F          First Come, First Served
    0x80-0x8F          Experimental Use (see RFC 3692)
    0x90-0xBF          Standards Action (early allocation per RFC 4020)


    TYPE VALUE          NAME

    0x00                Transitive Two-Octet AS-specific Extended
                        Community (Sub-Types are defined in the
                        "Transitive Two-Octet AS-specific Extended
                        Community Sub-Types" Registry)

    0x01                Transitive IPv4-Address-specific Extended
                        Community (Sub-Types are defined in the
                        "Transitive IPv4-Address-specific Extended
                        Community Sub-Types" Registry)

    0x02                Transitive Four-Octet AS-specific Extended
                        Community (Sub-Types are defined in the
                        "Transitive Four-Octet AS-specific Extended
                        Community Sub-Types" Registry)

    0x03                Transitive Opaque Extended Community
                        (Sub-Types are defined in the "Transitive
                        Opaque Extended Community Sub-Types"
                        Registry)

    0x04                QoS Marking

    0x05                CoS Capability

    0x06                EVPN (see "EVPN Extended Community Sub-type
                        Registry")

    0x08                Flow spec redirect/mirror to IP next-hop

    0x80                Generic Transitive Experimental Extended
                        Community (Sub-Types are defined in the
                        "Generic Transitive Experimental Extended
                        Community Sub-Types" Registry)







Rosen & Rekhter                                                 [Page 8]


Internet Draft     draft-rosen-idr-extcomm-iana-00.txt          May 2013


5.1.2. Non-Transitive Types

   This registry contains values of the high-order octet (the "Type
   Field") of a Non-transitive Extended Community.


Registry Name: BGP NON-TRANSITIVE EXTENDED COMMUNITY TYPES

    RANGE              REGISTRATION PROCEDURES

    0x40-0x7F          First Come, First Served
    0xC0-0xCF          Experimental Use (see RFC 3692)
    0xD0-0xFF          Standards Action (early allocation per RFC 4020)


    TYPE VALUE          NAME

    0x40                Non-Transitive Two-Octet AS-specific Extended
                        Community (Sub-Types are defined in the
                        "Non-Transitive Two-Octet AS-specific Extended
                        Community Sub-Types" Registry)

    0x41                Non-Transitive IPv4-Address-specific Extended
                        Community (Sub-Types are defined in the
                        "Non-transitive IPv4-Address-specific Extended
                        Community Sub-Types" Registry)

    0x42                Non-Transitive Four-Octet AS-specific Extended
                        (Sub-Types are defined in the "Non-Transitive
                        Four-Octet AS-specific Extended Community
                        Sub-Types" Registry)

    0x43                Non-Transitive Opaque Extended Community
                        (Sub-Types are defined in the "Non-Transitive
                        Opaque Extended Community Sub-Types" Registry)

    0x44                QoS Marking














Rosen & Rekhter                                                 [Page 9]


Internet Draft     draft-rosen-idr-extcomm-iana-00.txt          May 2013


5.2. Registries for the Sub-Type Field

5.2.1. EVPN Sub-Types

   This registry contains values of the second octet (the "Sub-Type
   field") of an extended community, when the value of the first octet
   (the "Type field") is 0x06.


Registry Name: EVPN EXTENDED COMMUNITY SUB-TYPES

    RANGE              REGISTRATION PROCEDURE

    0x00-0xBF          First Come, First Served
    0xC0-0xFF          IETF Review

    SUB-TYPE VALUE       NAME

    0x00                 MAC Mobility
    0x01                 ESI MPLS Label
    0x02                 ES Import



5.2.2. Transitive Two-Octet AS-Specific Sub-Types

   This registry contains values of the second octet (the "Sub-Type
   field") of an extended community, when the value of the first octet
   (the "Type field") is 0x00.






















Rosen & Rekhter                                                [Page 10]


Internet Draft     draft-rosen-idr-extcomm-iana-00.txt          May 2013


Registry Name: TRANSITIVE TWO-OCTET AS-SPECIFIC
               EXTENDED COMMUNITY SUB-TYPES

    RANGE              REGISTRATION PROCEDURE

    0x00-0xBF          First Come, First Served
    0xC0-0xFF          IETF Review


    SUB-TYPE VALUE     NAME

    0x02               Route Target
    0x03               Route Origin
    0x05               OSPF Domain Identifier
    0x08               BGP Data Collection
    0x09               Source AS
    0x0A               L2VPN Identifier
    0x10               Cisco VPN-Distinguisher



5.2.3. Non-Transitive Two-Octet AS-Specific Sub-Types

   This registry contains values of the second octet (the "Sub-Type
   field") of an extended community, when the value of the first octet
   (the "Type field") is 0x40.


Registry Name: NON-TRANSITIVE TWO-OCTET AS-SPECIFIC
               EXTENDED COMMUNITY SUB-TYPES

    RANGE              REGISTRATION PROCEDURE

    0x00-0xBF          First Come, First Served
    0xC0-0xFF          IETF Review


    SUB-TYPE VALUE     NAME

    0x04               Link Bandwidth Extended Community











Rosen & Rekhter                                                [Page 11]


Internet Draft     draft-rosen-idr-extcomm-iana-00.txt          May 2013


5.2.4. Transitive Four-Octet AS-Specific Sub-Types

   This registry contains values of the second octet (the "Sub-Type
   field") of an extended community, when the value of the first octet
   (the "Type field") is 0x02.


Registry Name: TRANSITIVE FOUR-OCTET AS-SPECIFIC EXTENDED
               COMMUNITY SUB-TYPES

    RANGE              REGISTRATION PROCEDURE

    0x00-0xBF          First Come, First Served
    0xC0-0xFF          IETF Review


    SUB-TYPE VALUE     NAME

    0x02               Route Target
    0x03               Route Origin
    0x04               Generic
    0x05               OSPF Domain Identifier
    0x08               BGP Data Collection
    0x09               Source AS
    0x10               Cisco VPN Identifier



5.2.5. Non-Transitive Four-Octet AS-Specific Sub-Types

   This registry contains values of the second octet (the "Sub-Type
   field") of an extended community, when the value of the first octet
   (the "Type field") is 0x42.


Registry Name: NON-TRANSITIVE FOUR-OCTET AS-SPECIFIC
               EXTENDED COMMUNITY SUB-TYPES

    RANGE              REGISTRATION PROCEDURE

    0x00-0xBF          First Come, First Served
    0xC0-0xFF          IETF Review


    SUB-TYPE VALUE     NAME

    0x04               Generic




Rosen & Rekhter                                                [Page 12]


Internet Draft     draft-rosen-idr-extcomm-iana-00.txt          May 2013


5.2.6. Transitive IPv4-Address-Specific Sub-Types

   This registry contains values of the second octet (the "Sub-Type
   field") of an extended community, when the value of the first octet
   (the "Type field") is 0x01.


Registry Name: TRANSITIVE IPV4-ADDRESS-SPECIFIC
               EXTENDED COMMUNITY SUB-TYPES

    RANGE              REGISTRATION PROCEDURE

    0x00-0xBF          First Come, First Served
    0xC0-0xFF          IETF Review


    SUB-TYPE VALUE     NAME

    0x02               Route Target
    0x03               Route Origin
    0x05               OSPF Domain Identifier
    0x07               OSPF Route ID
    0x0A               L2VPN Identifier
    0x0B               VRF Route Import
    0x10               Cisco VPN-Distinguisher



5.2.7. Non-Transitive IPv4-Address-Specific Sub-Types

   This registry contains values of the second octet (the "Sub-Type
   field") of an extended community, when the value of the first octet
   (the "Type field") is 0x41.


Registry Name: NON-TRANSITIVE IPV4-ADDRESS-SPECIFIC
               EXTENDED COMMUNITY SUB-TYPES

     RANGE              REGISTRATION PROCEDURE

    0x00-0xBF          First Come, First Served
    0xC0-0xFF          IETF Review

    None Assigned







Rosen & Rekhter                                                [Page 13]


Internet Draft     draft-rosen-idr-extcomm-iana-00.txt          May 2013


5.2.8. Transitive Opaque Extended Community Sub-Types

   This registry contains values of the second octet (the "Sub-Type
   field") of an extended community, when the value of the first octet
   (the "Type field") is 0x03.


Registry Name: TRANSITIVE OPAQUE
               EXTENDED COMMUNITY SUB-TYPES

     RANGE                REGISTRATION PROCEDURE

     0x00-0xBF            First Come, First Served
     0xC0-0xFF            IETF Review

     SUB-TYPE VALUE       NAME

     0x06                 OSPF Route Type
     0x0B                 Color Extended Community
     0x0C                 Encapsulation Extended Community
     0x0D                 Default Gateway



5.2.9. Non-Transitive Opaque Extended Community Sub-Types

   This registry contains values of the second octet (the "Sub-Type
   field") of an extended community, when the value of the first octet
   (the "Type field") is 0x43.


Registry Name: NON-TRANSITIVE OPAQUE
               EXTENDED COMMUNITY SUB-TYPES

     RANGE                REGISTRATION PROCEDURE

     0x00-0xBF            First Come, First Served
     0xC0-0xFF            IETF Review


     SUB-TYPE VALUE       NAME

     0x00                 BGP Origin Validation State








Rosen & Rekhter                                                [Page 14]


Internet Draft     draft-rosen-idr-extcomm-iana-00.txt          May 2013


5.2.10. Generic Transitive Experimental Use Sub-Types

Registry Name: BGP GENERIC NON-TRANSITIVE EXPERIMENTAL USE
               EXTENDED COMMUNITY SUB-TYPES

    RANGE              REGISTRATION PROCEDURE

    0x00-0xBF          First Come, First Served
    0xC0-0xFF          IETF Review


    SUB-TYPE VALUE      NAME

    0x06                Flow spec traffic-rate
    0x07                Flow spec traffic-action
    0x08                Flow spec redirect
    0x09                Flow spec traffic-remarking
    0x0A                Layer2 Info Extended Community




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







Rosen & Rekhter                                                [Page 15]


Internet Draft     draft-rosen-idr-extcomm-iana-00.txt          May 2013


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



6. IANA Considerations

   Instructions for IANA are found in section 5.


7. Security Considerations

   No security considerations are raised by this document.


8. Acknowledgments

   We thank Amanda Baber of IANA for educating us on some of the
   problems faced by IANA staff when responding to requests for BGP
   Extended Community Type and Sub-Type codepoint allocations.


9. Authors' Addresses

   Yakov Rekhter
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   Email: yakov@juniper.net










Rosen & Rekhter                                                [Page 16]


Internet Draft     draft-rosen-idr-extcomm-iana-00.txt          May 2013


   Eric C. Rosen
   Cisco Systems, Inc.
   1414 Massachusetts Avenue
   Boxborough, MA, 01719
   Email: erosen@cisco.com



10. Normative References

   [RFC3692] "Assigning Experimental and Testing Numbers Considered
   Useful", Narten, RFC 3692, January 2004

   [RFC4020] "Early IANA Allocation of Standards Track Code Points",
   Kompella, Zinin, RFC 4020, February 2005

   [RFC4360] "BGP Extended Communities Attribute", Sangli, Tappan,
   Rekhter, RFC 4360, February 2006

   [RFC5226] "Guidelines for Writing an IANA Considerations Section in
   RFCs", Narten, Alvestrand, RFC 5226, May 2008

   [RFC5701] "IPv6 Address Specific BGP Extended Community Attribute",
   Rekhter, RFC 5701, November 2009



























Rosen & Rekhter                                                [Page 17]