<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-heitz-idr-large-community-00" ipr="trust200902">
  <front>
    <title abbrev="Large BGP Community">Large BGP Community</title>

    <author fullname="Jakob Heitz" initials="J. " surname="Heitz">
      <organization>Cisco</organization>
      <address>
        <postal>
          <street>170 West Tasman Drive</street>
          <city>San Jose, CA</city>
          <region>CA</region>
          <code>95054</code>
          <country>USA</country>
        </postal>
        <email>jheitz@cisco.com</email>
      </address>
    </author>

    <author fullname="Keyur Patel" initials="K. " surname="Patel">
      <organization>Cisco</organization>
      <address>
        <postal>
          <street>170 West Tasman Drive</street>
          <city>San Jose</city>
          <region>CA</region>
          <code>95054</code>
          <country>USA</country>
        </postal>
        <email>keyupate@cisco.com</email>
      </address>
    </author>

    <author fullname="Job Snijders" initials="J." surname="Snijders">
        <organization abbrev="NTT">NTT Communications, Inc.</organization>
        <address>
            <postal>
                <street>Theodorus Majofskistraat 100</street>
                <code>1065 SZ</code>
                <city>Amsterdam</city>
                <country>NL</country>
            </postal>
            <email>job@ntt.net</email>
        </address>
    </author>

    <author fullname="Ignas Bagdonas" initials="I. " surname="Bagdonas">
      <organization>Equinix</organization>
      <address>
        <postal>
          <street></street>
          <city>London</city>
          <country>UK</country>
        </postal>
        <email>ibagdona.ietf@gmail.com</email>
      </address>
    </author>

    <date/>

    <area>Routing</area>
    <workgroup>IDR</workgroup>
    <keyword>BGP</keyword>
    <keyword>communities</keyword>

    <abstract>
      <t>A new type of BGP community attribute that contains communities that each hold a 4-octet AS number and a 6-octet opaque field is defined.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
    </note>

  </front>

  <middle>
    <section title="Introduction">
      <t>A BGP Community attribute is defined that encodes 12 byte communities, suitable for 4-Octet Autonomous System Numbers that require a 6-Octet Local Administrator field.</t>
      <t>The 2-octet AS Specific Extended Community defined in <xref target="RFC4360"/> has been widely used. 4-octet AS numbers as defined by <xref target="RFC4893"/> are unable to make use of this popular extended community. Subsequently, <xref target="RFC5668"/> defined a 4-octet AS Specific Extended community. However, to make room for the extra 2 octets of AS number, the Local Administrator field was shrunk from 4 octets to 2. This document defines a community to extend that to 6 octets.</t>
      <t>To ensure rapid and smooth adoption of the new community attribute, it must be as similar to the extended community as possible, only bigger.</t>
    </section>

    <section title="Large BGP Community Attribute">
      <t>The Large Community Attribute is a transitive optional BGP attribute, with the Type Code (suggested 41) to be assigned by IANA. The attribute consists of a set of "Large Communities". All routes with the Large Community attribute belong to the communities listed in the attribute.</t>
      <t>Each Large Community is encoded as a 12-octet quantity, as follows:
<figure align="center"><artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| T |   Type  |   Sub-Type    |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          Value                +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure></t>
      <t>The fields are as shown below:
      <list style='hanging' hangIndent='10'>
          <t hangText='     I -'>IANA authority bit
              <list style='hanging' hangIndent='5'>
                 <t hangText='Value 0:'>IANA-assignable type using the "First Come First Serve" policy</t>
                 <t hangText='Value 1:'>Part of this Type Field space is for IANA assignable types using either the Standard Action or the Early IANA Allocation policy. The rest of this Type Field space is for Experimental use.</t>
               </list>
           </t>
           <t hangText='     T -'>Transitivity field
              <list style='hanging' hangIndent='5'>
                 <t hangText='Value 0:'>The community is transitive across all ASes.</t>
                 <t hangText='Value 1:'>The community is transitive across AS boundaries, but not across an administration boundary. An administration in this sense is an arbitrary set of connected ASes, possibly owned by a single administration. How such an administration boundary is determined is out of scope of this document.</t>
                 <t hangText='Value 2:'>The community is transitive across Confederation member AS boundaries, but not across a confederation boundary or across an AS boundary that does not use confederations.</t>
                 <t hangText='Value 3:'>The community is not transitive across any AS boundary, including Confederation Member AS.</t>
              </list>
          </t>
          <t hangText='     Type -'>5 bits describing how the value field is divided. One type, the 4-Octet AS Specific Large Community is described in this document.</t>
          <t hangText='     Sub-type -'>describes the meaning of the value field.</t>
          <t hangText='     Value -'>The actual information according to the sub-type.</t>
       </list></t>
      <t>The Transitivity field is only a hint to BGP speakers that do not implement or understand the specific community. In some cases it makes sense to send a community across one boundary but not the next. An example is the Link Bandwidth Extended Community.</t>
      <t>The Transitivity field is not implicitly associated with the Type and Sub-Type fields the way they are in Extended Communities. The Transitivity field should be set by the originator based upon individual circumstances at the originator</t>
    </section>

    <section title="4-Octet AS Specific Large Community">
      <t>This is a Large Community type with a Value field comprising 10 octets.
