One document matched: draft-ietf-idr-reserved-extended-communities-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="no"?>
<?rfc tocompact="no"?>
<?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-ietf-idr-reserved-extended-communities-01"
     ipr="trust200902">
  <front>
    <title abbrev="Reserved extended communities">Assigned BGP extended
    communities</title>

    <author fullname="Bruno Decraene" initials="B.D." surname="Decraene">
      <organization>France Telecom - Orange</organization>

      <address>
        <postal>
          <street>38 rue du General Leclerc</street>

          <city>Issy Moulineaux cedex 9</city>

          <code>92794</code>

          <country>France</country>
        </postal>

        <email>bruno.decraene@orange-ftgroup.com</email>
      </address>
    </author>

    <author fullname="Pierre Francois" initials="P.F." surname="Francois">
      <organization>Universite catholique de Louvain</organization>

      <address>
        <postal>
          <street>Place Ste Barbe, 2</street>

          <city>Louvain-la-Neuve</city>

          <code>1348</code>

          <country>BE</country>
        </postal>

        <email>francois@info.ucl.ac.be</email>
      </address>
    </author>

    <date day="23" month="May" year="2011" />

    <abstract>
      <t>This document defines two IANA registries in order to assign
      transitive and non-transitive extended communities from. These are
      similar to the existing well-known BGP communities defined in RFC 1997
      but provide an easier control of inter-AS community advertisement as a
      community could be chosen as transitive or non-transitive across
      ASes.</t>

      <t>For that purpose, this document defines the use of the reserved AS
      number 0 for the transitive and non-transitive generic four-octet AS
      specific extended community types.</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">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t><xref target="RFC1997"></xref> defines the BGP community attribute
      and some BGP well-known communities whose meaning SHALL be understood by
      all compliant implementations. New communities can be registered in the
      IANA "BGP Well-known Communities" registry but it can't be assumed
      anymore that they will be known by all BGP implementations.
      Implementations or BGP policies which recognize them will behave as
      specified. Implementations which do not recognize those new reserved
      communities will propagate them from BGP neighbor to BGP neighbor and
      from AS to AS with an unlimited scope.</t>

      <t>There is currently no agreed way to register a non transitive
      well-known community:</t>

      <t>On one hand, <xref target="RFC1997"></xref> defines BGP Well-known
      communities with no structure to set their transitiveness across ASes.
      Without structure, communities can only be filtered by explicitly
      enumerating all community values that will be denied or allowed to BGP
      speakers in neighboring ASes. This is not satisfactory as this would
      require upgrading all border routers to understand this community before
      its first usage.</t>

      <t>On the other hand, <xref target="RFC4360"></xref> defines the BGP
      extended community attribute with a structure including a type and a
      transitive bit "T". This transitive bit, when set, allows to restrict
      the scope of the community within an AS. But their is no IANA registry
      to allocate one well-known extended community. <xref
      target="RFC4360"></xref> defines IANA registries to allocate BGP
      Extended Communities types. Each type is able to encode 2^48 or 2^56
      values depending on the type being extended or regular. Therefore, one
      needing to reserve a single non-transitive extended community would need
      to reserve an extended subtype which represents 2^48 communities, while
      a single value is used. This would both waste the resources and disable
      the ability to define global policies on reserved communities, such as
      to accept them or to filter them out.</t>

      <t><vspace blankLines="1" />To address this limitation, this document
      defines two IANA registries in order to allow the registration of
      transitive and non-transitive extended communities. These are similar to
      the existing Well-known BGP communities defined in <xref
      target="RFC1997"></xref> but provides a control on inter-AS community
      advertisement as a community could be chosen as transitive or
      non-transitive across ASes.</t>
    </section>

    <section title="Assigned extended communities">
      <t><xref target="I-D.ietf-idr-as4octet-extcomm-generic-subtype"></xref>
      defines a generic sub-type for the four-octet AS specific extended
      community. The value of the four-octets Global Administrator sub-field
      contains a four-octet Autonomous System number. The value of their
      two-octet Local Administrator sub-field has semantics defined by the
      Autonomous System set in the Global Administrator sub-field.</t>

      <t>This document updates <xref
      target="I-D.ietf-idr-as4octet-extcomm-generic-subtype"></xref> and
      defines the use of the Local Administrator sub-field when the AS number
      encoded in the Global Administrator sub-field has the reserved value
      0.</t>

      <t>When the AS number encoded in the Global Administrator sub-field has
      the reserved value 0, the communities have global significance. The
      lists of those communities are maintained by the IANA in the registries
      "Assigned transitive extended communities" for the "transitive generic
      four-octet AS specific" extended community type and "Assigned
      non-transitive extended communities" for the "non-transitive generic
      four-octet AS specific" extended community type.</t>

      <t>Note that this use of the reserved AS number 0 in the AS field of the
      communities is similar to the one defined by <xref
      target="RFC1997"></xref> for the BGP Well-Known communities.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t></t>

      <t>The IANA is requested to create and maintain a registry entitled
      "Assigned transitive extended communities" with the following
      registration procedure:<vspace blankLines="1" /></t>

      <figure>
        <artwork><![CDATA[ Registry Name: Assigned transitive extended communities

    Range              Registration Procedures
    -----------        -------------------------
    0x0000-8000        First Come First Served
    0x8001-FFFF        Standards Action/Early IANA Allocation]]></artwork>
      </figure>

      <t><vspace blankLines="2" />The IANA is requested to create and maintain
      a registry entitled "Assigned non-transitive extended communities" with
      the following registration procedure:</t>

      <t><vspace blankLines="1" /></t>

      <figure>
        <artwork><![CDATA[ Registry Name: Assigned non-transitive extended communities

    Range              Registration Procedures
    -----------        -------------------------
    0x0000-8000        First Come First Served
    0x8001-FFFF        Standards Action/Early IANA Allocation]]></artwork>
      </figure>

      <t><vspace blankLines="2" />An application may need both a transitive
      and a non-transitive community and it may be beneficial to have the same
      value for both communities. (Note that both extended communities will
      still be different as they will differ from their T bit). The IANA
      SHOULD try to accommodate such request to get both a transitive and
      non-transitive assigned community with the same value for both.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document defines IANA actions. In itself, it has no impact on
      the security of the BGP protocol.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.1997"?>

      <?rfc include="reference.RFC.5226"?>

      <?rfc include="reference.RFC.4360"?>

      <?rfc include="reference.I-D.ietf-idr-as4octet-extcomm-generic-subtype"?>

      <?rfc ?>
    </references>
  </back>
</rfc>