<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1997 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1997.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4271 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC4360 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4360.xml">
<!ENTITY RFC4364 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml">
<!ENTITY RFC4456 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4456.xml">
<!ENTITY RFC4684 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4684.xml">
<!ENTITY RFC5398 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5398.xml">
<!ENTITY RFC5575 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5575.xml">
<!ENTITY RFC5701 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5701.xml">
<!ENTITY RFC7432 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml">
<!ENTITY RFC8092 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8092.xml">
<!ENTITY RFC8126 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY IPV6-RT-CONSTRAIN SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-bgp-ipv6-rt-constrain.xml">
<!ENTITY WIDE-COMMUNITIES SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-wide-bgp-communities.xml">
<!ENTITY BITMASK-ROUTE-TARGET SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.zzhang-idr-bitmask-route-target.xml">
<!ENTITY TUNNEL-ENCAPS SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-tunnel-encaps.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" updates="4684" docName="draft-zzhang-idr-bgp-rt-constrains-extension-01" ipr="trust200902">
  <front>
    <title abbrev="generic-rtc">Generic Route Constraint Distribution Mechanism for BGP</title>

    <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
      <organization>Juniper Networks</organization>
      <address>
        <email>zzhang@juniper.net</email>
      </address>
    </author>

    <author fullname="Jeffrey Haas" initials="J." surname="Haas">
      <organization>Juniper Networks</organization>
      <address>
        <email>jhaas@juniper.net</email>
      </address>
    </author>

    <!--author fullname="Srihari Sangli" initials="S." surname="Sangli">
      <organization>Juniper Networks</organization>
      <address>
        <email>ssangli@juniper.net</email>
      </address>
    </author-->

    <date year="2021"/>

    <workgroup>idr</workgroup>

    <abstract>
      <t>This document defines a mechanism based upon Constrained Route
         Distribution for BGP (RFC 4684) that works with various types of
         BGP Community-like Path Attributes.  Similar to RFC 4684, this
         mechanism can be used to build a route distribution graph to limit the
         propagation of BGP Routes.  Unlike RFC 4684, this mechanism is not
         restricted to BGP Extended Communities (RFC 4360).
      </t>
    </abstract>

    <note title="Requirements Language">
    <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
       "MAY", and "OPTIONAL" in this document are to be interpreted as
       described in BCP 14 <xref target="RFC2119"/>
       <xref target="RFC8174"/> when, and only when, they appear in all
       capitals, as shown here.
    </t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
    <section title="Constrained Route Distribution">
    <t>In BGP/MPLS Layer 3 VPNs <xref target="RFC4364"/>, Route Target
       Extended Communities <xref target="RFC4360"/> are used to control
       VPN membership.  Networks providing VPN services may be large.
       In such networks, VPN routes for a given VPN may be only
       needed at a small subset of Provider Edge (PE) routers.
    </t>
    <t>The Constrained Route Distribution feature <xref target="RFC4684"/>
       assists in scaling such large VPN networks by building a distribution
       graph of VPN routes through the BGP routing infrastructure.  Much of the
       benefit of this feature comes from BGP routers, such as Route Reflectors
       <xref target="RFC4456"/>, avoiding the work of sending all VPN routes to
       a PE that may simply discard unneded routes.  Instead, the PE may
       receive only the VPN routes for VPNs located on that PE.
    </t>
    </section>

    <section title="Brief Summary of Constrained Route Distribution Procedure">
    <t>BGP Speakers implementing <xref target="RFC4684"/> advertise their
       interest in receiving VPN routes that contain specific Route Target
       Extended Communities by advertising Route Target membership NLRI.
    </t>
    <t>The format of the Route Target membership NLRI in
       <xref target="RFC4684"/> follows.  It may be of length from 0 to 96 bits.
       <figure>
          <artwork>
        +-------------------------------+
        | Origin AS        (4 octets)   |
        +-------------------------------+
        | Route Target     (8 octets)   |
        +                               +
        |                               |
        +-------------------------------+
           </artwork>
       </figure>
    </t>

    <t>The Origin AS contains the Autonomous System number of the originator of
       this NLRI.
    </t>
    <t>The Route Target contains a BGP Route Target Extended Community, or a
       prefix of a BGP Route Target Extended Community.
    </t>
    <t>Route Target membership NLRI act as a filter mechanism on VPN routes.
       The BGP Speaker receiving these Route Target membership NLRI from
       another BGP Speaker will propagate VPN routes that match these
       membership NLRI.  VPN routes that do not match these membership NLRI
       will not be propagated.
    </t>
    <t>The propagation of Route Target membership NLRI from an originating PE
       router to other interested BGP Speakers builds a distribution graph for VPN
       routes matching the desired Route Targets.
    </t>
    </section>

    <section title="Need for a Generic Route Constraint Distribution Mechanism">
    <t>Since BGP/MPLS Layer 3 VPNs were introduced, many new BGP VPN features
       have been created that leverage the original concepts in
       <xref target="RFC4364"/>.  While many of these new features similarly
       use Route Target Extended Communities for VPN membership, some use other
       Extended Communities.  That is, they utilize a different Type/Sub-Type code
       than those defined in <xref target="RFC4360"/>.
    </t>
    <t>While <xref target="RFC4684"/> is explicit about being utilized for
       Route Targets, the definition of a Route Target has become more fluid as
       VPN features have been introduced; for example, ES-Import from
       <xref target="RFC7432"/>.   It could be
       observed that that <xref target="RFC4684"/> is capable of being used on
       any type of <xref target="RFC4360"/> BGP Extended Community, for any VPN
       route type.  However, other attributes are coming to be used for
       idenitifying VPN routes and a procedure that is only applicable to
       Extended Communities cannot be used.
    </t>
    <t>
       <xref target="RFC5701"/> introduced the IPv6 Address Specific BGP
       Extended Community Attribute.  This type of BGP Community permits
       the encoding of an IPv6 address as the Global Administrator of a route.
       Similar to the <xref target="RFC4360"/> Extended Communities, the IPv6
       Address Specific type carries a Type and Sub-Type field.  One of the
       Type/Sub-Type allocations is for an IPv6 address specific Route Target.
       This permits operators to leverage IPv6 addressing when building
       their VPNs.
    </t>
    <t>IPv6 Extensions for Route Target Distribution
       <xref target="I-D.ietf-idr-bgp-ipv6-rt-constrain"/> proposes to permit
       matching for IPv6 address specific Extended Communities using
       <xref target="RFC4684"/> by overloading the NLRI length for Route Target
       membership NLRI for NLRI longer than 96 bits.  (See
       <xref target="RFC4684"/>, Section 4.)  However, this doesn't account for
       Route Target membership NLRI length shorter than 96 bits.  These shorter
       prefixes permit matching of many more specific Route Targets from a less
       specific Route Target membership BGP Route.  Therefore, a different
       mechanism is needed for safely matching IPv6 address specific Route
       Targets.
    </t>
    <t>
       The simplest change would be to utilize a new
       AFI/SAFI for IPv6 Route Target Distribution that only matches IPv6
       address specific Route Targets.  It can be further observed that
       various forms of BGP "Community" types continue to evolve to suit a
       variety of BGP route filtering needs, including those not intended for
       VPN services.  Examples of these include BGP Large Communities
       <xref target="RFC8092"/>, BGP Wide Communities
       <xref target="I-D.ietf-idr-wide-bgp-communities"/>, and Bitmask Route
       Targets <xref target="I-D.zzhang-idr-bitmask-route-target"/>.
    </t>

    <t>This document proposes a mechanism to match arbitrary BGP
       Community-like attributes, including those with Route Target-like
       semantics, for building Constrained Route Distribution graphs for BGP
       routes containing those attributes.
    </t>

    </section>
    </section>

    <section title="Community-like Attributes">
    <section title="Definition of Community-like Attributes">
    <t>BGP Communities were originally introduced in <xref target="RFC1997"/>.
       That RFC contains the definition, "A community is a group of destinations
       which share some common property."  Recall that in BGP-4
       <xref target="RFC4271"/>, a BGP Route is defined as a pairing of
       destinations (NLRI) with Path Attributes.
    </t>

    <t>In practice, a Community is implemented as an element of a BGP Path
       Attribute that is used to mark a prefix in a way that protocol and BGP
       policy mechanisms may be used to interact with that BGP Route.
    </t>

    <t>Since <xref target="RFC1997"/>, this idea of marking BGP Routes has been
       extended to other mechanisms such as BGP Extended Communities
       <xref target="RFC4360"/>, and BGP Large Communities
       <xref target="RFC8092"/>.  Other similar mechanisms are regularly
       considered for standardization.
    </t>

    <t>For purposes of this document, a Community-like Attribute (CLA) has the
       semantics of being an attribute of a BGP Path Attribute that is intended
       to interact with protocol mechanisms and may enable policy mechanisms to
       interact with that BGP Route.  Thus, classic <xref target="RFC1997"/>
       BGP Communities, BGP Extended Communities, and Large BGP Communities are
       all CLAs.
    </t>
    </section>

    <section title="Prefix Structure of BGP Community-like Attributes">
    <t><xref target="RFC4684"/> provides for matching less-specific BGP
       Extended Communities by utilizing a shorter NLRI length for the Route
       Target membership NLRI.  To highlight situations where such
       summarization is useful, consider the various forms of Route Target
       extended community from <xref target="RFC4360"/>.  In each of those
       types, the Sub-Type field is 0x02, with the Type selecting the format:
        <list style="symbols">
        <t>0x00 - 2-octet Global Administrator field, 4-octet Local
           Administrator field.</t>
        <t>0x01 - 4-octet Global Administrator field, 2-octet Local
           Administrator field.</t>
        <t>0x02 - 4-octet IPv4 Address Global Administrator field, 2-octet
           Local Administrator field.</t>
        </list>
    </t>

    <t>The Global Administrator field for Route Targets is typically an
       Autonomous System number.
    </t>

    <t>Summarization offers several useful options where the Sub-Type of the Route
       Target Extended Community is 0x02. Examples include:
       <list style="symbols">
       <t>Type = 0x00 and NLRI length = 48: Match all 2-octet Global
          Administrator fields of a given value; for example Origin AS 64511:Route
          Target 64496:*.
       </t>
       <t>Type = 0x01 and NLRI length = 64: Match all 4-octet Global
          Administrator fields of a given value; for example Origin AS 64511:Route
          Target 65551:*.
       </t>
       <t>Type = 0x03 and NLRI length = 88: Match all IPv4 Address Global
          Administrator fields of a given value; for example Origin AS 64511:Route Target
          192.0.2.*:*.
       </t>
       </list>
    </t>

    <t>Similarly, for inter-domain purposes, matching all Route Target
       Membership NLRI for a given Origin AS may be useful:
       <list style="symbols">
       <t>NLRI length = 32; for example Origin AS 64511:*.  This matches all classes
          of Extended Community originated from AS 64511.
       </t>
       <t>NLRI length = 44; for example Origin AS 64511:0x0002:*.  This matches all
          Extended Communities originated from AS 64511 that have the first two
          octets as 0x0002, which includes the class of Extended Communities that
          are 2-octet Global Administrator Route Target types.
       </t>
       </list>
    </t>

    <t>It's even possible to utilize a Prefix
       Length that splits a well defined field.  When the structure of that
       field is understood, clever operators may be able to generate summaries.
       It should be noted that understanding the intent of such summarization
       may be difficult to discern from the NLRI in question.  Some examples:

       <list style="symbols">
       <t>NLRI length = 31; for example Origin AS 6451[01]:*.  This matches all
          classes of Extended Community originated from Origin ASes 64510 and 64511.
       </t>
       <t>NLRI length = 47; for example Origin AS 64511:0x0002:*.  This matches all
          two-octet AS-Specific Extended Communities originated from AS 64511
          that include Route Targets (0x02) and Route Origins (0x03).
       </t>
       </list>
    </t>

    <t>The purpose of highlighting that a variable NLRI length can be applied in
       these ways is to demonstrate the flexibility of summarization.
       This is most true when the structure of that attribute is
       arranged most general to most specific; that is, Global to Local Admin as we
       have in Extended Communities.
    </t>

    </section>
    </section>

    <section title="Specification">
    <section title="NLRI Definition">
    <t>To support applying Constrained Route Distribution procedures to BGP
       Community-like attributes, the following NLRI is defined.  The
       "Generic Route Constraint Distribution Mechanism" NLRI uses a new SAFI
       (TBD) with the following format:
       <figure>
           <artwork>

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Origin AS (4 octets)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    CLA Selector (2 octets)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                     CLA Value (variable)                      ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           </artwork>
       </figure>
    </t>
    
    <t>It can be observed that the format of this NLRI emulates the format
       of the Route Target membership NLRI from <xref target="RFC4684"/>,
       with the addition of the CLA selector to permit the recipient to
       correctly interpret the CLA value.
    </t>
    </section>

    <section title="NLRI Length Encoding">
    <t>To support potentially large Community-like Values, the NLRI length
       field is encoded using 1 or 2 octets using the same mechanism as
       <xref target="RFC5575"/>, Section 4.  The text from that RFC is copied
       here:

       <figure>
           <artwork>
    If the NLRI length value is smaller than 240 (0xf0 hex),
    the length field can be encoded as a single octet.
    Otherwise, it is encoded as an extended-length 2-octet
    value in which the most significant nibble of the first
    byte is all ones.

    In the figure above, values less-than 240 are encoded
    using two hex digits (0xnn).  Values above 240 are encoded
    using 3 hex digits (0xfnnn).  The highest value that can
    be represented with this encoding is 4095.  The value 241
    is encoded as 0xf0f1.
           </artwork>
       </figure>
    </t>
    </section>

    <section title="Operation">
    <t>The two-octet CLA Selector identifies the type of Community-like
       attribute in a BGP route to apply the Constrained Route Distribution
       procedures to.  The value of this field, registered with IANA, may
       identify Community-like attributes that exist in a given BGP Path
       Attribute, or internal fields of structured BGP Path Attributes.
       Examples of a stand-alone BGP Path Attribute may be
       <xref target="RFC1997"/> classic BGP Communities or
       <xref target="RFC8092"/> Large BGP Communities.  Examples of internal
       community values may be Bitmask Route Targets
       <xref target="I-D.zzhang-idr-bitmask-route-target"/> defined inside a
       BGP Wide Community Container, or newly defined sub-TLVs in a BGP Tunnel
       Encapsulation Attribute <xref target="I-D.ietf-idr-tunnel-encaps"/>.
    </t>

    <t>The Community-like Attribute is encoded in the CLA Value field.
       Sufficient octets are encoded for the Prefix Length of this NLRI.
    </t>
   </section>
   </section>

   <section title="Examples">
   <section title="IPv6 Specific Extended Communities">
   <t><xref target="RFC5701"/> defines IPv6 Specific Extended Communities.  Its
      structure, from the RFC is:
      <figure>
          <artwork>
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0x00 or 0x40  |    Sub-Type   |    Global Administrator       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Global Administrator (cont.)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Global Administrator (cont.)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Global Administrator (cont.)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Global Administrator (cont.)  |    Local Administrator        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          </artwork>
      </figure>

      Where Global Administrator is 16 octets in length, and Local
      Administrator is 2 octets in length.  The community is a fixed length of
      20 octets.
   </t>

   <t>The Community Selector for Large BGP Communities is assigned 1, per this
      document.
   </t>

   <t>The encoding for a Generic Route Constraint Distribution Mechanism  NLRI
      for an IPv6 Specific Extended Community for an Origin AS of 64511, for
      the IPv6 Specific Extended Community [2001:DB8::2]:100 would be:

      <figure>
          <artwork>