<figure align="center"><artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| T |        0|   Sub-Type    |    Local Administrator 2      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Local Administrator 1                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Global Administrator                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure></t>
<t>The definition of each sub-type should specify how to set the T field. The Type field is 0. The Sub-Type is to be assigned by IANA for individual functions.</t>
<t>The Value field consists of 2 sub-fields:
       <list style='hanging'>
       <t>Global Administrator sub-field: 4 octets
            <list style='hanging'>
              <t>This sub-field contains a 4-octet Autonomous System number assigned by IANA.</t>
            </list>
       </t>
       <t>Local Administrator 1 sub-field: 4 octets</t>
       <t>Local Administrator 2 sub-field: 2 octets
            <list style='hanging'>
              <t>The organization identified by the Autonomous System number in the Global Administrator sub-field can encode any information in these sub-fields. The format and meaning of the value encoded in these sub-fields should be defined by the sub-type of the community.</t>
            </list>
       </t>
       </list></t>
       <section title="Textual Representation">
          <t>The textual representation of the 4-Octet AS Specific Large Community is A:B:C, where A is the Global Administrator, B is the Local Administrator 1 and C is the Local Administrator 2. A ranges from 0 to 4294967295. B ranges from 0 to 4294967295. C ranges from 0 to 65535. A, B and C are plain decimal numbers without leading zeroes. Each number must appear, even if it is 0. For example, "0:1:2" cannot be written as ":1:2".</t>
       </section>

    </section>

    <section title="Compatibility with Extended Communities">
       <t>Any 2-octet AS Specific Extended Community <xref target="RFC4360"/> can be converted into a 4-octet AS Specific Large Community by copying:
       <list style="symbols">
         <t>bits 1 and 2 of the Type into the Transitivity, and</t>
         <t>the Sub-Type unchanged, and</t>
         <t>the 2-octet Global Administrator into the low order octets of the 4-octet Global Administrator, and</t>
         <t>the 4-octet Local Administrator into the Local Administrator 1, and</t>
         <t>setting the remaining octets to zero.</t>
       </list>
       </t>
       <t>Notice that the Global Administrator and the Local Administrator fields in the Large community are in the reverse order compared to those in the Extended Community. This is done for better octet alignment.</t>
       <t>If a community contains an Autonomous System Number less than 65536 and a Local Administrator 2 field of zero, then it can be represented either as a 4-Octet AS Specific Large Community or a 2-Octet AS Specific Extended Community. These communities would be treated as different, even though they hold the same information. To prevent such inconsistencies, such communities SHOULD be encoded as a 2-Octet Specific Extended Community.</t>
       <t>Similarly, if a community contains an Autonomous System Number greater than 65535 and a Local Administrator field less than 65536, then it SHOULD be encoded as a 4-Octet AS Specific Extended Community as per <xref target="RFC5668"/>.</t>
    </section>

    <section title="Large Regular Communities">
       <t>The AS portion of BGP Communities described in <xref target="RFC1997"/> is too small to fit a 4-octet ASN. <xref target="I-D.ietf-idr-as4octet-extcomm-generic-subtype"/> defines an Extended Community sub-type to perform the same function with a 4-octet ASN. Large Communities will provide the same functionality, but provide an extra 4 octets of Local Administrator space.</t>
    </section>

    <section title="Security Considerations">
       <t>TBD</t>
    </section>

    <section title="IANA Considerations">
       <t>IANA is requested to assign a BGP path attribute value for the Large community attribute.</t>
       <t>IANA is requested to create and maintain a registry for the Type field of the Large Community. This document reserves the Type value 0 for the 4-Octet AS Specific Large Community.</t>
       <t>IANA is requested to create and maintain a registry for the Sub-Type field of the 4-Octet AS Specific Large Community. The initial values in the registry should be the same as those in the registry for the 2-octet AS Specific Extended Community. These values are reproduced as follows:
       <list style="hanging">
       <t hangText='0x02'>Route Target <xref target="RFC4360"/></t>
       <t hangText='0x03'>Route Origin <xref target="RFC4360"/></t>
       <t hangText='0x04'>Link Bandwidth <xref target="I-D.ietf-idr-link-bandwidth"/></t>
       <t hangText='0x05'>OSPF Domain Identifier <xref target="RFC4577"/></t>
       <t hangText='0x08'>BGP Data Collection <xref target="RFC4384"/></t>
       <t hangText='0x09'>Source AS <xref target="RFC6514"/></t>
       <t hangText='0x0a'>L2VPN Identifier <xref target="RFC6074"/></t>
       <t hangText='0x10'>Cisco VPN-Distinguisher [Eric_Rosen]</t>
       <t hangText='0x80'>Virtual-Network Identifier Extended Community <xref target="I-D.drao-bgp-l3vpn-virtual-network-overlays"/></t>
       </list></t>
       <t>As the generic sub-type defined in <xref target="I-D.ietf-idr-as4octet-extcomm-generic-subtype"/> is 4 and clashes with the value for the Link Bandwidth, IANA is requested to assign a new value.</t>

    </section>

    <section title="Acknowledgements">
       <t>Thanks to Russ White, Acee Lindem and Shyam Sethuram for insightful review and comments.</t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.I-D.draft-ietf-idr-as4octet-extcomm-generic-subtype-08'?>
      <?rfc include="reference.RFC.1997"?>
      <?rfc include="reference.RFC.2119"?>
      <?rfc include='reference.RFC.4360'?>
      <?rfc include='reference.RFC.4893'?>
      <?rfc include='reference.RFC.5668'?>
    </references>
    <references title="Informative References">
      <?rfc include='reference.I-D.draft-ietf-idr-link-bandwidth-06'?>
      <?rfc include='reference.I-D.draft-drao-bgp-l3vpn-virtual-network-overlays-03'?>
      <?rfc include='reference.RFC.4384'?>
      <?rfc include='reference.RFC.4577'?>
      <?rfc include='reference.RFC.6514'?>
      <?rfc include='reference.RFC.6074'?>
    </references>

  </back>
</rfc>