NLRI length          = 0xd0 (208)
Origin AS            = 0x0000fbff (64511)
Community Selector   = 0x0001 (2)         # IPv6 Specific
                                          # Extended Community
Community-like Value = 0x0001000f (65551) # Global Administrator
                       0x2001 0DB8 0000 0000 0000 0000 0000 0000
                       0x0000 0000 0000 0000 0000 0000 0000 0002
                                          # Global Administrator
                       0x00000064 (100)   # Local Administrator
          </artwork>
      </figure>
   </t>
   </section>


   <section title="Large BGP Communities">
   <t><xref target="RFC8092"/> defines Large BGP Communities.  Its structure,
      from the RFC is:
      <figure>
          <artwork>
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Global Administrator                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local Data Part 1                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local Data Part 2                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          </artwork>
      </figure>

      Where each of the fields Global Administrator, Local Data Part 1, and
      Local Data Part 2 are 4 octets in length.  The community is a fixed
      length of 12 octets.
   </t>
   <t>The Community Selector for Large BGP Communities is assigned 2, per this
      document.
   </t>

   <t>The encoding for a Generic Route Cosntraint Mechanism NLRI for Large BGP
      Communities for an Origin AS of 64511, for Large BGP Community
      65551:100:16777215 would be:

      <figure>
          <artwork>
NLRI length          = 0x90 (144)
Origin AS            = 0x0000fbff (64511)
Community Selector   = 0x0001 (2)            # Large BGP Community
Community-like Value = 0x0001000f (65551)    # Global Administrator
                       0x00000064 (100)      # Local Data Part 1
                       0x00ffffff (16777215) # Local Data Part 2
          </artwork>
      </figure>
   </t>
   </section>

   <section title="Bitmask Route Target">
   <t><xref target="I-D.zzhang-idr-bitmask-route-target"/> defines Bitmask
      Route Targets. Bitmask Route Targets are encoded within the BGP Community
      Container Path Attribute, which is defined in
      <xref target="I-D.ietf-idr-wide-bgp-communities"/>.  The structure of the
      Bitmask Route Target, from the Internet-Draft, is:
      <figure>
          <artwork>
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  GA Type        |  GA Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Global Administrator (variable length)                       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Local Administrator                                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Bitmask Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                   Bitmask (variable length)                   ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   GA Type and GA Length are 1 octet in length.

   Local Administrator is 4 octets in length.

   The Bitmask is a number of octets that will fit the Bitmask Length.

   The following GA Types and corresponding lengths are defined:

   o  1: AS Number, 4 octets

   o  2: IPv4 Address, 4 octets

   o  3: IPv6 Address, 16 octets
          </artwork>
      </figure>
   </t>

   <t>The Community Selector for Bitmask Route Targets is assigned 3, per this
      document.
   </t>

   <t>The Bitmask Route Target, a Community-like attribute, is carried as the
      payload (that is, the value portion) of another Path Attribute. 
      The Generic Route Constraint Distribution Mechanism NLRI is not
      constructed to match any of the outer portions of the Community
      Container; rather it matches only the payload, that is, the
      Bitmask Route Target itself.
   </t>

   <section title="AS Number Bitmask Route Target">
   <t>The encoding for a Generic Route Constraint Distribution Mechanism NLRI
      for Origin AS 64511 for an AS-Number based  Bitmask Route Target for AS
      65551 with Local Administrator value 100 and a bitmask of 0xc0ffee (3
      octets) would be:

      <figure>
          <artwork>
NLRI length          = 0xa0 (160)
Origin AS            = 0x0000fbff (64511)
Community Selector   = 0x0002 (3)         # Bitmask Route Target
Community-Like Value = 0x01 (1)           # GA Type AS Number
                       0x04 (4)           # GA Length
                       0x0001000f (65551) # Global Administrator
                       0x00000064 (100)   # Local Administrator
                       0x03 (3)           # Bitmask Length
                       0xc0ffee           # Bitmask
          </artwork>
      </figure>
   </t>
   </section>

   <section title="IPv6 Address Bitmask Route Target">
   <t>The encoding for a Generic Route Constraint Distribution Mechanism NLRI
      for Origin AS 64511 for an AS-Number based  Bitmask Route Target for
      2001:DB8::2 with Local Administrator value 100 and a bitmask of 0xc0ffee
      (3 octets) would be:

      <figure>
          <artwork>
NLRI length          = 0xf108 (264)
Origin AS            = 0x0000fbff (64511)
Community Selector   = 0x0002 (2)         # Bitmask Route Target
Community-Like Value = 0x01 (1)           # GA Type IPv6 Address
                       0x04 (16)          # GA Length
                       0x2001 0DB8 0000 0000 0000 0000 0000 0000
                       0x0000 0000 0000 0000 0000 0000 0000 0002
                                          # Global Administrator
                       0x00000064 (100)   # Local Administrator
                       0x03 (3)           # Bitmask Length
                       0xc0ffee           # Bitmask
          </artwork>
      </figure>
   </t>
   </section>

   </section>


   </section>

   <!--section title="Error Handling"-->
   <!-- TODO -->
   <!-- my tiny bit of Spanish vocabulary tends to catch me on these -->
   <!-- placeholders. As in, "why does it say 'everything'?" -->
   <!--/section-->

    <section anchor="Security" title="Security Considerations">
      <t>This document does not change security aspects discussed in
         <xref target="RFC4684"/>.
      </t>
    </section>
    <section title="IANA Considerations">
    <t>This document requests IANA to assign a new SAFI, the  "Generic Route
       Constraint Distribution Mechanism" from the First Come First Served 
       "Subsequent Address Family Identifiers (SAFI) Parameters" registry.
    </t>
    <t>This documument requests IANA to create a new registry, the Generic
       Route Constraint CLA Selector Registry.  It should have the
       following initial values and registration policies assigned:
    </t>

        <texttable style="all">
        <ttcol width="20%">Value</ttcol>
        <ttcol width="20%">Description</ttcol>
        <ttcol>Defining Specification for Community-like attribute (CLA)</ttcol>
        <ttcol width="20%">Reference for this Value</ttcol>

        <c>0</c>
        <c>RESERVED</c>
        <c>-</c>
        <c>This document</c>

        <c>1</c>
        <c>IPv6 Address Specific BGP Extended Communities</c>
        <c>RFC 5701</c>
        <c>This document</c>

        <c>2</c>
        <c>Large BGP Communities</c>
        <c>RFC 8092</c>
        <c>This document</c>

        <c>3</c>
        <c>Bitmask Route Targets</c>
        <c>draft-zzhang-idr-bitmask-route-target</c>
        <c>This document</c>

        <c>4..64511</c>
        <c>Available for first come, first served allocation.</c>
        <c></c>
        <c></c>

        <c>255</c>
        <c>RESERVED</c>
        <c>-</c>
        <c>This document</c>

        </texttable>

    </section>
    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank John Scudder for his comments and
         suggestions.
      </t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;
      &RFC4271;
      &RFC4360;
      &RFC4684;
      &RFC5575;
      &RFC8174;
    </references>
    <references title="Informative References">
      &IPV6-RT-CONSTRAIN;
      &WIDE-COMMUNITIES;
      &BITMASK-ROUTE-TARGET;
      &TUNNEL-ENCAPS;
      &RFC1997;
      &RFC4364;
      &RFC4456;
      &RFC5398;
      &RFC5701;
      &RFC7432;
      &RFC8092;
      &RFC8126;
    </references>
  </back>
</rfc>
