<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5512 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5512.xml">
<!ENTITY RFC7606 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7606.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY I-D.ietf-bess-evpn-inter-subnet-forwarding SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-bess-evpn-inter-subnet-forwarding.xml">
<!--><!ENTITY I-D.ietf-intarea-tunnels SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-intarea-tunnels.xml">-->
<!ENTITY RFC2474 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml">
<!ENTITY RFC2784 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2784.xml">
<!ENTITY RFC2890 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2890.xml">
<!ENTITY RFC3032 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml">
<!ENTITY RFC3270 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3270.xml">
<!ENTITY RFC3931 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3931.xml">
<!ENTITY RFC4023 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4023.xml">
<!ENTITY RFC4364 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml">
<!ENTITY RFC5129 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5129.xml">
<!ENTITY RFC5462 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5462.xml">
<!ENTITY RFC5565 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5565.xml">
<!ENTITY RFC5566 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5566.xml">
<!ENTITY RFC5640 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5640.xml">
<!ENTITY RFC6514 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6514.xml">
<!ENTITY RFC6811 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6811.xml">
<!ENTITY RFC6890 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6890.xml">
<!ENTITY RFC7348 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7348.xml">
<!ENTITY RFC7510 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7510.xml">
<!ENTITY RFC7637 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7637.xml">
<!ENTITY RFC8205 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8205.xml">
<!ENTITY RFC8277 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8277.xml">
<!ENTITY RFC8669 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8669.xml">
<!ENTITY RFC4271 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC4272 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4272.xml">
<!ENTITY RFC4760 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4760.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml">
<!ENTITY RFC8365 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8365.xml">
<!ENTITY RFC8402 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml">
]> "rfc2629-xhtml.ent">

<rfc submissionType="IETF" xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-idr-tunnel-encaps-22" number="9012" submissionType="IETF" category="std" consensus="true" obsoletes="5512, 5566"
     updates="5640"> updates="5640" xml:lang="en" sortRefs="true" symRefs="true" tocInclude="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <!-- Generated by id2xml 1.4.4 on 2019-02-22T16:45:17Z -->
	<?rfc compact="yes"?>
	<?rfc text-list-symbols="o*+-"?>
	<?rfc subcompact="no"?>
	<?rfc sortrefs="yes"?>
	<?rfc symrefs="yes"?>
	<?rfc strict="yes"?>
	<?rfc toc="yes"?>

	<front>
    <title abbrev="Tunnel Encapsulation Attribute">The BGP Tunnel Encapsulation Attribute</title>
    <seriesInfo name="RFC" value="9012"/>
    <author fullname="Keyur Patel" initials="K." surname="Patel">
      <organization>Arrcus, Inc</organization>
      <address>
	<postal><street>2077
        <postal>
          <street>2077 Gateway Pl</street>
	<street>San Jose, CA 95110</street>
	<street>United States</street>
          <city>San Jose</city>
	  <region>CA</region>
	  <code>95110</code>
          <country>United States of America</country>
        </postal>
        <email>keyur@arrcus.com</email>
      </address>
    </author>
    <author fullname="Gunter Van de Velde" initials="G." surname="Van de Velde">
      <organization>Nokia</organization>
	<address><postal><street>Copernicuslaan
      <address>
        <postal>
          <street>Copernicuslaan 50</street>
	<street>Antwerpen 2018</street>
	<street>Belgium</street>
          <city>Antwerpen</city>
	  <code>2018</code>
          <country>Belgium</country>
        </postal>
        <email>gunter.van_de_velde@nokia.com</email>
      </address>
    </author>
    <author fullname="Srihari R. Sangli" initials="S." surname="Sangli">
      <organization>Juniper Networks</organization>
      <address>
        <email>ssangli@juniper.net</email>
      </address>
    </author>
    <author fullname="John Scudder" initials="J." surname="Scudder">
      <organization>Juniper Networks</organization>
      <address>
        <email>jgs@juniper.net</email>
      </address>
    </author>

	<date/>
	<workgroup>IDR Working Group</workgroup>
	<abstract><t>
    <date year="2021" month="April" />

    <keyword>BGP</keyword>

    <abstract>
      <t>
	This document defines a BGP Path Attribute path attribute known as the
	"Tunnel Encapsulation Attribute", attribute", which can be used with
	BGP UPDATEs of various SAFIs Subsequent Address Family Identifiers (SAFIs) to provide information needed
	to create tunnels and their corresponding encapsulation
	headers. It provides encodings for a number of Tunnel Types tunnel types,
	along with procedures for choosing between alternate tunnels
	and routing packets into tunnels.</t>
      <t>This document obsoletes RFC 5512, which provided an earlier
	definition of the Tunnel Encapsulation Attribute. attribute. RFC 5512 was never
	deployed in production. Since RFC 5566 relies on RFC 5512, it is
	likewise obsoleted. This document updates RFC 5640 by indicating
	that the Load-Balancing Block sub-TLV may be included in any Tunnel
	Encapsulation Attribute attribute where load balancing is desired.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"><t> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   This document obsoletes RFC 5512. <xref target="RFC5512"/>.  The deficiencies of RFC 5512, <xref target="RFC5512"/>, and
   a summary of the changes made, are discussed in Sections 1.1-1.3. <xref target="summary" format="counter"/>-<xref target="use-case" format="counter"/>.
   The material from RFC 5512 <xref target="RFC5512"/> that is retained has been incorporated
   into this document.  Since <xref target="RFC5566"/>
   relies on RFC 5512, <xref target="RFC5512"/>, it is likewise obsoleted.</t>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
   "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP
   14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>

      <section title="Brief numbered="true" toc="default" anchor="summary">
        <name>Brief Summary of RFC 5512"><t> 5512</name>
        <t>
   <xref target="RFC5512"/> target="RFC5512" format="default"/> defines a BGP Path Attribute path attribute known as the Tunnel
   Encapsulation attribute.  This attribute consists of one or more
   TLVs.  Each TLV identifies a particular type of tunnel.  Each TLV
   also contains one or more sub-TLVs.  Some of the sub-TLVs, for example, the
   "Encapsulation sub-TLV",
   Encapsulation sub-TLV, contain information that may be used to form
   the encapsulation header for the specified Tunnel Type. tunnel type.  Other sub-
   TLVs, sub-TLVs, for example, the "color sub-TLV" and the "protocol sub-TLV", contain
   information that aids in determining whether particular packets
   should be sent through the tunnel that the TLV identifies.</t>
        <t>
   <xref target="RFC5512"/> target="RFC5512" format="default"/> only allows the Tunnel Encapsulation attribute to be
   attached to BGP UPDATE messages of the Encapsulation Address Family.
   These UPDATE messages have an AFI (Address Address Family Identifier) Identifier (AFI) of 1 or
   2, and a SAFI of 7.  In an UPDATE of the Encapsulation SAFI, the NLRI
   (Network
   Network Layer Reachability Information) Information (NLRI) is an address of the BGP
   speaker originating the UPDATE.  Consider the following scenario:</t>

	<t><list style="symbols"><t>BGP
        <ul spacing="normal">
          <li>BGP speaker R1 has received and selected UPDATE U for local use;</t>

	<t>UPDATE use;</li>
          <li>UPDATE U's SAFI is the Encapsulation SAFI;</t>

	<t>UPDATE SAFI;</li>
          <li>UPDATE U has the address R2 as its NLRI;</t>

	<t>UPDATE NLRI;</li>
          <li>UPDATE U has a Tunnel Encapsulation attribute.</t>

	<t>R1 attribute.</li>
          <li>R1 has a packet, P, to transmit to destination D;</t>

	<t>R1's D; and</li>
          <li>R1's best route to D is a BGP route that has R2 as its next hop;</t>

	</list>
	</t> hop.</li>
        </ul>
        <t>
   In this scenario, when R1 transmits packet P, it should transmit it
   to R2 through one of the tunnels specified in U's Tunnel
   Encapsulation attribute.  The IP address of the tunnel egress endpoint of
   each such tunnel is R2.  Packet P is known as the tunnel's "payload".</t>
      </section>
      <section title="Deficiencies anchor="deficiencies" numbered="true" toc="default">
        <name>Deficiencies in RFC 5512" anchor="deficiencies"><t> 5512</name>
        <t>
   While the ability to specify tunnel information in a BGP UPDATE is
   useful, the procedures of <xref target="RFC5512"/> target="RFC5512" format="default"/> have certain limitations:</t>

	<t><list style="symbols"><t>The
        <ul spacing="normal">
          <li>The requirement to use the "Encapsulation SAFI" Encapsulation SAFI presents an
      unfortunate operational cost, as each BGP session that may need to
      carry tunnel encapsulation information needs to be reconfigured to
      support the Encapsulation SAFI.  The Encapsulation SAFI has never
      been used, and this requirement has served only to discourage the
      use of the Tunnel Encapsulation attribute.</t>

	<t>There attribute.</li>
          <li>There is no way to use the Tunnel Encapsulation attribute to
      specify the tunnel egress endpoint address of a given tunnel; <xref target="RFC5512"/> target="RFC5512" format="default"/>
      assumes that the tunnel egress endpoint of each tunnel is specified as
      the NLRI of an UPDATE of the Encapsulation SAFI.</t>

	<t>If SAFI.</li>
          <li>If the respective best routes to two different address prefixes
      have the same next hop, <xref target="RFC5512"/> target="RFC5512" format="default"/> does not provide a
      straightforward method to associate each prefix with a different
      tunnel.</t>

	<t>If
      tunnel.</li>
          <li>If a particular Tunnel Type tunnel type requires an outer IP or UDP
      encapsulation, there is no way to signal the values of any of the
      fields of the outer encapsulation.</t>

	<t>In <xref target="RFC5512"/>'s encapsulation.</li>
          <li>In the specification of the sub-TLVs, sub-TLVs in <xref target="RFC5512" format="default"/>, each sub-TLV has a
      one-octet length Length field.  In some cases, where a sub-TLV may require more than
      255 octets for its encoding, a two-octet length Length field
      may be needed.</t>

	</list>
	</t> needed.</li>
        </ul>
      </section>
      <section title="Use numbered="true" toc="default" anchor="use-case">
        <name>Use Case for The the Tunnel Encapsulation Attribute"><t> Attribute</name>
        <t>
	    Consider the case of a router R1 forwarding an IP packet P.  Let D be
	    P's IP destination address.  R1 must look up D in its forwarding
	    table.  Suppose that the "best match" route for D is route Q, where Q
	    is a BGP-distributed route whose "BGP next hop" is router R2.  And
	    suppose further that the routers along the path from R1 to R2 have
	    entries for R2 in their forwarding tables, tables but do NOT have entries
	    for D in their forwarding tables.  For example, the path from R1 to
	    R2 may be part of a "BGP-free core", where there are no BGP-
	    distributed BGP-distributed routes at all in the core.  Or, as in <xref target="RFC5565"/>, target="RFC5565" format="default"/>, D may be an
	    IPv4 address while the intermediate routers along the path from R1 to
	    R2 may support only IPv6.
        </t>
        <t>
	    In cases such as this, in order for R1 to properly forward packet P,
	    it must encapsulate P and send P "through a tunnel" to R2.  For
	    example, R1 may encapsulate P using GRE, L2TPv3, Layer 2 Tunneling
   Protocol version 3 (L2TPv3), IP in IP, etc.,
	    where the destination IP address of the encapsulation header is the
	    address of R2.
        </t>
        <t>
	    In order for R1 to encapsulate P for transport to R2, R1 must know
	    what encapsulation protocol to use for transporting different sorts
	    of packets to R2.  R1 must also know how to fill in the various
	    fields of the encapsulation header.  With certain encapsulation
	    types, this knowledge may be acquired by default or through manual
	    configuration.  Other encapsulation protocols have fields such as
	    session id, key, or cookie that must be filled in.  It would not be
	    desirable to require every BGP speaker to be manually configured with
	    the encapsulation information for every one of its BGP next hops.
        </t>
        <t>
	    This document specifies a way in which BGP itself can be used by
	    a given BGP speaker to tell other BGP speakers, "if "If you need to
	    encapsulate packets to be sent to me, here's the information you need
	    to properly form the encapsulation header".  A BGP speaker signals
	    this information to other BGP speakers by using a new BGP attribute type
	    value,
	    value -- the BGP Tunnel Encapsulation Attribute. attribute.  This attribute
	  specifies the encapsulation protocols that may be used used, as well as
	  whatever additional information (if any) is needed in order to
	  properly use those protocols.  Other attributes, for example, communities or
	  extended communities, may also be included.
        </t>
      </section>
      <section title="Brief numbered="true" toc="default">
        <name>Brief Summary of Changes from RFC 5512"><t> 5512</name>
        <t>
   This document addresses the deficiencies identified in <xref
   target="deficiencies"/> target="deficiencies" format="default"/> by:</t>

	<t><list style="symbols"><t>Deprecating
        <ul spacing="normal">
          <li>Deprecating the Encapsulation SAFI.</t>

	<t>Defining SAFI.</li>
          <li>Defining a new "Tunnel Egress Endpoint sub-TLV" (<xref
	  target="tunnel-egress-endpoint"/>) target="tunnel-egress-endpoint" format="default"/>) that can be
      included in any of the TLVs contained in the Tunnel Encapsulation
      attribute.  This sub-TLV can be used to specify the remote
      endpoint address of a particular tunnel.</t>

	<t>Allowing tunnel.</li>
          <li>Allowing the Tunnel Encapsulation attribute to be carried by BGP
      UPDATEs of additional AFI/SAFIs.  Appropriate semantics are
      provided for this way of using the attribute.</t>

	<t>Defining attribute.</li>
          <li>Defining a number of new sub-TLVs that provide additional
      information that is useful when forming the encapsulation header
      used to send a packet through a particular tunnel.</t>

	<t>Defining tunnel.</li>
          <li>Defining the sub-TLV type Sub-TLV Type field so that a sub-TLV whose type is in
      the range from 0 to 127 inclusive (inclusive) has a one-octet length Length field,
      but a sub-TLV whose type is in the range from 128 to 255 inclusive (inclusive)
      has a two-octet length field.</t>

	</list>
	</t> Length field.</li>
        </ul>
        <t>
   One of the sub-TLVs defined in <xref target="RFC5512"/> target="RFC5512" format="default"/> is the "Encapsulation sub-TLV".  For a given tunnel, the Encapsulation sub-TLV specifies some
   of the information needed to construct the encapsulation header used
   when sending packets through that tunnel.  This document defines
   Encapsulation sub-TLVs for a number of tunnel types not discussed in
   <xref target="RFC5512"/>: VXLAN (Virtual Extensible target="RFC5512" format="default"/>: Virtual eXtensible Local Area Network, Network (VXLAN) <xref target="RFC7348"/>),
   NVGRE
   (Network target="RFC7348" format="default"/>, Network Virtualization Using Generic Routing Encapsulation (NVGRE)
   <xref target="RFC7637"/>), target="RFC7637" format="default"/>, and MPLS-in-GRE (MPLS MPLS in Generic Routing Encapsulation (MPLS-in-GRE) <xref target="RFC4023"/>). target="RFC4023" format="default"/>.  MPLS-in-UDP <xref target="RFC7510"/> target="RFC7510" format="default"/> is also
   supported, but an Encapsulation sub-TLV for it is not needed since there are
   no additional parameters to be signaled.</t>
        <t>
   Some of the encapsulations mentioned in the previous paragraph need
   to be further encapsulated inside UDP and/or IP.  <xref target="RFC5512"/> target="RFC5512" format="default"/> provides
   no way to specify that certain information is to appear in these
   outer IP and/or UDP encapsulations.  This document provides a
   framework for including such information in the TLVs of the Tunnel
   Encapsulation attribute.</t>
        <t>
   When the Tunnel Encapsulation attribute is attached to a BGP UPDATE
   whose AFI/SAFI identifies one of the labeled address families, it is
   not always obvious whether the label embedded in the NLRI is to
   appear somewhere in the tunnel encapsulation header (and if so,
   where), or whether it is to appear in the payload, or whether it can
   be omitted altogether.  This is especially true if the tunnel
   encapsulation header itself contains a "virtual network identifier".
   This document provides a mechanism that allows one to signal (by
   using sub-TLVs of the Tunnel Encapsulation attribute) how one wants
   to use the embedded label when the tunnel encapsulation has its own
   virtual network identifier
   Virtual Network Identifier field.</t>
        <t>

    <xref target="RFC5512"/> target="RFC5512" format="default"/> defines a Tunnel an Encapsulation Extended
    Community that can be used instead of the Tunnel Encapsulation
    attribute under certain circumstances.  This document describes
    (<xref target="encapsulation-extcomm"/>)
     how the Tunnel Encapsulation Extended
    Community can be used in a backwards-compatible fashion. fashion (see <xref target="encapsulation-extcomm" format="default"/>). It is
    possible to combine Tunnel Encapsulation Extended Communities and
    Tunnel Encapsulation attributes in the same BGP UPDATE in this
    manner.</t>
      </section>
      <section title="Update numbered="true" toc="default">
        <name>Update to RFC 5640"> 5640</name>
        <t>
	This document updates <xref target="RFC5640"/> target="RFC5640" format="default"/> by indicating that the Load-Balancing Block
 	sub-TLV MAY <bcp14>MAY</bcp14> be included in any Tunnel Encapsulation Attribute attribute where
  	loadbalancing
  	load balancing is desired.
        </t>
      </section>
      <section title="Effects numbered="true" toc="default">
        <name>Effects of Obsoleting RFC 5566"> 5566</name>
        <t>
	This specification obsoletes RFC 5566. This has the effect of,
	in turn, obsoleting deprecating a number of code points defined in that document.
	From
	In the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry, registry <xref target="IANA-BGP-TUNNEL-ENCAP"/>, the following code points have been marked as deprecated:
	"Transmit tunnel endpoint" (type code 3), "IPsec in Tunnel-mode" (type
	code 4), "IP in IP tunnel with IPsec Transport Mode" (type code 5), and
	"MPLS-in-IP tunnel with IPsec Transport Mode" (type code 6) are obsoleted.
	From 6).
	In the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, registry <xref target="IANA-BGP-TUNNEL-ENCAP"/>,
	"IPsec Tunnel Authenticator" (type code 3) is obsoleted. has been marked as deprecated.
	See <xref target="obsoleting-5566-and-5640"/>. target="obsoleting-5566-and-5640" format="default"/>.
        </t>
      </section>
    </section>
    <section title="The anchor="encaps-attr" numbered="true" toc="default">
      <name>The Tunnel Encapsulation Attribute" anchor="encaps-attr"><t> Attribute</name>
      <t>
   The Tunnel Encapsulation attribute is an optional transitive BGP Path path

   attribute.  IANA has assigned the value 23 as the type code of the
   attribute.
   attribute in the "BGP Path Attributes" registry <xref target="IANA-BGP-PARAMS" />.  The attribute is composed of a set of Type-Length-Value
   (TLV) encodings.  Each TLV contains information corresponding to a
   particular Tunnel Type. tunnel type.  A Tunnel Encapsulation TLV, also known as Tunnel TLV,
   is structured as shown in Figure 1:</t> <xref target="ref-tunnel-tlv-value-field"/>.
 </t>
      <figure title="Tunnel anchor="ref-tunnel-tlv-value-field">
        <name>Tunnel Encapsulation TLV Value Field" anchor="ref-tunnel-tlv-value-field"><artwork><![CDATA[ TLV</name>
        <artwork name="" type="" align="left" alt=""><![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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Tunnel Type (2 Octets) octets)     |        Length (2 Octets) octets)      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  |                        Value (Variable) (variable)                       |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
	<t><list style="symbols"><t>Tunnel

      <dl>
        <dt>Tunnel Type (2 octets): identifies octets):</dt><dd>Identifies a type of tunnel.  The field
      contains values from the IANA Registry registry
"BGP Tunnel Encapsulation Attribute Tunnel Types". Types" <xref target="IANA-BGP-TUNNEL-ENCAP" />.
      See <xref target="protocol-type"/> target="protocol-type" format="default"/> for discussion of special treatment of tunnel types with names of the form "X-in-Y".
	</t>

	<t>Length "X-in-Y".</dd>
        <dt>Length (2 octets): the octets):</dt><dd>The total number of octets of the Value field.</t>

	<t>Value (variable): comprised field.</dd>
        <dt>Value (variable):</dt><dd>Comprised of multiple sub-TLVs.</t>

	</list>
	</t> sub-TLVs.</dd>
      </dl>
      <t>
   Each sub-TLV consists of three fields: a A 1-octet type, a 1-octet or
   2-octet length field (depending on the type), and zero or more octets
   of value.  A sub-TLV is structured as shown in Figure 2: <xref target="ref-tunnel-encapsulation-sub-tlv-value-field"/>.
      </t>
      <figure title="Encapsulation Sub-TLV Value Field" anchor="ref-tunnel-encapsulation-sub-tlv-value-field"><artwork><![CDATA[ anchor="ref-tunnel-encapsulation-sub-tlv-value-field">
        <name>Encapsulation Sub-TLV</name>

        <artwork name="" type="" align="left" alt=""><![CDATA[
                    +--------------------------------+
                    | Sub-TLV Type (1 Octet) octet)         |
                    +--------------------------------+
                    | Sub-TLV Length (1 or 2 Octets) octets) |
                    +--------------------------------+
                    | Sub-TLV Value (Variable) (variable)       |
                    +--------------------------------+
]]></artwork>
      </figure>

</t>
	<t><list style="symbols"><t>Sub-TLV
      <dl>
        <dt>Sub-TLV Type (1 octet): each octet):</dt><dd>Each sub-TLV type defines a certain
      property about the Tunnel TLV that contains this sub-TLV.
      The field contains values from the IANA Registry registry
"BGP Tunnel Encapsulation Attribute Sub-TLVs".</t>

	<t>Sub-TLV Sub-TLVs" <xref target="IANA-BGP-TUNNEL-ENCAP" />.</dd>
      <dt>Sub-TLV Length (1 or 2 octets): the octets):</dt><dd>The total number of octets of the
      sub-TLV
      Sub-TLV Value field.  The Sub-TLV Length field contains 1 octet if
      the Sub-TLV Type field contains a value in the range from 0-127.
      The Sub-TLV Length field contains two octets if the Sub-TLV Type
      field contains a value in the range from 128-255.</t>

	<t>Sub-TLV 128-255.</dd>
      <dt>Sub-TLV Value (variable): encodings (variable):</dt><dd>Encodings of the Value field depend on
      the sub-TLV type as enumerated above. type.  The following sub-sections subsections
      define the encoding in detail.</t>

	</list>
	</t> detail.</dd>
      </dl>
    </section>
    <section title="Tunnel numbered="true" toc="default">
      <name>Tunnel Encapsulation Attribute Sub-TLVs"><t> Sub-TLVs</name>
      <t>
	This section specifies a number of sub-TLVs.  These sub-TLVs can
      be included in a TLV of the Tunnel Encapsulation attribute.</t>
      <section title="The anchor="tunnel-egress-endpoint" numbered="true" toc="default">
        <name>The Tunnel Egress Endpoint Sub-TLV (type code 6)"
	 anchor="tunnel-egress-endpoint"><t> (Type Code 6)</name>
        <t>
   The Tunnel Egress Endpoint
   sub-TLV specifies the address of the egress endpoint of the tunnel, that
   is, the address of the router that will decapsulate the payload. Its
   Value field contains three subfields:</t>

	<t><list style="numbers"><t>a reserved subfield</t>

	<t>a
        <ol spacing="normal" type="1"><li>a Reserved subfield</li>
          <li>a two-octet Address Family subfield</t>

	<t>an subfield</li>
          <li>an Address subfield, whose length depends upon the Address
       Family.</t>

	</list>
	</t>
       Family.</li>
        </ol>
        <figure title="Tunnel anchor="ref-tunnel-endpoint-sub-tlv-value-field">
          <name>Tunnel Egress Endpoint Sub-TLV Value Field" anchor="ref-tunnel-endpoint-sub-tlv-value-field"><artwork><![CDATA[ Field</name>
          <artwork name="" type="" align="left" alt=""><![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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       Reserved (4 octets)                     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Address Family (2 octets)   |           Address             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          (Variable)          (variable)           +
  ~                                                               ~
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>
   The Reserved subfield SHOULD <bcp14>SHOULD</bcp14> be originated as zero. It MUST <bcp14>MUST</bcp14> be
   disregarded on receipt, and it MUST <bcp14>MUST</bcp14> be propagated unchanged.
        </t>
        <t>
   The Address Family subfield contains a value from IANA's
"Address Family Numbers" registry. registry <xref target="IANA-ADDRESS-FAM" />.
   This document assumes that the
   Address Family is either IPv4 or IPv6; use of other address families
   is outside the scope of this document.</t>
        <t>
   If the Address Family subfield contains the value for IPv4, the
   Address subfield MUST <bcp14>MUST</bcp14> contain an IPv4 address (a /32 IPv4 prefix).</t>
        <t>
   If the Address Family subfield contains the value for IPv6, the
   Address subfield MUST <bcp14>MUST</bcp14> contain an IPv6 address (a /128 IPv6 prefix).</t>
        <t>
   In a given BGP UPDATE, the address family (IPv4 or IPv6) of a Tunnel
   Egress Endpoint sub-TLV is independent of the address family of the UPDATE
   itself. For example, an UPDATE whose NLRI is an IPv4 address may
   have a Tunnel Encapsulation attribute containing Tunnel Egress Endpoint
   sub-TLVs that contain IPv6 addresses.  Also, different tunnels
   represented in the Tunnel Encapsulation attribute may have tunnel egress
   endpoints of different address families.</t>
        <t>
	  There is one special case: the Tunnel Egress Endpoint sub-TLV MAY <bcp14>MAY</bcp14> have a
	  Value field whose Address Family subfield contains 0.  This means
	  that the tunnel's egress endpoint is the address of the next hop.  If
	  the Address Family subfield contains 0, the Address subfield is
	  omitted. In this case,
	  the Length field of Tunnel Egress Endpoint sub-TLV MUST <bcp14>MUST</bcp14> contain the
	  value 6 (0x06). </t>

        <t>
          When the Tunnel Encapsulation attribute is carried in an UPDATE message
          of one of the AFI/SAFIs specified in this document (see the second first
          paragraph of <xref target="usage"/>), target="usage" format="default"/>), each TLV MUST <bcp14>MUST</bcp14> have one, and one only, only one, Tunnel Egress Endpoint sub-TLV. If a TLV does not have a Tunnel Egress Endpoint sub-TLV, that TLV should be treated as if it had a malformed Tunnel
          Egress Endpoint sub-TLV (see below).</t>
        <t>

   In the context of this specification, if the Address Family subfield
   has any value other than IPv4, IPv6, or the special value 0, the
   Tunnel Egress Endpoint sub-TLV is considered "unrecognized" (see
   <xref target="validation-and-error"/>). target="validation-and-error" format="default"/>).

   If any of the following conditions hold, the Tunnel Egress Endpoint sub-TLV
   is considered to be "malformed":</t>

	<t><list style="symbols">
        <ul spacing="normal">
          <li>
            <t>The length of the sub-TLV's Value field is other than 6 added to
	  the defined length for the address family given in its Address
	  Family subfield. Therefore, for address family behaviors defined
	  in this document, the permitted values are:

	  <list style="symbols">
	  <t>10,

            </t>
            <ul spacing="normal">
              <li>10, if the Address Family subfield contains the value for IPv4.</t>
	  <t>22, IPv4.</li>
              <li>22, if the Address Family subfield contains the value for IPv6.</t>
	  <t>6, IPv6.</li>
              <li>6, if the Address Family subfield contains the value zero.</t>
	  </list></t>

	<t>The zero.</li>
            </ul>
          </li>
          <li>The IP address in the sub-TLV's Address subfield lies within a
	  block listed in the relevant Special-Purpose IP Address Registry registry
	  <xref target="RFC6890"/> target="RFC6890" format="default"/> with either a “destination” "destination" attribute
	  value or a “forwardable” "forwardable" attribute value of “false”. "false". (Such routes
	  are sometimes colloquially known as "Martians".) This restriction
	  MAY
	  <bcp14>MAY</bcp14> be relaxed by explicit configuration.</t>

    <t>It configuration.</li>
          <li>It can be determined that the IP address in the sub-TLV's Address
      subfield does not belong to the Autonomous System (AS) that originated
      the route that contains the attribute.  <xref target="address-validation"/> target="address-validation" format="default"/>
      describes an optional procedure to make this determination.</t>
	</list>
	</t> determination.</li>
        </ul>
        <t>
   Error Handling handling is specified in <xref target="validation-and-error"/>. target="validation-and-error" format="default"/>.
        </t>
        <t>
   If the Tunnel Egress Endpoint sub-TLV contains an IPv4 or IPv6 address that
   is valid but not reachable, the sub-TLV is not considered to be
   malformed.</t>
        <section title="Validating anchor="address-validation" numbered="true" toc="default">
          <name>Validating the Address Subfield" anchor="address-validation"> Subfield</name>
          <t>
   This section provides a procedure that MAY <bcp14>MAY</bcp14> be applied to
   validate that the IP address in the sub-TLV's Address subfield
   belongs to the AS that originated the route that contains the
   attribute. (The notion of "belonging to" an AS is expanded on below.)
   Doing this is thought to increase confidence that when
   traffic is sent to the IP address depicted in the
   Address subfield, it will go to the same AS as it would go to if the
   Tunnel Encapsulation Attribute attribute were not present, although of course
   it cannot guarantee it. See <xref
   target="security"/> target="security" format="default"/> for discussion of the limitations of this
   procedure. The principal applicability of this procedure is in deployments
   that are not strictly scoped. In deployments with strict scope, and especially
   those scoped to a single AS, these procedures may not add substantial
   benefit beyond those discussed in <xref target="scoping"/>. target="scoping" format="default"/>.
          </t>
          <t>
   The Route Origin ASN (Autonomous Autonomous System Number) Number (ASN) of a BGP route that
   includes a Tunnel Encapsulation Attribute attribute can be determined by
   inspection of the AS_PATH attribute, according to the procedure
   specified in <xref target="RFC6811"/> Section 2. target="RFC6811" sectionFormat="comma" section="2"/>. Call this value
   Route_AS.
          </t>
          <t>
   In order to determine the Route Origin ASN of the address depicted in
   the Address subfield of the Tunnel Egress Endpoint sub-TLV, it is
   necessary to consider the forwarding route, route -- that is, the route that
   will be used to forward traffic toward that address. This route is
   determined by a recursive route lookup route-lookup operation for that address, as
   discussed in <xref target="RFC4271"/> Section 5.1.3. target="RFC4271" sectionFormat="comma" section="5.1.3"/>. The relevant AS
   Path
   path to consider is the last one encountered while performing the
   recursive lookup; the procedures of RFC6811 Section 2 <xref target="RFC6811" sectionFormat="comma" section="2"/> are applied to
   that AS Path path to determine the Route Origin ASN. If no AS Path path is
   encountered at all, for example example, if that route's source is a protocol
   other than BGP, the Route Origin ASN is the BGP speaker's own AS
   number. Call this value Egress_AS.
          </t>
          <t>
   If Route_AS does not equal Egress_AS, then the Tunnel Egress Endpoint
   sub-TLV is considered not to be valid. In some cases cases, a network operator
   who controls a set of Autonomous Systems ASes might wish to allow a Tunnel
   Egress Endpoint tunnel
   egress endpoint to reside in an AS other than Route_AS; configuration
   MAY
   <bcp14>MAY</bcp14> allow for such a case, in which case the check becomes, becomes: if
   Egress_AS is not within the configured set of permitted AS numbers, then the
   Tunnel Egress Endpoint sub-TLV is considered to be "malformed".
          </t>
          <t>
   Note that if the forwarding route changes, this procedure MUST <bcp14>MUST</bcp14> be
   reapplied. As a result, a sub-TLV that was formerly considered valid
   might become not valid, or vice-versa. vice versa.
          </t>
        </section>
      </section>
      <section title="Encapsulation numbered="true" toc="default">
        <name>Encapsulation Sub-TLVs for Particular Tunnel Types (type code 1)"><t> (Type Code 1)</name>
        <t>
   This section defines Encapsulation sub-TLVs for the following
   tunnel types: VXLAN (<xref target="RFC7348"/>), <xref target="RFC7348" format="default"/>, NVGRE
   (<xref target="RFC7637"/>),
   <xref target="RFC7637" format="default"/>, MPLS-in-GRE (<xref target="RFC4023"/>), <xref target="RFC4023" format="default"/>, L2TPv3
   (<xref target="RFC3931"/>),
   <xref target="RFC3931" format="default"/>, and GRE (<xref target="RFC2784"/>).</t> <xref target="RFC2784" format="default"/>.</t>
        <t>
   Rules for forming the encapsulation based on the information in a
   given TLV are given in Sections <xref target="usage"/> target="usage" format="counter"/> and <xref target="use-of-vni"/>.</t> target="use-of-vni" format="counter"/>.</t>
        <t>
   Recall that the tunnel type itself is identified by the Tunnel Type
   field in the attribute header (<xref target="encaps-attr"/>); target="encaps-attr" format="default"/>); the
   Encapsulation sub-TLV's structure is inferred from this. Regardless
   of the Tunnel Type, tunnel type, the sub-TLV type of the Encapsulation sub-TLV is
   1. There are also tunnel types for which it is not necessary to
   define an Encapsulation sub-TLV, because there are no fields in the
   encapsulation header whose values need to be signaled from the tunnel
   egress endpoint.</t>
        <section title="VXLAN (tunnel type 8)"><t> numbered="true" toc="default">
          <name>VXLAN (Tunnel Type 8)</name>
          <t>
   This document defines an Encapsulation sub-TLV for <xref target="RFC7348">VXLAN</xref> target="RFC7348" format="default">VXLAN</xref> tunnels.
   When the Tunnel Type tunnel type is VXLAN, the length of the sub-TLV is 12 octets. The
   following is the structure of the Value field in the Encapsulation sub-TLV:</t> sub-TLV is shown in <xref target="ref-vxlan-encapsulation-sub-tlv" />.</t>
          <figure title="VXLAN anchor="ref-vxlan-encapsulation-sub-tlv">
            <name>VXLAN Encapsulation Sub-TLV Value Field" anchor="ref-vxlan-encapsulation-sub-tlv"><artwork><![CDATA[ Field</name>
            <artwork name="" type="" align="left" alt=""><![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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |V|M|R|R|R|R|R|R|          VN-ID (3 Octets) octets)                     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 MAC Address (4 Octets) octets)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  MAC Address (2 Octets) octets)       |      Reserved (2 Octets) octets)      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
	<t><list hangIndent="3" style="hanging"><t>
      V:
          <dl newline="false" spacing="normal" indent="3">
            <dt>V:</dt>
            <dd>
      This bit is set to 1 to indicate that a VN-ID (Virtual Virtual
      Network Identifier) Identifier (VN-ID) is present in the Encapsulation sub-TLV.
      If set to 0, the VN-ID field is disregarded.
      Please see <xref target="use-of-vni"/>.</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t>
      M: target="use-of-vni" format="default"/>.</dd>
            <dt>M:</dt>
            <dd>
      This bit is set to 1 to indicate that a MAC Media Access Control (MAC) Address is
      present in the Encapsulation sub-TLV. If set to 0, the MAC
      Address field is disregarded.</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t>
      R: disregarded.</dd>
            <dt>R:</dt>
            <dd>
      The remaining bits in the 8-bit flags Flags field are reserved for
      further use.  They MUST <bcp14>MUST</bcp14> always be set to 0 by the originator of
      the sub-TLV. Intermediate routers MUST <bcp14>MUST</bcp14> propagate them without
      modification. Any receiving routers MUST <bcp14>MUST</bcp14> ignore
      these bits upon receipt.</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t>
      VN-ID: receipt.</dd>

            <dt>VN-ID:</dt>
            <dd>
      If the V bit is set, set to 1, the VN-ID field contains a 3 octet VN-
      ID 3-octet VN-ID value.  If the V bit is not set, set to 0, the VN-ID field MUST <bcp14>MUST</bcp14> be set
      to zero on transmission and disregarded on receipt.</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t>
      MAC Address: receipt.</dd>
            <dt>MAC Address:</dt>
            <dd>
      If the M bit is set, set to 1, this field contains a 6 octet 6-octet
      Ethernet MAC address.  If the M bit is not set, set to 0, this field MUST <bcp14>MUST</bcp14>
      be set to all zeroes on transmission and disregarded on receipt.</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t>
      Reserved: MUST receipt.</dd>
            <dt>Reserved:</dt>
            <dd>
      <bcp14>MUST</bcp14> be set to zero on transmission and disregarded
      on receipt.</t>

	</list>
	</t> receipt.</dd>
          </dl>
          <t>
   When forming the VXLAN encapsulation header:</t>

	<t><list style="symbols"><t>The
          <ul spacing="normal">
            <li>The values of the V, M, and R bits are NOT copied into the flags Flags
      field of the VXLAN header.  The flags Flags field of the VXLAN header is
      set as per <xref target="RFC7348"/>.</t> target="RFC7348" format="default"/>.</li>
            <li>
              <t>If the M bit is set, set to 1, the MAC Address is copied into the Inner
      Destination MAC Address field of the Inner Ethernet Header (see
      section 5 of
      <xref target="RFC7348"/>).<vspace blankLines="1"/> target="RFC7348" sectionFormat="of" section="5"/>).</t>
              <t>
	If the M bit is not set, set to 0, and the payload being sent through the
      VXLAN tunnel is an Ethernet frame, the Destination MAC Address
      field of the Inner Ethernet Header is just the Destination MAC
      Address field of the payload's Ethernet header.
	<vspace blankLines="1"/>
              </t>
              <t>
	If the M bit is not set, set to 0, and the payload being sent through the
      VXLAN tunnel is an IP or MPLS packet, the Inner Destination MAC
      Address field is set to a configured value; if there is no
      configured value, the VXLAN tunnel cannot be used.
              </t>
	<t>
            </li>
            <li> If the V bit is not set, set to 0, and the BGP UPDATE message has an
	  AFI/SAFI other than Ethernet VPNs (SAFI 70, "BGP EVPNs") EVPNs"), then the
	  VXLAN tunnel cannot be used.
	</t>

	<t><xref target="use-of-vni"/>
	</li>
            <li>
              <xref target="use-of-vni" format="default"/> describes how the VNI (VXLAN Network Identifier) field of the VXLAN encapsulation header is set.
    </t>

	</list>
	</t>
    </li>
          </ul>
          <t>
   Note that in order to send an IP packet or an MPLS packet through a
   VXLAN tunnel, the packet must first be encapsulated in an Ethernet
   header, which becomes the "inner "Inner Ethernet header" Header" described in
   <xref target="RFC7348"/>. target="RFC7348" format="default"/>.  The VXLAN Encapsulation sub-TLV may contain information
   (for example,the example, the MAC address) that is used to form this Ethernet header.</t>
        </section>
        <section title="NVGRE (tunnel type 9)"><t> numbered="true" toc="default">
          <name>NVGRE (Tunnel Type 9)</name>
          <t>
   This document defines an Encapsulation sub-TLV for <xref target="RFC7637">NVGRE</xref> target="RFC7637" format="default">NVGRE</xref> tunnels.
   When the Tunnel Type tunnel type is NVGRE, the length of the sub-TLV is 12 octets. The
   following is the structure of the Value field in the Encapsulation sub-TLV:</t> sub-TLV is shown in <xref target="ref-nvgre-encapsulation-sub-tlv"/>.</t>
          <figure title="NVGRE anchor="ref-nvgre-encapsulation-sub-tlv">
            <name>NVGRE Encapsulation Sub-TLV Value Field" anchor="ref-nvgre-encapsulation-sub-tlv"><artwork><![CDATA[ Field</name>
            <artwork name="" type="" align="left" alt=""><![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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |V|M|R|R|R|R|R|R|          VN-ID (3 Octets) octets)                     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 MAC Address (4 Octets) octets)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  MAC Address (2 Octets) octets)       |      Reserved (2 Octets) octets)      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
	<t><list hangIndent="3" style="hanging"><t>
      V:
          <dl newline="false" spacing="normal" indent="3">
            <dt>V:</dt>
            <dd>
      This bit is set to 1 to indicate that a VN-ID is
      present in the Encapsulation sub-TLV.  If set to 0,
      the VN-ID field is disregarded. Please see <xref target="use-of-vni"/>.</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t>
      M: target="use-of-vni" format="default"/>.</dd>
            <dt>M:</dt>
            <dd>
      This bit is set to 1 to indicate that a MAC Address is
      present in the Encapsulation sub-TLV. If set to 0,
      the MAC Address field is disregarded. </t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t>
      R: </dd>
            <dt>R:</dt>
            <dd>
      The remaining bits in the 8-bit flags Flags field are reserved for
      further use. They MUST <bcp14>MUST</bcp14> always be set to 0 by the originator of
      the sub-TLV. Intermediate routers MUST <bcp14>MUST</bcp14> propagate them without
      modification. Any receiving routers MUST <bcp14>MUST</bcp14> ignore
      these bits upon receipt.</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t>
      VN-ID: receipt.</dd>
            <dt>VN-ID:</dt>
            <dd>
      If the V bit is set, set to 1, the VN-ID field contains a 3 octet VN-
      ID 3-octet VN-ID value, used to set the NVGRE VSID (see Virtual Subnet Identifier (VSID; see <xref target="use-of-vni"/>). target="use-of-vni" format="default"/>).  If the V bit is not set, set to 0, the VN-ID field MUST <bcp14>MUST</bcp14> be set
      to zero on transmission and disregarded on receipt.</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t>
      MAC Address: receipt.</dd>
            <dt>MAC Address:</dt>
            <dd>
      If the M bit is set, set to 1, this field contains a 6 octet 6-octet
      Ethernet MAC address.  If the M bit is not set, set to 0, this field MUST <bcp14>MUST</bcp14>
      be set to all zeroes on transmission and disregarded on receipt.</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t>
      Reserved: MUST receipt.</dd>
            <dt>Reserved:</dt>
            <dd>
      <bcp14>MUST</bcp14> be set to zero on transmission and disregarded
      on receipt.</t>

	</list>
	</t> receipt.</dd>
          </dl>
          <t>
   When forming the NVGRE encapsulation header:</t>

	<t><list style="symbols"><t>The
          <ul spacing="normal">
            <li>The values of the V, M, and R bits are NOT copied into the flags Flags
      field of the NVGRE header.  The flags Flags field of the NVGRE header is
      set as per <xref target="RFC7637"/>.</t> target="RFC7637" format="default"/>.</li>
            <li>
              <t>If the M bit is set, set to 1, the MAC Address is copied into the Inner
      Destination MAC Address field of the Inner Ethernet Header (see
      section 3.2 of
      <xref target="RFC7637"/>).<vspace blankLines="1"/> target="RFC7637" sectionFormat="of" section="3.2"/>).</t>
              <t>
	If the M bit is not set, set to 0, and the payload being sent through the
      NVGRE tunnel is an Ethernet frame, the Destination MAC Address
      field of the Inner Ethernet Header is just the Destination MAC
      Address field of the payload's Ethernet header.
	<vspace blankLines="1"/>
              </t>
              <t>
	If the M bit is not set, set to 0, and the payload being sent through the
      NVGRE tunnel is an IP or MPLS packet, the Inner Destination MAC
      Address field is set to a configured value; if there is no
      configured value, the NVGRE tunnel cannot be used.
              </t>
	<t>
            </li>
            <li> If the V bit is not set, set to 0, and the BGP UPDATE message has an
	  AFI/SAFI other than Ethernet VPNs (EVPN) (EVPNs), then the
	  NVGRE tunnel cannot be used.
	</t>

	<t><xref target="use-of-vni"/>
	</li>
            <li>
              <xref target="use-of-vni" format="default"/> describes how the VSID (Virtual Subnet Identifier) field of the
      NVGRE encapsulation header is set.</t>

	</list>
	</t> set.</li>
          </ul>
        </section>
        <section title="L2TPv3 (tunnel type 1)"><t> numbered="true" toc="default">
          <name>L2TPv3 (Tunnel Type 1)</name>
          <t>
   When the Tunnel Type tunnel type of the TLV is <xref target="RFC3931">L2TPv3 target="RFC3931" format="default">L2TPv3 over IP</xref>, the length of the sub-TLV is
   between 4 and 12
   octets, depending on the length of the cookie.
   The following is the structure of the Value field of the Encapsulation sub-TLV:</t> sub-TLV is shown in <xref target="ref-l2tpv3-encapsulation-sub-tlv"/>.</t>
          <figure title="L2TPv3 anchor="ref-l2tpv3-encapsulation-sub-tlv">
            <name>L2TPv3 Encapsulation Sub-TLV Value Field" anchor="ref-l2tpv3-encapsulation-sub-tlv"><artwork><![CDATA[ Field</name>
            <artwork name="" type="" align="left" alt=""><![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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Session ID (4 octets)                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  |                        Cookie (Variable) (variable)                      |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
	<t><list hangIndent="3" style="hanging"><t>
      Session ID: a
          <dl newline="false" spacing="normal" indent="3">
            <dt>Session ID:</dt>
            <dd>
      A non-zero 4-octet value locally assigned by the
      advertising router that serves as a lookup key for the incoming
      packet's context.</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t>
      Cookie: an context.</dd>
            <dt>Cookie:</dt>
            <dd>
<t>
      An optional, variable length variable-length (encoded in octets -- 0 to 8
      octets) value used by L2TPv3 to check the association of a
      received data message with the session identified by the Session
      ID.  Generation and usage of the cookie value is as specified in
      <xref target="RFC3931"/>.</t>

	</list> target="RFC3931" format="default"/>. </t>

	<t><list hangIndent="3" style="hanging"><t>
<t>
      The length of the cookie is not encoded explicitly, explicitly but can be
      calculated as (sub-TLV length - 4).</t>

	</list>
	</t> 4).</t></dd>
          </dl>
        </section>
        <section title="GRE (tunnel type 2)" anchor="gre"><t> anchor="gre" numbered="true" toc="default">
          <name>GRE (Tunnel Type 2)</name>
          <t>
   When the Tunnel Type tunnel type of the TLV is <xref target="RFC2784">GRE</xref>, target="RFC2784" format="default">GRE</xref>, the length of the sub-TLV is 4 octets. The
   following is the structure of the Value field of the Encapsulation sub-TLV:</t> sub-TLV is shown in <xref target="ref-gre-encapsulation-sub-tlv"/>.</t>

          <figure title="GRE anchor="ref-gre-encapsulation-sub-tlv">
            <name>GRE Encapsulation Sub-TLV" anchor="ref-gre-encapsulation-sub-tlv"><artwork><![CDATA[ Sub-TLV Value Field</name>
            <artwork name="" type="" align="left" alt=""><![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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      GRE Key (4 octets)                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
	<t><list hangIndent="3" style="hanging"><t>
      GRE Key:
          <dl newline="false" spacing="normal" indent="3">
            <dt>GRE Key:</dt>
            <dd>
      4-octet field <xref target="RFC2890"/> target="RFC2890" format="default"/> that is generated by the
      advertising router. Note that the key is optional.  Unless a key value is being
      advertised, the GRE Encapsulation sub-TLV MUST NOT <bcp14>MUST NOT</bcp14> be present.</t>

	</list>
	</t> present.</dd>
          </dl>
        </section>
        <section title="MPLS-in-GRE (tunnel type 11)"><t> numbered="true" toc="default">
          <name>MPLS-in-GRE (Tunnel Type 11)</name>
          <t>
   When the Tunnel Type tunnel type is <xref target="RFC4023">MPLS-in-GRE</xref>, target="RFC4023" format="default">MPLS-in-GRE</xref>, the length of the sub-TLV is 4 octets. The
   following is the structure of the Value field of the Encapsulation sub-TLV:</t> sub-TLV is shown in <xref target="ref-mpls-in-gre-encapsulation-sub-tlv"/>.</t>
          <figure title="MPLS-in-GRE anchor="ref-mpls-in-gre-encapsulation-sub-tlv">
            <name>MPLS-in-GRE Encapsulation Sub-TLV Value Field" anchor="ref-mpls-in-gre-encapsulation-sub-tlv"><artwork><![CDATA[ Field</name>
            <artwork name="" type="" align="left" alt=""><![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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       GRE-Key                       GRE Key (4 Octets) octets)                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
	<t><list hangIndent="3" style="hanging"><t>
      GRE-Key:

          <dl newline="false" spacing="normal" indent="3">
            <dt>GRE Key:</dt>
            <dd>
      4-octet field <xref target="RFC2890"/> target="RFC2890" format="default"/> that is generated by the
      advertising router.  Note that the key is optional.  Unless a key
      value is being advertised, the MPLS-in-GRE Encapsulation sub-TLV
      MUST NOT
      <bcp14>MUST NOT</bcp14> be present.</t>

	</list>
	</t> present.</dd>
          </dl>
          <t>
   Note that the GRE Tunnel Type tunnel type defined in <xref target="gre"/> target="gre" format="default"/> can be used
   instead of the MPLS-in-GRE Tunnel Type tunnel type when it is necessary to
   encapsulate MPLS in GRE.  Including a TLV of the MPLS-in-GRE tunnel
   type is equivalent to including a TLV of the GRE Tunnel Type tunnel type that
   also includes a Protocol Type sub-TLV (<xref target="protocol-type"/>) target="protocol-type" format="default"/>) specifying MPLS
   as the protocol to be encapsulated.</t>
          <t>
   Although the MPLS-in-GRE tunnel type is just a special case of the GRE
   tunnel type and thus is not strictly necessary, it is included for reasons
   of backwards compatibility with, for example, implementations of <xref target="RFC8365"/>. target="RFC8365" format="default"/>.
</t>
        </section>
      </section>
      <section title="Outer numbered="true" toc="default">
        <name>Outer Encapsulation Sub-TLVs"><t> Sub-TLVs</name>
        <t>
   The Encapsulation sub-TLV for a particular Tunnel Type tunnel type allows one to
   specify the values that are to be placed in certain fields of the
   encapsulation header for that Tunnel Type. tunnel type.  However, some tunnel
   types require an outer IP encapsulation, and some also require an
   outer UDP encapsulation.  The Encapsulation sub-TLV for a given
   Tunnel Type
   tunnel type does not usually provide a way to specify values for
   fields of the outer IP and/or UDP encapsulations.  If it is necessary
   to specify values for fields of the outer encapsulation, additional
   sub-TLVs must be used.  This document defines two such sub-TLVs.</t>
        <t>
   If an outer Encapsulation sub-TLV occurs in a TLV for a Tunnel Type tunnel type
   that does not use the corresponding outer encapsulation, the sub-TLV
   MUST
   <bcp14>MUST</bcp14> be treated as if it were an unrecognized type of sub-TLV.</t>
        <section title="DS numbered="true" toc="default">
          <name>DS Field (type code 7)"><t> (Type Code 7)</name>
          <t>
   Most of the tunnel types that can be specified in the Tunnel
   Encapsulation attribute require an outer IP encapsulation.  The
   Differentiated Services (DS) Field sub-TLV can be carried in the TLV
   of any such Tunnel Type. tunnel type.  It specifies the setting of the one-octet
   Differentiated Services field in the outer IPv4 or IPv6 encapsulation (see
   <xref target="RFC2474"/>). target="RFC2474" format="default"/>).  Any one-octet value can be transported; the semantics
   of the DSCP (Differentiated Services Code Point) field is beyond the scope of this document.  The Value field is always a single octet.</t>
          <figure title="DS anchor="ref-ds-field">
            <name>DS Field Sub-TLV Value Field" anchor="ref-ds-field"><artwork><![CDATA[ Field</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
   0 1 2 3 4 5 6 7
  +-+-+-+-+-+-+-+-+
  |    DS value   |
  +-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>
   Because the interpretation of the DSCP field at the recipient may be
   different from its interpretation at the originator, an implementation
   MAY
   <bcp14>MAY</bcp14> provide a facility to use policy to filter or modify the DS Field. field.
          </t>
        </section>
        <section title="UDP numbered="true" toc="default">
          <name>UDP Destination Port (type code 8)"><t> (Type Code 8)</name>
          <t>
   Some of the tunnel types that can be specified in the Tunnel
   Encapsulation attribute require an outer UDP encapsulation.
   Generally
   Generally, there is a standard UDP Destination Port destination port value for a
   particular Tunnel Type. tunnel type.  However, sometimes it is useful to be able
   to use a non-standard nonstandard UDP destination port.  If a particular tunnel
   type requires an outer UDP encapsulation, and it is desired to use a
   UDP destination port other than the standard one, the port to be used
   can be specified by including a UDP Destination Port sub-TLV.  The
   Value field of this sub-TLV is always a two-octet field, containing
   the port value.  Any two-octet value other than zero can be transported.
   If the reserved value zero is received, the sub-TLV MUST <bcp14>MUST</bcp14> be treated
   as malformed malformed, according to the rules of <xref target="validation-and-error"/>.</t> target="validation-and-error" format="default"/>.</t>
          <figure title="UDP anchor="ref-udp-dest-port">
            <name>UDP Destination Port Sub-TLV Value Field" anchor="ref-udp-dest-port"><artwork><![CDATA[ Field</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
   0                   1
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       UDP Port (2 Octets) octets)     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
        </section>
      </section>
      <section title="Sub-TLVs numbered="true" toc="default">
        <name>Sub-TLVs for Aiding Tunnel Selection"> Selection</name>
        <section title="Protocol anchor="protocol-type" numbered="true" toc="default">
          <name>Protocol Type Sub-TLV (type code 2)" anchor="protocol-type"><t> (Type Code 2)</name>
          <t>
   The Protocol Type sub-TLV MAY <bcp14>MAY</bcp14> be included in a given TLV to indicate
   the type of the payload packets that are allowed to be encapsulated with the
   tunnel parameters that are being signaled in the TLV.  Packets with other
   payload types MUST NOT <bcp14>MUST NOT</bcp14> be encapsulated in the relevant tunnel. The Value
   field of the sub-TLV contains a 2-octet value from IANA's
"ETHER TYPES"
   registry <xref target="Ethertypes"/>. target="IANA-ETHERTYPES" />. If the reserved value 0xFFFF is
   received, the sub-TLV MUST <bcp14>MUST</bcp14> be treated
   as malformed according to the rules of <xref target="validation-and-error"/>.</t> target="validation-and-error" format="default"/>.</t>
          <figure title="Protocol anchor="ref-proto-type">
            <name>Protocol Type Sub-TLV Value Field" anchor="ref-proto-type"><artwork><![CDATA[ Field</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
   0                   1
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Ethertype (2 Octets) octets)     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>
   For example, if there are three L2TPv3 sessions, one carrying
   IPv4 packets, one carrying IPv6 packets, and one carrying MPLS
   packets, the egress router will include three TLVs of L2TPv3
   encapsulation type, each specifying a different Session ID and a
   different payload type.  The Protocol Type sub-TLV for these will be
   IPv4 (protocol type = 0x0800), IPv6 (protocol type = 0x86dd), and
   MPLS (protocol type = 0x8847), respectively.  This informs the
   ingress routers of the appropriate encapsulation information to use
   with each of the given protocol types.  Insertion of the specified
   Session ID at the ingress routers allows the egress to process the
   incoming packets correctly, according to their protocol type.</t>
          <t>
   Note that for tunnel types whose names are of the form "X-in-Y",
   for "X-in-Y"
   (for example, "MPLS-in-GRE", MPLS-in-GRE), only packets of the specified payload type "X"
   are to be carried through the tunnel of type "Y".  This is the
   equivalent of specifying a Tunnel Type tunnel type "Y" and including in its TLV a
   Protocol Type sub-TLV (see <xref target="protocol-type"/>) target="protocol-type" format="default"/>) specifying
   protocol "X".  If the Tunnel Type tunnel type is "X-in-Y", it is unnecessary,
   though harmless, to explicitly include a Protocol Type sub-TLV
   specifying "X". Also, for "X-in-Y" type tunnels, a Protocol Type
   sub-TLV specifying anything other than "X" MUST <bcp14>MUST</bcp14> be ignored; this is
   discussed further in <xref target="validation-and-error"/>. target="validation-and-error" format="default"/>.
          </t>
        </section>
        <section title="Color anchor="color" numbered="true" toc="default">
          <name>Color Sub-TLV (type code 4)" anchor="color"><t> (Type Code 4)</name>
          <t>
   The Color sub-TLV MAY <bcp14>MAY</bcp14> be used as a way to "color" the
   corresponding Tunnel TLV.  The Value field of the sub-TLV is eight
   octets long, long and consists of a Color Extended Community, as defined
   in <xref target="color-extcomm"/>. target="color-extcomm" format="default"/>.  For the use of this sub-TLV and Extended Community, extended community,
   please see <xref target="recursive-nh-resolution"/>.</t> target="recursive-nh-resolution" format="default"/>.</t>
          <t>The format of the Value field is depicted in
   <xref target="ref-color-extended-community"/>.</t> target="ref-color-extended-community" format="default"/>.</t>
          <t>
   If the Length field of a Color sub-TLV has a value other than 8, or the first two
   octets of its Value field are not 0x030b, the sub-TLV MUST <bcp14>MUST</bcp14> be
   treated as if it were an unrecognized sub-TLV (see <xref target="validation-and-error"/>).</t> target="validation-and-error" format="default"/>).</t>
        </section>
      </section>
      <section title="Embedded numbered="true" toc="default">
        <name>Embedded Label Handling Sub-TLV (type code 9)"><t> (Type Code 9)</name>
        <t>
   Certain BGP address families (corresponding to particular AFI/SAFI
   pairs, for example, 1/4, 2/4, 1/128, 2/128) have MPLS labels embedded in
   their NLRIs.  The term "embedded label" is used to refer to the
   MPLS label that is embedded in an NLRI, and the term "labeled address family"
   to refer to any AFI/SAFI that has embedded labels.</t>
        <t>
   Some of the tunnel types (for example, VXLAN and NVGRE) that can
   be specified in the Tunnel Encapsulation attribute have an
   encapsulation header containing a "Virtual Network" virtual network identifier of some
   sort.  The Encapsulation sub-TLVs for these tunnel types may
   optionally specify a value for the virtual network identifier.</t>
        <t>
   Suppose a Tunnel Encapsulation attribute is attached to an UPDATE of
   a labeled address family, and it is decided to use a particular
   tunnel (specified in one of the attribute's TLVs) for transmitting a
   packet that is being forwarded according to that UPDATE.  When
   forming the encapsulation header for that packet, different
   deployment scenarios require different handling of the embedded label
   and/or the virtual network identifier.  The Embedded Label Handling
   sub-TLV can be used to control the placement of the embedded label
   and/or the virtual network identifier in the encapsulation.</t>
        <t>
   The Embedded Label Handling sub-TLV may be included in any TLV of the
   Tunnel Encapsulation attribute.  If the Tunnel Encapsulation
   attribute is attached to an UPDATE of a non-labeled address family,
   then the sub-TLV MUST <bcp14>MUST</bcp14> be disregarded.  If the sub-TLV is contained in a
   TLV whose Tunnel Type tunnel type does not have a virtual network identifier in
   its encapsulation header, the sub-TLV MUST <bcp14>MUST</bcp14> be disregarded.  In
   those cases where the sub-TLV is ignored, it MUST NOT <bcp14>MUST NOT</bcp14> be
   stripped from the TLV before the route is propagated.</t>
        <t>
   The sub-TLV's Length field always contains the value 1, and its Value
   field consists of a single octet.  The following values are defined:</t>

	<t><list style="hanging" hangIndent="3"><t hangText="1: The
        <dl spacing="normal" indent="4">
          <dt>1:</dt><dd>The payload will be an MPLS packet with the embedded label at">
	<vspace blankLines="0"/> at the top of its label stack.
	</t>

	<t hangText="2: The stack.</dd>
          <dt>2:</dt>
	  <dd><t>The embedded label is not carried in the payload, payload but is carried">
	<vspace blankLines="0"/> either carried
	in the virtual network identifier Virtual Network Identifier field of the
	encapsulation header, header or else is ignored entirely.

	</t> entirely.</t>
	</dd>
        </dl>
	<t>If any value other than 1 or 2 is carried, the sub-TLV MUST <bcp14>MUST</bcp14> be
	considered malformed, according to the procedures of <xref target="validation-and-error"/>.
	</t>

	</list>
	</t> target="validation-and-error" format="default"/>.</t>

        <t>
   Please see <xref target="use-of-vni"/> target="use-of-vni" format="default"/> for the details of how this sub-TLV is used when
   it is carried by an UPDATE of a labeled address family.</t>
        <figure title="Embedded anchor="ref-embedded-label">
          <name>Embedded Label Handling Sub-TLV Value Field" anchor="ref-embedded-label"><artwork><![CDATA[ Field</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
   0 1 2 3 4 5 6 7
  +-+-+-+-+-+-+-+-+
  |     1 or 2    |
  +-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
      </section>
      <section title="MPLS anchor="label-stack" numbered="true" toc="default">
        <name>MPLS Label Stack Sub-TLV (type code 10)" anchor="label-stack"><t> (Type Code 10)</name>
        <t>
   This sub-TLV allows an MPLS label stack (<xref target="RFC3032"/>) <xref target="RFC3032" format="default"/> to be associated
   with a particular tunnel.</t>
        <t>
   The length of the sub-TLV is a multiple of 4 octets octets, and the Value field of this sub-TLV
   is a sequence of MPLS label stack entries.  The first entry in the sequence is the
   "topmost" label, and the final entry in the sequence is the "bottommost" label.  When this
   label stack is pushed onto a packet, this ordering MUST <bcp14>MUST</bcp14> be preserved.</t>

	<t><list style="hanging" hangIndent="-1"><t hangText="Each
        <dl newline="true" spacing="normal">
          <dt>Each label stack entry has the following format:">
	<vspace blankLines="0"/>
	</t>

	</list>
	</t> format shown in <xref target="ref-mpls-label-stack-sub-tlv"/>.</dt>
          <dd/>
        </dl>
        <figure title="MPLS anchor="ref-mpls-label-stack-sub-tlv">
          <name>MPLS Label Stack Sub-TLV Value Field" anchor="ref-mpls-label-stack-sub-tlv"><artwork><![CDATA[ Field</name>
          <artwork name="" type="" align="left" alt=""><![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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                Label                  |  TC |S|      TTL      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>
   The fields are as defined in <xref target="RFC3032"/>, target="RFC3032" format="default"/> and <xref target="RFC5462"/>. target="RFC5462" format="default"/>.
        </t>
        <t>
   If a packet is to be sent through the tunnel identified in a
   particular TLV, and if that TLV contains an MPLS Label Stack sub-TLV,
   then the label stack appearing in the sub-TLV MUST <bcp14>MUST</bcp14> be pushed onto the
   packet before any
   other labels are pushed onto the packet. (See <xref target="usage"/> target="usage" format="default"/>
   for further discussion.)</t>
        <t>
   In particular, if the Tunnel Encapsulation attribute is attached to a
   BGP UPDATE of a labeled address family, the contents of the MPLS
   Label Stack sub-TLV MUST <bcp14>MUST</bcp14> be pushed onto the packet before the label
   embedded in the NLRI is pushed onto the packet.</t>
        <t>
   If the MPLS Label Stack sub-TLV is included in a TLV identifying a
   Tunnel Type
   tunnel type that uses virtual network identifiers (see <xref target="use-of-vni"/>), target="use-of-vni" format="default"/>),
   the contents of the MPLS Label Stack sub-TLV MUST <bcp14>MUST</bcp14> be pushed onto the
   packet before the procedures of <xref target="use-of-vni"/> target="use-of-vni" format="default"/> are applied.</t>
        <t>
   The number of label stack entries in the sub-TLV MUST <bcp14>MUST</bcp14> be determined
   from the sub-TLV length Sub-TLV Length field.  Thus  Thus, it is not necessary to set the S
   bit in any of the label stack entries of the sub-TLV, and the setting
   of the S bit is ignored when parsing the sub-TLV.  When the label stack entries are pushed onto a packet that already has a label
   stack, the S bits of all the entries being pushed MUST <bcp14>MUST</bcp14> be cleared.  When the label stack entries are pushed onto a packet that does not already have a
   label stack, the S bit of the bottommost label stack entry MUST <bcp14>MUST</bcp14> be
   set, and the S bit of all the other label stack entries MUST <bcp14>MUST</bcp14> be
   cleared.</t>
        <t>
   The TC (Traffic Class) Traffic Class (TC) field (<xref target="RFC3270"/>, <xref
   target="RFC5129"/>) target="RFC3270" format="default"/><xref target="RFC5129" format="default"/> of each label stack entry SHOULD <bcp14>SHOULD</bcp14> be set to 0,
   unless changed by policy at the originator of the sub-TLV.  When
   pushing the label stack onto a packet, the TC of each label stack
   SHOULD
   <bcp14>SHOULD</bcp14> be preserved, unless local policy results in a modification.
        </t>
        <t>
   The TTL (Time to Live) field of each label stack entry SHOULD <bcp14>SHOULD</bcp14> be set
   to 255, unless changed to some other non-zero value by policy at the
   originator of the sub-TLV. When pushing the label stack onto a
   packet, the TTL of each label stack entry SHOULD <bcp14>SHOULD</bcp14> be preserved, unless
   local policy results in a modification to some other non-zero value.
   If any label stack entry in the sub-TLV has a TTL value of zero, the
   router that is pushing the stack on onto a packet MUST <bcp14>MUST</bcp14> change the value to
   a non-zero value, either 255 or some other value as determined by
   policy as discussed above.</t>
        <t>
   Note that this sub-TLV can appear within a TLV identifying any
   type of tunnel, not just within a TLV identifying an MPLS tunnel.
   However, if this sub-TLV appears within a TLV identifying an MPLS
   tunnel (or an MPLS-in-X tunnel), this sub-TLV plays the same role
   that would be played by an MPLS Encapsulation sub-TLV.  Therefore, an
   MPLS Encapsulation sub-TLV is not defined.</t>
        <t>
   Although this specification does not supply detailed instructions
   for validating the received label stack, implementations might
   impose restrictions on the label stack they can support. If an
   invalid or unsupported label stack is received, <!-- the sub-TLV MAY
   be treated as malformed according to the procedures of
   <xref target="validation-and-error"/>,
   or --> the tunnel MAY <bcp14>MAY</bcp14> be treated as not feasible feasible, according to the
   procedures of <xref target="usage"/>. target="usage" format="default"/>.
        </t>
      </section>
      <section title="Prefix-SID anchor="prefix-sid" numbered="true" toc="default">
        <name>Prefix-SID Sub-TLV (type code 11)" anchor="prefix-sid"><t> (Type Code 11)</name>
        <t>
   <xref target="RFC8669"/> target="RFC8669" format="default"/> defines a BGP Path path
   attribute known as the "Prefix-SID Attribute". "BGP Prefix-SID attribute".  This attribute is
   defined to contain a sequence of one or more TLVs, where each TLV is
   either a "Label-Index" TLV, Label-Index TLV or an "Originator Originator SRGB (Source Routing
   Global Block)" Block) TLV.</t>
        <t>
   This document defines a Prefix-SID (Prefix Segment Identifier) sub-TLV.
   The Value field of the Prefix-SID sub-TLV can be set to any permitted
   value of the Value field of a BGP Prefix-SID attribute <xref
   target="RFC8669"/>. target="RFC8669" format="default"/>.
        </t>
        <t>
   <xref target="RFC8669"/> target="RFC8669" format="default"/> only defines behavior when the BGP Prefix-SID
   Attribute
   attribute is attached to routes of type IPv4/IPv6 Labeled Unicast
   (<xref target="RFC4760"/>,
   <xref target="RFC8277"/>), target="RFC4760" format="default"/><xref target="RFC8277" format="default"/>, and it only
   defines values of the BGP Prefix-SID Attribute attribute for those cases. Therefore,
   similar limitations exist for the Prefix-SID sub-TLV: it SHOULD <bcp14>SHOULD</bcp14> only
   be included in a BGP UPDATE message for one of the address families
   for which <xref target="RFC8669" format="default"/> has a defined in behavior, namely BGP IPv4/IPv6 Labeled Unicast <xref target="RFC4760" format="default"/> <xref target="RFC8669"/>. target="RFC8277" format="default"/>. If included in a BGP UPDATE for
   any other address family then family, it MUST <bcp14>MUST</bcp14> be ignored.
        </t>
        <t>
   The Prefix-SID sub-TLV can occur in a TLV identifying any type of
   tunnel.  If an Originator SRGB is specified in the sub-TLV, that SRGB
   MUST
   <bcp14>MUST</bcp14> be interpreted to be the SRGB used by the tunnel's
   egress endpoint.  The Label-Index, if present, is the Segment Routing SID
   that the tunnel's egress endpoint uses to represent the prefix
   appearing in the NLRI field of the BGP UPDATE to which the Tunnel
   Encapsulation attribute is attached.</t>
        <t>
   If a Label-Index is present in the Prefix-SID sub-TLV, then when a
   packet is sent through the tunnel identified by the TLV, if that tunnel
   is from a labeled address family, the
   corresponding MPLS label MUST <bcp14>MUST</bcp14> be pushed on the packet's label stack.
   The corresponding MPLS label is computed from the Label-Index value
   and the SRGB of the route's originator, as specified in section 4.1
   of
   <xref target="RFC8669"/>.</t> target="RFC8669" sectionFormat="of" section="4.1"/>.</t>
        <t>
   The corresponding MPLS label is pushed on after the processing of the
   MPLS Label Stack sub-TLV, if present, as specified in <xref target="label-stack"/>. target="label-stack" format="default"/>.
   It is pushed on before any other labels (for example, a label embedded in an
   UPDATE's NLRI, NLRI or a label determined by the procedures of <xref target="use-of-vni"/>), target="use-of-vni" format="default"/>) are pushed on the stack.</t>
        <t>
   The Prefix-SID sub-TLV has slightly different semantics than the
   BGP Prefix-SID attribute.  When the BGP Prefix-SID attribute is attached to a
   given route, the BGP speaker that originally attached the attribute
   is expected to be in the same Segment Routing domain as the BGP
   speakers who receive the route with the attached attribute.  The
   Label-Index tells the receiving BGP speakers what the prefix-SID Prefix-SID is
   for the advertised prefix in that Segment Routing domain.  When the
   Prefix-SID sub-TLV is used, there is no implication that the
   prefix-SID
   Prefix-SID for the advertised prefix is the same in the Segment
   Routing domains of the BGP speaker that originated the sub-TLV and
   the BGP speaker that received it.</t>
      </section>
    </section>
    <section title="Extended numbered="true" toc="default">
      <name>Extended Communities Related to the Tunnel Encapsulation Attribute"> Attribute</name>
      <section title="Encapsulation anchor="encapsulation-extcomm" numbered="true" toc="default">
        <name>Encapsulation Extended Community" anchor="encapsulation-extcomm"> Community</name>
        <t>
   The Encapsulation Extended Community is a Transitive Opaque Extended
   Community. </t>
        <t> The Encapsulation Extended Community encoding is as shown below </t> in <xref target="ref-Encapsulation-extended-community"/>.</t>
        <figure title="Encapsulation anchor="ref-Encapsulation-extended-community">
          <name>Encapsulation Extended Community" anchor="ref-Encapsulation-extended-community"><artwork><![CDATA[ Community</name>
          <artwork name="" type="" align="left" alt=""><![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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | 0x03 (1 Octet)| octet)| 0x0c (1 Octet)| octet)|       Reserved (2 Octets) octets)     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Reserved (2 Octets) octets)       |    Tunnel Type (2 Octets) octets)     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t>The value of the high-order octet of the extended type Type field is 0x03,
   which indicates it's transitive.  The value of the low-order octet of
   the extended type Type field is 0x0c.</t>
        <t>The last two octets of the Value field encode a tunnel type.</t>

        <t>This Extended Community extended community may be attached to a route of any
   AFI/SAFI to which the Tunnel Encapsulation attribute may be attached.
   Each such Extended Community extended community identifies a particular Tunnel Type, tunnel type; its
   semantics are the same as semantics of a Tunnel Encapsulation attribute
   Tunnel TLV in a Tunnel Encapsulation attribute,
    for which the following three conditions all hold:</t>

	<t><list style="numbers"><t>it
        <ol spacing="normal" type="1">
	  <li>It identifies the same Tunnel Type,</t>

	<t>it tunnel type.</li>
          <li>
            <t>It has a Tunnel Egress Endpoint sub-TLV for which one of the following
       two conditions holds:<list style="letters"><t>its "Address Family" holds:</t>
            <ol spacing="normal" type="a">
	      <li>Its Address Family subfield contains zero, or</t>

	<t>its "Address" or</li>
              <li>Its Address subfield contains the address of the next hop Next Hop field of
           the route to which the Tunnel Encapsulation attribute is attached</t>

	</list>
	</t>

	<t>it attached.</li>
            </ol>
          </li>
          <li>It has no other sub-TLVs.</t>

	</list>
	</t> sub-TLVs.</li>
        </ol>
        <t>
	  Such a Tunnel TLV is called a "barebones" Tunnel TLV.</t>
        <t>
   The Encapsulation Extended Community was first defined in <xref target="RFC5512"/>. target="RFC5512" format="default"/>.
   While it provides only a small subset of the functionality of the
   Tunnel Encapsulation attribute, it is used in a number of deployed
   applications,
   applications and is still needed for backwards compatibility.
   In situations where a tunnel could be encoded using
   a barebones TLV, it MUST <bcp14>MUST</bcp14> be encoded using the corresponding
   Encapsulation Extended Community.  Notwithstanding, an implementation
   MUST
   <bcp14>MUST</bcp14> be prepared to process a tunnel received encoded as a barebones
   TLV.</t>
        <t>
   Note that for tunnel types of the form "X-in-Y", for "X-in-Y" (for example, MPLS-in-GRE, MPLS-in-GRE),
   the Encapsulation Extended Community implies that only packets of the
   specified payload type "X" are to be carried through the tunnel of
   type "Y". Packets with other payload types MUST NOT <bcp14>MUST NOT</bcp14> be carried through
   such tunnels. See also <xref target="encaps-attr"/>.</t> target="encaps-attr" format="default"/>.</t>
        <t>
   In the remainder of this specification, when a route is referred to as
   containing a Tunnel Encapsulation attribute with a TLV identifying a
   particular Tunnel Type, tunnel type, it implicitly includes the case where
   the route contains a Tunnel an Encapsulation Extended Community
   identifying that Tunnel Type.</t> tunnel type.</t>
      </section>
      <section title="Router's numbered="true" toc="default">
        <name>Router's MAC Extended Community"><t> Community</name>
        <t>
   <xref target="I-D.ietf-bess-evpn-inter-subnet-forwarding"/> target="I-D.ietf-bess-evpn-inter-subnet-forwarding" format="default"/> defines a Router's router's MAC
   Extended Community. This Extended Community, extended community, as its name implies,
   carries the MAC address of the advertising router. Since the VXLAN
   and NVGRE Encapsulation Sub-TLVs sub-TLVs can also optionally carry a router's
   MAC, a conflict can arise if both the Router's MAC Extended Community
   and such an Encapsulation Sub-TLV sub-TLV are present at the same time but
   have different values. In
   case of such a conflict, the information in the Router's MAC Extended Community
   MUST
   <bcp14>MUST</bcp14> be used.</t>
      </section>
      <section title="Color anchor="color-extcomm" numbered="true" toc="default">
        <name>Color Extended Community" anchor="color-extcomm"><t> Community</name>
        <t>
   The Color Extended Community is a Transitive Opaque Extended
   Community with the following encoding:</t> encoding shown in <xref target="ref-color-extended-community"/>.</t>
        <figure title="Color anchor="ref-color-extended-community">
          <name>Color Extended Community" anchor="ref-color-extended-community"><artwork><![CDATA[ Community</name>
          <artwork name="" type="" align="left" alt=""><![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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | 0x03 (1 Octet)| octet)| 0x0b (1 Octet)| octet)|        Flags (2 Octets) octets)       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Color Value (4 Octets) octets)                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>
   The value of the high-order octet of the extended type Type field is 0x03, which
   indicates it is transitive.  The value of the low-order octet of the extended
   type
   Type field for this community is 0x0b.  The color value is user defined and
   configured locally. No flags are defined in this document; this field MUST <bcp14>MUST</bcp14> be set to
   zero by the originator and ignored by the receiver; the value MUST NOT <bcp14>MUST NOT</bcp14> be
   changed when propagating this Extended Community. extended community. The Color Value field is
   encoded as 4 octet a 4-octet value by the administrator and is outside the scope
   of this document. For the use of this Extended Community extended community, please see
  <xref target="recursive-nh-resolution"/>.</t> target="recursive-nh-resolution" format="default"/>.</t>
      </section>
    </section>
    <section title="Special anchor="ipip-considerations" numbered="true" toc="default">
      <name>Special Considerations for IP-in-IP Tunnels" anchor="ipip-considerations"><t> Tunnels</name>
      <t>
   In certain situations with an IP fabric underlay, one could have a tunnel overlay
   with the tunnel type IP-in-IP. The egress BGP speaker can advertise the
   IP-in-IP tunnel endpoint address in the Tunnel Egress Endpoint sub-TLV. When
   the Tunnel tunnel type of the TLV is IP-in-IP, it will not have a Virtual Network
   Identifier. virtual network
   identifier. However, the tunnel egress endpoint address can be used in identifying
   the forwarding table to use for making the forwarding decisions to forward
   the payload.</t>
    </section>
    <section title="Semantics anchor="usage" numbered="true" toc="default">
      <name>Semantics and Usage of the Tunnel Encapsulation attribute" anchor="usage"> Attribute</name>
      <t>
   The BGP Tunnel Encapsulation attribute MAY <bcp14>MAY</bcp14> be carried in any BGP
   UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6
   Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast),
   1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast),
   or 25/70 (Ethernet VPN, usually known as EVPN)). EVPN).  Use of the Tunnel
   Encapsulation attribute in BGP UPDATE messages of other AFI/SAFIs is
   outside the scope of this document.</t>
      <t>
   There is no significance to the order in which the TLVs occur within
   the Tunnel Encapsulation attribute.  Multiple TLVs may occur for a
   given Tunnel Type; tunnel type; each such TLV is regarded as describing a
   different tunnel. (This also applies if the Tunnel Encapsulation
   Extended Community encoding is used.)</t>
      <t>
   The decision to attach a Tunnel Encapsulation attribute to a given
   BGP UPDATE is determined by policy.  The set of TLVs and sub-TLVs
   contained in the attribute is also determined by policy.</t>
      <t>
   Suppose that:</t>

	<t><list style="symbols"><t>a
      <ul spacing="normal">
        <li>a given packet P must be forwarded by router R;</t>

	<t>the R;</li>
        <li>the path along which P is to be forwarded is determined by BGP
      UPDATE U;</t> U;</li>
        <li>
          <t>UPDATE U has a Tunnel Encapsulation attribute, containing at least
      one TLV that identifies a "feasible tunnel" for packet P.  A
      tunnel is considered feasible if it has the following four
      properties:<list style="symbols"><t>The Tunnel Type
      properties:</t>
          <ol spacing="normal">
            <li>The tunnel type is supported (that is, router R knows how to set up tunnels of that type, how to create the encapsulation header for tunnels of that type, etc.)</t>

	<t>The etc.).</li>
            <li>The tunnel is of a type that can be used to carry packet P (for example, an MPLS-in-UDP tunnel would not be a feasible tunnel for
         carrying an IP packet, unless the IP packet can first be
         encapsulated in a MPLS packet).</t>

	<t>The packet).</li>
            <li>The tunnel is specified in a TLV whose Tunnel Egress Endpoint sub-TLV
		 identifies an IP address that is reachable. The reachability condition
		 is evaluated as per <xref target="RFC4271"/>. target="RFC4271" format="default"/>.  If the IP address is
		 reachable via more than one forwarding table, local policy is used
		 to determine which table to use.</t>

    <t>There use.</li>
            <li>There is no local policy that prevents the use of the tunnel.</t>

	</list>
	</t>

	</list>
	</t> tunnel.</li>
          </ol>
        </li>
      </ul>
      <t>
   Then router R MUST <bcp14>MUST</bcp14> send packet P through one of the feasible
   tunnels identified in the Tunnel Encapsulation attribute of UPDATE U.</t>
      <t>
   If the Tunnel Encapsulation attribute contains several TLVs (that is, if
   it specifies several feasible tunnels), router R may choose any one of those
   tunnels, based upon local policy.  If any Tunnel TLV contains
   one or more Color sub-TLVs (<xref target="color"/>) target="color" format="default"/>) and/or the Protocol Type sub-TLV (<xref target="protocol-type"/>), target="protocol-type" format="default"/>), the choice of tunnel may be influenced by these
   sub-TLVs. Many other factors, for example example, minimization of encapsulation header encapsulation-header
   overhead, could also be used to influence selection.</t>
      <t>
   The reachability to the address of the egress endpoint of the tunnel may change over
   time, directly impacting the feasibility of the tunnel. A tunnel that is not
   feasible at some moment, moment may become feasible at a later time when its egress endpoint
   address is reachable. The router may start using the newly feasible tunnel
   instead of an existing one. How this decision is made is outside the scope
   of this document.</t>
      <t>
   Once it is determined to send a packet through the tunnel specified
   in a particular Tunnel TLV of a particular Tunnel Encapsulation attribute,
   then the tunnel's egress endpoint address is the IP address contained
   in the Tunnel Egress Endpoint sub-TLV.  If the Tunnel TLV contains a Tunnel Egress Endpoint sub-TLV
   whose Value field is all zeroes, then the tunnel's egress endpoint is the
   address of the Next Hop next hop of the BGP Update UPDATE containing the Tunnel Encapsulation
   attribute.
   attribute (that is, the Network Address of Next Hop field of the
   MP_REACH_NLRI attribute if the encoding of [RFC4760] is in use or
   the NEXT_HOP attribute otherwise).  The address of the tunnel egress endpoint generally appears in a
   "destination address"
   Destination Address field of the encapsulation.</t>
      <t>
   The full set of procedures for sending a packet through a particular
   Tunnel Type
   tunnel type to a particular tunnel egress endpoint depends upon the tunnel
   type,
   type and is outside the scope of this document.  Note that some
   tunnel types may require the execution of an explicit tunnel setup
   protocol before they can be used for carrying data.  Other tunnel
   types may not require any tunnel setup protocol.</t>
      <t>
   Sending a packet through a tunnel always requires that the packet be
   encapsulated, with an encapsulation header that is appropriate for
   the Tunnel Type. tunnel type.  The contents of the tunnel encapsulation header may
   be influenced by the Encapsulation sub-TLV.  If there is no
   Encapsulation sub-TLV present, the router transmitting the packet
   through the tunnel must have a priori knowledge (for example, by
   provisioning) of how to fill in the various fields in the
   encapsulation header.</t>
      <t>
   A Tunnel Encapsulation attribute may contain several TLVs that all
   specify the same Tunnel Type. tunnel type.  Each TLV should be considered as
   specifying a different tunnel.  Two tunnels of the same type may have
   different Tunnel Egress Endpoint sub-TLVs, different Encapsulation sub-TLVs,
   etc.  Choosing between two such tunnels is a matter of local policy.</t>
      <t>
   Once router R has decided to send packet P through a particular
   tunnel, it encapsulates packet P appropriately and then forwards it
   according to the route that leads to the tunnel's egress endpoint.
   This route may itself be a BGP route with a Tunnel Encapsulation
   attribute.  If so, the encapsulated packet is treated as the payload
   and is encapsulated according to the Tunnel Encapsulation attribute
   of that route.  That is, tunnels may be "stacked".</t>
      <t>
   Notwithstanding anything said in this document, a BGP speaker MAY <bcp14>MAY</bcp14>
   have local policy that influences the choice of tunnel, tunnel and the way
   the encapsulation is formed.  A BGP speaker MAY <bcp14>MAY</bcp14> also have a local
   policy that tells it to ignore the Tunnel Encapsulation attribute
   entirely or in part.  Of course, interoperability issues must be
   considered when such policies are put into place.</t>
      <t>
    See also <xref target="validation-and-error"/>, target="validation-and-error" format="default"/>, which provides further
    specification regarding validation and exception cases.</t>
    </section>
    <section title="Routing Considerations">
	  <section title="Impact numbered="true" toc="default">
      <name>Routing Considerations</name>
      <section numbered="true" toc="default">
        <name>Impact on the BGP Decision Process"><t> Process</name>
        <t>
	      The presence of the Tunnel Encapsulation attribute affects
	      the BGP best route selection route-selection algorithm. If a route includes
	      the Tunnel Encapsulation attribute, and if that attribute
	      includes no tunnel which that is feasible, then that route MUST
	      NOT <bcp14>MUST
	      NOT</bcp14> be considered resolvable for the purposes of Route Resolvability
	      Condition <xref target="RFC4271"/> Section 9.1.2.1. the route resolvability
	      condition (<xref target="RFC4271" sectionFormat="comma" section="9.1.2.1"/>).
        </t>
      </section>
      <section title="Looping, numbered="true" toc="default">
        <name>Looping, Mutual Recursion, Etc."><t> Etc.</name>
        <t>
   Consider a packet destined for address X.  Suppose a BGP UPDATE for
   address prefix X carries a Tunnel Encapsulation attribute that
   specifies a tunnel egress endpoint of Y, and suppose that a BGP
   UPDATE for address prefix Y carries a Tunnel Encapsulation attribute
   that specifies a tunnel egress endpoint of X.  It is easy to see that this
   can have no good outcome. <xref target="RFC4271"/> target="RFC4271" format="default"/> describes an analogous case
   as mutually recursive routes.</t>
        <t>
   This could happen as a result of misconfiguration, either accidental
   or intentional.  It could also happen if the Tunnel Encapsulation
   attribute were altered by a malicious agent.  Implementations should
   be aware that such an attack will result in unresolvable BGP routes due to the
   mutually recursive relationship. This document does not specify a maximum number of
   recursions; that is an implementation-specific matter.</t>
        <t>
   Improper setting (or malicious altering) of the Tunnel Encapsulation
   attribute could also cause data packets to loop.  Suppose a BGP
   UPDATE for address prefix X carries a Tunnel Encapsulation attribute
   that specifies a tunnel egress endpoint of Y.  Suppose router R
   receives and processes the advertisement. When router R receives a packet
   destined for X, it will apply the encapsulation and send the
   encapsulated packet to Y.  Y will decapsulate the packet and forward
   it further.  If Y is further away from X than is router R, it is
   possible that the path from Y to X will traverse R.  This would cause
   a long-lasting routing loop.  The control plane itself cannot detect
   this situation, though a TTL field in the payload packets would
   prevent any given packet from looping infinitely.</t>
        <t>
   During the deployment of techniques as described
   in this document, operators are encouraged to avoid mutually
   recursive route and/or tunnel dependencies. There is greater
   potential for such scenarios to arise when the tunnel egress endpoint for a
   given prefix differs from the address of the next hop for that
   prefix.</t>
      </section>
    </section>
    <section title="Recursive Next Hop Resolution" anchor="recursive-nh-resolution"><t> anchor="recursive-nh-resolution" numbered="true" toc="default">
      <name>Recursive Next-Hop Resolution</name>
      <t>
   Suppose that:</t>

	<t><list style="symbols"><t>a
      <ul spacing="normal">
        <li>a given packet P must be forwarded by router R1;</t>

	<t>the R1;</li>
        <li>the path along which P is to be forwarded is determined by BGP
      UPDATE U1;</t>

	<t>UPDATE U1;</li>
        <li>UPDATE U1 does not have a Tunnel Encapsulation attribute;</t>

	<t>the attribute;</li>
        <li>the address of the next hop of UPDATE U1 is router R2;</t>

	<t>the R2;</li>
        <li>the best route to router R2 is a BGP route that was advertised in
      UPDATE U2;</t>

	<t>UPDATE U2; and</li>
        <li>UPDATE U2 has a Tunnel Encapsulation attribute.</t>

	</list>
	</t> attribute.</li>
      </ul>
      <t>
   Then packet P MUST <bcp14>MUST</bcp14> be sent through one of the tunnels identified in
   the Tunnel Encapsulation attribute of UPDATE U2.  See <xref target="usage"/> target="usage" format="default"/> for
   further details.</t>
      <t>
   However, suppose that one of the TLVs in U2's Tunnel Encapsulation
   attribute contains one or more Color Sub-TLVs. sub-TLVs.  In that case, packet P MUST
   NOT <bcp14>MUST
   NOT</bcp14> be sent through the tunnel contained in that TLV, unless U1 is
   carrying a Color Extended Community that is identified in one of U2's
   Color Sub-TLVs.</t> sub-TLVs.</t>
      <t>
   The procedures in this section presuppose that U1's address of the next hop
   resolves to a BGP route, and that U2's next hop resolves (perhaps after
   further recursion) to a non-BGP route.</t>
    </section>
    <section title="Use anchor="use-of-vni" numbered="true" toc="default">
      <name>Use of Virtual Network Identifiers and Embedded Labels when When Imposing a Tunnel Encapsulation" anchor="use-of-vni"><t> Encapsulation</name>
      <t>
   If the TLV specifying a tunnel contains an MPLS Label Stack sub-TLV,
   then when sending a packet through that tunnel, the procedures of
   <xref target="label-stack"/> target="label-stack" format="default"/> are applied before the procedures of this section.</t>
      <t>
   If the TLV specifying a tunnel contains a Prefix-SID sub-TLV, the
   procedures of <xref target="prefix-sid"/> target="prefix-sid" format="default"/> are applied before the procedures of this
   section.  If the TLV also contains an MPLS Label Stack sub-TLV, the
   procedures of <xref target="label-stack"/> target="label-stack" format="default"/> are applied before the procedures of
   <xref target="prefix-sid"/>.</t> target="prefix-sid" format="default"/>.</t>
      <section title="Tunnel numbered="true" toc="default">
        <name>Tunnel Types without a Virtual Network Identifier Field"> Field</name>
        <t>
		If a Tunnel Encapsulation attribute is attached to an UPDATE of a
		labeled address family, there will be one or more labels specified in
		the UPDATE's NLRI.  When a packet is sent through a tunnel specified
		in one of the attribute's TLVs, and that tunnel type does not contain
		a virtual network identifier Virtual Network Identifier field, the label or labels from the NLRI
		are pushed on the packet's label stack.  The resulting MPLS packet is
		then further encapsulated, as specified by the TLV.
        </t>
      </section>
      <section title="Tunnel numbered="true" toc="default">
        <name>Tunnel Types with a Virtual Network Identifier Field"><t> Field</name>
        <t>
   Two of the tunnel types that can be specified in a Tunnel
   Encapsulation TLV have virtual network identifier Virtual Network Identifier fields in their
   encapsulation headers.  In the VXLAN encapsulation,
   this field is called the VNI (VXLAN Network Identifier) field; in
   the NVGRE encapsulation, this field is called the VSID (Virtual
   Subnet Identifier) field.</t>
        <t>
   When one of these tunnel encapsulations is imposed on a packet, the
   setting of the virtual network identifier Virtual Network Identifier field in the encapsulation
   header depends upon the contents of the Encapsulation sub-TLV (if one
   is present).  When the Tunnel Encapsulation attribute is being
   carried in a BGP UPDATE of a labeled address family, the setting of
   the virtual network identifier Virtual Network Identifier field also depends upon the contents
   of the Embedded Label Handling sub-TLV (if present).</t>
        <t>
   This section specifies the procedures for choosing the value to set
   in the virtual network identifier Virtual Network Identifier field of the encapsulation header.
   These procedures apply only when the Tunnel Type tunnel type is VXLAN
   or NVGRE.</t>
        <section title="Unlabeled numbered="true" toc="default">
          <name>Unlabeled Address Families"><t> Families</name>
          <t>
   This sub-section subsection applies when:</t>

	<t><list style="symbols"><t>the
          <ul spacing="normal">
            <li>the Tunnel Encapsulation attribute is carried in a BGP UPDATE of
      an unlabeled address family, and</t>

	<t>at </li>
            <li>at least one of the attribute's TLVs identifies a Tunnel Type tunnel type that
      uses a virtual network identifier, and</t>

	<t>it and</li>
            <li>it has been determined to send a packet through one of those
      tunnels.</t>

	</list>
	</t>
      tunnels.</li>
          </ul>
          <t>
   If the TLV identifying the tunnel contains an Encapsulation sub-TLV
   whose V bit is set, set to 1, the virtual network identifier Virtual Network Identifier field of the
   encapsulation header is set to the value of the virtual network
   identifier Virtual Network
   Identifier field of the Encapsulation sub-TLV.</t>
          <t>
   Otherwise, the virtual network identifier Virtual Network Identifier field of the encapsulation
   header is set to a configured value; if there is no configured value,
   the tunnel cannot be used.</t>
        </section>
        <section title="Labeled numbered="true" toc="default">
          <name>Labeled Address Families"><t> Families</name>
          <t>
   This sub-section subsection applies when:</t>

	<t><list style="symbols"><t>the
          <ul spacing="normal">
            <li>the Tunnel Encapsulation attribute is carried in a BGP UPDATE of a
      labeled address family, and</t>

	<t>at family,</li>
            <li>at least one of the attribute's TLVs identifies a Tunnel Type tunnel type that
      uses a virtual network identifier, and</t>

	<t>it and</li>
            <li>it has been determined to send a packet through one of those
      tunnels.</t>

	</list>
	</t>
      tunnels.</li>
          </ul>
          <section title="When anchor="valid-vni" numbered="true" toc="default">
            <name>When a Valid VNI has been Signaled" anchor="valid-vni"><t> Has Been Signaled</name>
            <t>
   If the TLV identifying the tunnel contains an Encapsulation sub-TLV
   whose V bit is set, set to 1, the virtual network identifier Virtual Network Identifier field of the
   encapsulation header is set to the value of the virtual network identifier Virtual Network Identifier
   field of the Encapsulation sub-TLV. However, the Embedded Label Handling
   sub-TLV will determine label processing as described below.</t>

	<t><list style="symbols"><t>If
            <ul spacing="normal">
              <li>If the TLV contains an Embedded Label
      Handling sub-TLV whose value is 1, the embedded label (from the NLRI
      of the route that is carrying the Tunnel Encapsulation attribute)
      appears at the top of the MPLS label stack in the encapsulation payload.

        </t>

	<t>If

        </li>
              <li>If the TLV does not contain an Embedded Label Handling sub-TLV, or
      it contains an Embedded Label Handling sub-TLV whose value is 2,
      the embedded label is ignored entirely.</t>

	</list>
	</t> entirely.</li>
            </ul>
          </section>
          <section title="When anchor="no-valid-vni" numbered="true" toc="default">
            <name>When a Valid VNI has not been Signaled" anchor="no-valid-vni"><t> Has Not Been Signaled</name>
            <t>
   If the TLV identifying the tunnel does not contain an Encapsulation
   sub-TLV whose V bit is set, set to 1, the virtual network identifier Virtual Network Identifier field of
   the encapsulation header is set as follows:</t>

	<t><list style="symbols"><t>If
            <ul spacing="normal">
              <li>
                <t>If the TLV contains an Embedded Label Handling sub-TLV whose value
      is 1, then the virtual network identifier Virtual Network Identifier field of the
      encapsulation header is set to a configured value.<vspace blankLines="1"/> value.</t>
                <t>
	If there is no configured value, the tunnel cannot be used.
	<vspace blankLines="1"/>
                </t>
                <t>
	The embedded label (from the NLRI of the route that is carrying
      the Tunnel Encapsulation attribute) appears at the top of the MPLS
      label stack in the encapsulation payload.
                </t>
              </li>
              <li>
                <t>If the TLV does not contain an Embedded Label Handling sub-TLV, or
      if it contains an Embedded Label Handling sub-TLV whose value is
      2, the embedded label is copied into the lower 3 octets of the virtual
      network identifier Virtual
      Network Identifier field of the encapsulation header.<vspace blankLines="1"/> header.</t>
                <t>
	In this case, the payload may or may not contain an MPLS label
      stack, depending upon other factors.  If the payload does contain
      an MPLS label stack, the embedded label does not appear in that
      stack.
                </t>

	</list>
	</t>
              </li>
            </ul>
          </section>
        </section>
      </section>
    </section>
    <section title="Applicability Restrictions" anchor="applicability"><t> anchor="applicability" numbered="true" toc="default">
      <name>Applicability Restrictions</name>
      <t>
   In a given UPDATE of a labeled address family, the label embedded in
   the NLRI is generally a label that is meaningful only to the router
   represented by the address of the next hop.  Certain of the procedures of Sections
   <xref target="valid-vni"/> target="valid-vni" format="counter"/> or <xref target="no-valid-vni"/> target="no-valid-vni" format="counter"/> cause the embedded label to be
   carried by a data packet to the router whose address appears in the
   Tunnel Egress Endpoint sub-TLV.  If the Tunnel Egress Endpoint sub-TLV does not
   identify the same router represented by the address of the next hop, sending the
   packet through the tunnel may cause the label to be misinterpreted at the
   tunnel's egress endpoint.  This may cause misdelivery of the packet.
   Avoidance of this unfortunate outcome is a matter of network planning
   and design, design and is outside the scope of this document.</t>
      <t>
   Note that if the Tunnel Encapsulation attribute is attached to a VPN-
   IP route <xref target="RFC4364"/>, and target="RFC4364" format="default"/>, if Inter-AS "option b" (see section 10 of
   <xref target="RFC4364"/>) target="RFC4364" sectionFormat="of" section="10"/>) is being used, and if the Tunnel Egress Endpoint sub-TLV contains
   an IP address that is not in the same AS as the router receiving the
   route, it is very likely that the embedded label has been changed.
   Therefore
   Therefore, use of the Tunnel Encapsulation attribute in an "Inter-AS option b" scenario is
   not recommended.</t>
      <t>
   Other documents may define other ways to signal tunnel information in
   BGP. For example, <xref target="RFC6514"/> target="RFC6514" format="default"/> defines the "P-Multicast
   Service Interface Tunnel" (PMSI Tunnel) attribute. In this
   specification, we do not consider the effects of advertising the
   Tunnel Encapsulation Attribute attribute in conjunction with other forms of
   signaling tunnels. Any document specifying such joint use MUST <bcp14>MUST</bcp14>
   provide details as to how interactions should be handled.
      </t>
    </section>
    <section title="Scoping" anchor="scoping"><t> anchor="scoping" numbered="true" toc="default">
      <name>Scoping</name>
      <t>
   The Tunnel Encapsulation attribute is defined as a transitive
   attribute, so that it may be passed along by BGP speakers that do not
   recognize it.  However  However, the Tunnel Encapsulation
   attribute MUST <bcp14>MUST</bcp14> be used only within a well-defined scope, for example, within a
   set of Autonomous Systems ASes that belong to a single administrative
   entity.  If the attribute is distributed beyond its intended scope,
   packets may be sent through tunnels in a manner that is not intended.</t>
      <t>
   To prevent the Tunnel Encapsulation attribute from being distributed
   beyond its intended scope, any BGP speaker that understands the
   attribute MUST <bcp14>MUST</bcp14> be able to filter the attribute from incoming BGP
   UPDATE messages.  When the attribute is filtered from an incoming
   UPDATE, the attribute is neither processed nor distributed.  This
   filtering SHOULD <bcp14>SHOULD</bcp14> be possible on a per-BGP-session basis; finer
   granularities (for example, per route and/or per attribute TLV) MAY <bcp14>MAY</bcp14> be
   supported.  For each external BGP (EBGP) session, filtering of the attribute on
   incoming UPDATEs MUST <bcp14>MUST</bcp14> be enabled by default.</t>
      <t>
   In addition, any BGP speaker that understands the attribute MUST <bcp14>MUST</bcp14> be
   able to filter the attribute from outgoing BGP UPDATE messages.  This
   filtering SHOULD <bcp14>SHOULD</bcp14> be possible on a per-BGP-session basis.  For each EBGP
   session, filtering of the attribute on outgoing UPDATEs MUST <bcp14>MUST</bcp14> be
   enabled by default.</t>
      <t>
   Since the Tunnel Encapsulation Extended Community provides a subset
   of the functionality of the Tunnel Encapsulation attribute, these
   considerations apply equally in its case: any </t>
<ul>
<li>Any BGP speaker that
   understands it MUST <bcp14>MUST</bcp14> be able to filter it from incoming BGP UPDATE
   messages, it MUST
   messages.</li>
<li>It <bcp14>MUST</bcp14> be possible to filter the Tunnel Encapsulation
   Extended Community from outgoing messages, and in messages.</li>
<li>In both cases cases, this
   filtering MUST <bcp14>MUST</bcp14> be enabled by default for EBGP sessions.
   </t> sessions.</li>
</ul>

    </section>
    <section title="Operational Considerations"> numbered="true" toc="default">
      <name>Operational Considerations</name>
      <t>
	A potential operational difficulty arises when tunnels are used, if the
	size of packets entering the tunnel exceeds the
	maximum transmission unit (MTU) the tunnel is capable of supporting. This
	difficulty can be exacerbated by stacking multiple tunnels, since each
	stacked tunnel header further reduces the supportable MTU. This issue is
	long-standing and well-known. The tunnel
	signaling provided in this specification does nothing to address this
	issue, nor to aggravate it (except insofar as it may further increase the
	popularity of tunneling). <!-- A detailed discussion of this issue can be
	found in <xref target="I-D.ietf-intarea-tunnels"/>. -->
      </t>
    </section>
    <section title="Validation anchor="validation-and-error" numbered="true" toc="default">
      <name>Validation and Error Handling" anchor="validation-and-error"><t> Handling</name>
      <t>
   The Tunnel Encapsulation attribute is a sequence of TLVs, each of
   which is a sequence of sub-TLVs.  The final octet of a TLV is
   determined by its length Length field.  Similarly, the final octet of a sub-
   TLV is determined by its length Length field.  The final octet of a TLV MUST <bcp14>MUST</bcp14>
   also be the final octet of its final sub-TLV.  If this is not the
   case, the TLV MUST <bcp14>MUST</bcp14> be considered to be malformed,
   and the "Treat-as-withdraw" procedure of
   <xref target="RFC7606"/> target="RFC7606" format="default"/> is applied. </t>
      <t>
   If a Tunnel Encapsulation attribute does not have any valid TLVs, or
   it does not have the transitive bit set, the "Treat-as-withdraw"
   procedure of <xref target="RFC7606"/> target="RFC7606" format="default"/> is applied.</t>
      <t>
   If a Tunnel Encapsulation attribute can be parsed correctly, correctly but
   contains a TLV whose Tunnel Type tunnel type is not recognized by a particular
   BGP speaker, that BGP speaker MUST NOT <bcp14>MUST NOT</bcp14> consider the attribute to be
   malformed.  Rather, it MUST <bcp14>MUST</bcp14>
   interpret the attribute as if that
   TLV had not been present.  If the route carrying the Tunnel
   Encapsulation attribute is propagated with the attribute, the
   unrecognized TLV MUST <bcp14>MUST</bcp14> remain in the attribute.</t>
      <t>
   The following sub-TLVs defined in this document MUST NOT <bcp14>MUST NOT</bcp14> occur more
   than once in a given Tunnel TLV: Tunnel Egress Endpoint (discussed below),
   Encapsulation, DS, UDP Destination Port, Embedded Label
   Handling, MPLS Label Stack, and Prefix-SID.  If a Tunnel TLV has more
   than one of any of these sub-TLVs, all but the first occurrence of
   each such sub-TLV type MUST <bcp14>MUST</bcp14> be disregarded.  However, the
   Tunnel TLV containing them MUST NOT <bcp14>MUST NOT</bcp14> be considered to be malformed,
   and all the sub-TLVs MUST <bcp14>MUST</bcp14> be propagated if the route carrying the
   Tunnel Encapsulation attribute is propagated.</t>
      <t>
   The following sub-TLVs defined in this document may appear zero or
   more times in a given Tunnel TLV: Protocol Type, Type and Color.  Each
   occurrence of such sub-TLVs is meaningful.  For example, the Color
   sub-TLV may appear multiple times to assign multiple colors to a
   tunnel. </t>
      <t>
   If a TLV of a Tunnel Encapsulation attribute contains a sub-TLV that
   is not recognized by a particular BGP speaker, the BGP speaker MUST <bcp14>MUST</bcp14>
   process that TLV as if the unrecognized sub-TLV had not been present.
   If the route carrying the Tunnel Encapsulation attribute is
   propagated with the attribute, the unrecognized sub-TLV MUST <bcp14>MUST</bcp14> remain in
   the attribute.</t>
      <t>
   In general, if a TLV contains a sub-TLV that is malformed,
   the sub-TLV MUST <bcp14>MUST</bcp14> be treated as if it were an unrecognized sub-TLV.
   There is one exception to this rule -- rule: if a TLV
   contains a malformed Tunnel Egress Endpoint sub-TLV (as defined in
   <xref target="tunnel-egress-endpoint"/>), target="tunnel-egress-endpoint" format="default"/>), the entire TLV MUST <bcp14>MUST</bcp14> be ignored, ignored and
   MUST <bcp14>MUST</bcp14> be removed from the Tunnel Encapsulation attribute before the
   route carrying that attribute is distributed.</t>
      <t>
   Within a Tunnel Encapsulation attribute that is carried by a BGP
   UPDATE whose AFI/SAFI is one of those explicitly listed in the second first
   paragraph of <xref target="usage"/>, target="usage" format="default"/>, a TLV that does not contain exactly one
   Tunnel Egress Endpoint sub-TLV MUST <bcp14>MUST</bcp14> be treated as if it contained a
   malformed Tunnel Egress Endpoint sub-TLV.</t>
      <t>
   A TLV identifying a particular Tunnel Type tunnel type may contain a sub-TLV that
   is meaningless for that Tunnel Type. tunnel type.  For example, perhaps the TLV
   contains a  UDP Destination Port  sub-TLV, but the identified tunnel
   type does not use UDP encapsulation at all, or a tunnel of the form
   "X-in-Y" contains a Protocol Type sub-TLV that specifies something
   other than "X". Sub-TLVs of this sort MUST <bcp14>MUST</bcp14> be disregarded.  That is,
   they MUST NOT <bcp14>MUST NOT</bcp14> affect the creation of the encapsulation header.
   However, the sub-TLV MUST NOT <bcp14>MUST NOT</bcp14> be considered to be malformed, malformed and MUST
   NOT <bcp14>MUST&nbsp;NOT</bcp14> be removed from the TLV before the route carrying the Tunnel
   Encapsulation attribute is distributed. An implementation MAY <bcp14>MAY</bcp14> log a
   message when it encounters such a sub-TLV.</t>
    </section>
    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
	This document makes
	IANA has made the updates described in the following requests of IANA. (All subsections.
All registration
	procedures listed below are per their definitions in
	<xref target="RFC8126"/>.)</t> target="RFC8126" format="default"/>.</t>
      <section title="Obsoleting numbered="true" toc="default">
        <name>Obsoleting RFC 5512"> 5512</name>
        <t>
   Because this document obsoletes RFC 5512, change all registration
   information that IANA has updated
   references <xref target="RFC5512"/> to instead reference RFC 5512 to point to this document.</t> document in the following registries:</t>
<ul>
<li>"Border Gateway Protocol (BGP) Extended Communities" registry <xref target="IANA-BGP-EXT-COMM" /></li>
<li>"Border Gateway Protocol (BGP) Parameters" registry <xref target="IANA-BGP-PARAMS" /></li>
<li>"Border Gateway Protocol (BGP) Tunnel Encapsulation" registry <xref target="IANA-BGP-TUNNEL-ENCAP" /></li>
<li>"Subsequent Address Family Identifiers (SAFI) Parameters" registry <xref target="IANA-SAFI" /></li>
</ul>

      </section>
      <section title="Obsoleting anchor="obsoleting-5566-and-5640" numbered="true" toc="default">
        <name>Obsoleting Code Points Assigned by RFCs 5566"
	 anchor="obsoleting-5566-and-5640"> RFC 5566</name>
        <t>
	Since this document obsoletes RFC 5566, the code points
	assigned by that RFC are similarly obsoleted. Specifically, the
	following code points should be have been marked as deprecated.</t>
        <t>
	In the
"BGP Tunnel Encapsulation Attribute Tunnel Types" registry:</t>

	<texttable>
	<ttcol>Value</ttcol>
	<ttcol>Name</ttcol>
	<c>3</c>
	<c>Transmit tunnel endpoint</c>
	<c>4</c>
	<c>IPsec in Tunnel-mode</c>
	<c>5</c>
	<c>IP registry <xref target="IANA-BGP-TUNNEL-ENCAP" />:</t>
        <table align="center">
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Name</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">3</td>
              <td align="left">Transmit tunnel endpoint (DEPRECATED)</td>
            </tr>
            <tr>
              <td align="left">4</td>
              <td align="left">IPsec in Tunnel-mode (DEPRECATED)</td>
            </tr>
            <tr>
              <td align="left">5</td>
              <td align="left">IP in IP tunnel with IPsec Transport Mode</c>
	<c>6</c>
	<c>MPLS-in-IP Mode (DEPRECATED)</td>
            </tr>
            <tr>
              <td align="left">6</td>
              <td align="left">MPLS-in-IP tunnel with IPsec Transport Mode</c>
	</texttable> Mode (DEPRECATED)</td>
            </tr>
          </tbody>
        </table>
        <t>
	And in the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry:</t>

	<texttable>
	<ttcol>Value</ttcol>
	<ttcol>Name</ttcol>
	<c>3</c>
	<c>IPsec Tunnel Authenticator</c>
	</texttable>

	</section>

	<section title="BGP registry <xref target="IANA-BGP-TUNNEL-ENCAP" />:</t>
        <table align="center">
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Name</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">3</td>
              <td align="left">IPsec Tunnel Authenticator (DEPRECATED)</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section numbered="true" toc="default">
        <name>Border Gateway Protocol (BGP) Tunnel Encapsulation Parameters Grouping"> Grouping</name>
        <t>
   Create
   IANA has created a new registry grouping, to be grouping named
   "BGP
   "Border Gateway Protocol (BGP) Tunnel Encapsulation Parameters". Encapsulation" <xref target="IANA-BGP-TUNNEL-ENCAP"/>.
        </t>
      </section>
      <section title="BGP numbered="true" toc="default">
        <name>BGP Tunnel Encapsulation Attribute Tunnel Types"> Types</name>
        <t>
   Relocate
   IANA has relocated the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry to be
   under the "BGP "Border Gateway Protocol (BGP) Tunnel Encapsulation Parameters" grouping. Encapsulation" grouping <xref target="IANA-BGP-TUNNEL-ENCAP"/>.
        </t>
      </section>
      <section title="Subsequent numbered="true" toc="default">
        <name>Subsequent Address Family Identifiers"><t>
   Modify Identifiers</name>
        <t>
   IANA has modified the "Subsequent Address Family Identifiers" "SAFI Values" registry <xref target="IANA-SAFI"/> to
   indicate that the Encapsulation SAFI (value 7) is has been
   obsoleted.  This document should be is listed as the reference.</t> reference for this change.</t>
      </section>
      <section title="BGP numbered="true" toc="default">
        <name>BGP Tunnel Encapsulation Attribute Sub-TLVs"> Sub-TLVs</name>
        <t>
   Relocate
   IANA has relocated the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry to be under
   the "BGP "Border Gateway Protocol (BGP) Tunnel Encapsulation Parameters" grouping.</t> Encapsulation" grouping <xref target="IANA-BGP-TUNNEL-ENCAP"/>.</t>
        <t>
   Add
   IANA has included the following note to the registry:</t>

	<t><list hangIndent="3" style="hanging"><t>
   <blockquote>
      If the Sub-TLV Type is in the range from 0 to 127 inclusive, (inclusive), the
      Sub-TLV Length field contains one octet.  If the Sub-TLV Type is
      in the range from 128-255 inclusive, 128 to 255 (inclusive), the Sub-TLV Length field
      contains two octets.</t>

	</list>
	</t> octets.
   </blockquote>
        <t>
   Change
   IANA has updated the registration policy procedures of the
   registry to the following:</t>

	<texttable>
	<ttcol>Value(s)</ttcol>
	<ttcol>Registration Procedure</ttcol>
	<c>0</c>
	<c>Reserved</c>
	<c>1-63</c>
	<c>Standards Action</c>
	<c>64-125</c>
	<c>First
        <table align="center">
          <thead>
            <tr>
              <th align="left">Range</th>
              <th align="left">Registration Procedures</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">1-63</td>
              <td align="left">Standards Action</td>
            </tr>
            <tr>
              <td align="left">64-125</td>
              <td align="left">First Come First Served</c>
	<c>126-127</c>
	<c>Experimental Use</c>
	<c>128-191</c>
	<c>Standards Action</c>
	<c>192-252</c>
	<c>First Served</td>
            </tr>
            <tr>
              <td align="left">126-127</td>
              <td align="left">Experimental Use</td>
            </tr>
            <tr>
              <td align="left">128-191</td>
              <td align="left">Standards Action</td>
            </tr>
            <tr>
              <td align="left">192-252</td>
              <td align="left">First Come First Served</c>
	<c>253-254</c>
	<c>Experimental Use</c>
	<c>255</c>
	<c>Reserved</c>
	</texttable>

   <t>Rename Served</td>
            </tr>
            <tr>
              <td align="left">253-254</td>
              <td align="left">Experimental Use</td>
            </tr>
          </tbody>
        </table>

        <t>IANA has added the following entries within the to this registry:</t>

   <texttable>
   <ttcol>Value</ttcol>
   <ttcol>Old Name</ttcol>
   <ttcol>New Name</ttcol>
   <c>6</c>
   <c>Remote Endpoint</c>
   <c>Tunnel
        <table align="center">
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0</td>
              <td align="left">Reserved</td>
              <td align="left">RFC 9012</td>
            </tr>
            <tr>
              <td align="left">6</td>
              <td align="left">Tunnel Egress Endpoint</c>
   <c>7</c>
   <c>IPv4 DS Field</c>
   <c>DS Field</c>
   </texttable>

	</section>

	<section title="Flags Endpoint</td>
              <td align="left">RFC 9012</td>
            </tr>
            <tr>
              <td align="left">7</td>
              <td align="left">DS Field</td>
              <td align="left">RFC 9012</td>
            </tr>

            <tr>
              <td align="left">8</td>
              <td align="left">UDP Destination Port</td>
              <td align="left">RFC 9012</td>
            </tr>
            <tr>
              <td align="left">9</td>
              <td align="left">Embedded Label Handling</td>
              <td align="left">RFC 9012</td>
            </tr>
            <tr>
              <td align="left">10</td>
              <td align="left">MPLS Label Stack</td>
              <td align="left">RFC 9012</td>
            </tr>
            <tr>
              <td align="left">11</td>
              <td align="left">Prefix-SID</td>
              <td align="left">RFC 9012</td>
            </tr>
            <tr>
              <td align="left">255</td>
              <td align="left">Reserved</td>
              <td align="left">RFC 9012</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section numbered="true" toc="default">
        <name>Flags Field of VXLAN Encapsulation sub-TLV">

	<t>Create Sub-TLV</name>
        <t>IANA has created a registry named "Flags Field of VXLAN Encapsulation sub-TLV" Sub-TLVs" under
   the "BGP "Border Gateway Protocol (BGP) Tunnel Encapsulation Parameters" grouping. Encapsulation" grouping <xref target="IANA-BGP-TUNNEL-ENCAP"/>. The registration policy for
   this registry is "Standards Action". The minimum possible value is 0, and the
   maximum is 7.</t>
        <t>The initial values for this new registry are indicated below.</t>

   <texttable>
    <ttcol align='center'>Bit Position</ttcol>
    <ttcol align='left'>Description</ttcol>
    <ttcol align='left'>Reference</ttcol>
    <c>0</c>
    <c>V (VN-ID)</c>
    <c>(this document)</c>
    <c>1</c>
    <c>M in <xref target="flags-vxlan"/>.</t>
        <table align="center" anchor="flags-vxlan">
          <thead>
            <tr>
              <th align="center">Bit Position</th>
              <th align="left">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">0</td>
              <td align="left">V (VN-ID)</td>
              <td align="left">RFC 9012</td>
            </tr>
            <tr>
              <td align="center">1</td>
              <td align="left">M (MAC Address)</c>
    <c>(this document)</c>
   </texttable> Address)</td>
              <td align="left">RFC 9012</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="Flags numbered="true" toc="default">
        <name>Flags Field of NVGRE Encapsulation sub-TLV">
	<t>Create Sub-TLV</name>
        <t>IANA has created a registry named "Flags Field of NVGRE Encapsulation sub-TLV" Sub-TLVs" under
   the "BGP "Border Gateway Protocol (BGP) Tunnel Encapsulation Parameters" grouping. Encapsulation" grouping <xref target="IANA-BGP-TUNNEL-ENCAP"/>. The registration policy for
   this registry is "Standards Action". The minimum possible value is 0, and the
   maximum is 7.</t>
        <t>The initial values for this new registry are indicated below.</t>

   <texttable>
    <ttcol align='center'>Bit Position</ttcol>
    <ttcol align='left'>Description</ttcol>
    <ttcol align='left'>Reference</ttcol>
    <c>0</c>
    <c>V (VN-ID)</c>
    <c>(this document)</c>
    <c>1</c>
    <c>M in <xref target="flags-nvgre"/>.</t>
        <table align="center" anchor="flags-nvgre">
          <thead>
            <tr>
              <th align="center">Bit Position</th>
              <th align="left">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">0</td>
              <td align="left">V (VN-ID)</td>
              <td align="left">RFC 9012</td>
            </tr>
            <tr>
              <td align="center">1</td>
              <td align="left">M (MAC Address)</c>
    <c>(this document)</c>
   </texttable> Address)</td>
              <td align="left">RFC 9012</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="Embedded numbered="true" toc="default">
        <name>Embedded Label Handling sub-TLV">
	<t>Create Sub-TLV</name>
        <t>IANA has created a registry named "Embedded Label Handling sub-TLV" Sub-TLVs" under
   the "BGP "Border Gateway Protocol (BGP) Tunnel Encapsulation Parameters" grouping. Encapsulation" grouping <xref target="IANA-BGP-TUNNEL-ENCAP"/>. The registration policy for
   this registry is "Standards Action". The minimum possible value is 0, and the
   maximum is 255.</t>
        <t>The initial values for this new registry are indicated below.</t>

   <texttable>
    <ttcol align='center'>Value</ttcol>
    <ttcol align='left'>Description</ttcol>
    <ttcol align='left'>Reference</ttcol>
    <c>0</c>
    <c>Reserved</c>
    <c>(this document)</c>
    <c>1</c>
    <c>Payload in <xref target="embedded-label"/>.</t>
        <table align="center" anchor="embedded-label">
          <thead>
            <tr>
              <th align="center">Value</th>
              <th align="left">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">0</td>
              <td align="left">Reserved</td>
              <td align="left">RFC 9012</td>
            </tr>
            <tr>
              <td align="center">1</td>
              <td align="left">Payload of MPLS with embedded label</c>
    <c>(this document)</c>
    <c>2</c>
    <c>no label</td>
              <td align="left">RFC 9012</td>
            </tr>
            <tr>
              <td align="center">2</td>
              <td align="left">No embedded label in payload</c>
    <c>(this document)</c>
   </texttable> payload</td>
              <td align="left">RFC 9012</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="Color anchor="color-extcomm-flags" numbered="true" toc="default">
        <name>Color Extended Community Flags" anchor="color-extcomm-flags">
	<t>Create Flags</name>
        <t>IANA has created a registry named "Color Extended Community Flags" under
   the "BGP "Border Gateway Protocol (BGP) Tunnel Encapsulation Parameters" grouping. Encapsulation" grouping <xref target="IANA-BGP-TUNNEL-ENCAP"/>. The registration policy for
   this registry is "Standards Action". The minimum possible value is 0, and the
   maximum is 15.</t>

   <t>No initial
        <t>   This new registry contains columns for "Bit Position", "Description", and
   "Reference". No values are to be have currently been registered. The format of the registry
   is shown below.</t>

      <texttable>
    <ttcol align='center'>Bit Position</ttcol>
    <ttcol align='left'>Description</ttcol>
    <ttcol align='left'>Reference</ttcol>
	</texttable>
</t>
      </section>
    </section>
    <section title="Security Considerations" anchor="security"> anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
   As <xref target="scoping"/> target="scoping" format="default"/> discusses, it is intended that the
   Tunnel Encapsulation attribute be used only within a well-defined
   scope, for example, within a set of Autonomous Systems ASes that belong to a
   single administrative entity. As long as the filtering mechanisms
   discussed in that section are applied diligently, an attacker outside
   the scope would not be able to use the Tunnel Encapsulation attribute
   in an attack. This leaves open the questions of attackers within the
   scope (for example, a compromised router) and failures in filtering
   that allow an external attack to succeed.
      </t>
      <t>
   As <xref target="RFC4272"/> target="RFC4272" format="default"/> discusses, BGP is vulnerable to traffic
   diversion traffic-diversion attacks. The Tunnel Encapsulation attribute adds a new
   means by which an attacker could cause traffic to be diverted from
   its normal path, especially when the Tunnel Egress Endpoint sub-TLV
   is used. Such an attack would differ from pre-existing
   vulnerabilities in that traffic could be tunneled to a distant target
   across intervening network infrastructure, allowing an attack to
   potentially succeed more easily, since less infrastructure would have
   to be subverted. Potential consequences include "hijacking" of
   traffic (insertion of an undesired node in the path allowing path, which allows for
   inspection or modification of traffic, or avoidance of security
   controls) or denial of service (directing traffic to a node that
   doesn't desire to receive it).
      </t>
      <t>
   In order to further mitigate the risk of diversion of traffic from
   its intended destination, <xref target="address-validation"/> target="address-validation" format="default"/>
   provides an optional procedure to check that the destination given in
   a Tunnel Egress Endpoint sub-TLV is within the AS that was the source
   of the route. One then has some level of assurance that the tunneled
   traffic is going to the same destination AS that it would have gone
   to had the Tunnel Encapsulation attribute not been present. As RFC
   4272 discusses, it's possible for an attacker to announce an
   inaccurate AS_PATH, therefore AS_PATH; therefore, an attacker with the ability to inject
   a Tunnel Egress Endpoint sub-TLV could equally craft an AS_PATH that would
   pass the validation procedures of <xref
   target="address-validation"/>. target="address-validation" format="default"/>. BGP Origin Validation origin validation <xref
   target="RFC6811"/> target="RFC6811" format="default"/> and BGPsec <xref target="RFC8205"/> target="RFC8205" format="default"/> provide means to increase assurance that the origins being validated have not been
   falsified.
      </t>
      <t>
   Many tunnels carry traffic that embeds a destination address that comes
   from a non-global namespace. One example is MPLS VPNs. If a tunnel
   crosses from one namespace to another, without the necessary translation
   being performed for the embedded address(es), there exists a risk of
   misdelivery of traffic. If the traffic contains confidential data that's
   not otherwise protected (for example, by end-to-end encryption) encryption), then
   confidential information could be revealed. The restriction of applicability
   of the Tunnel Encapsulation attribute to a well-defined scope limits the
   likelihood of this occurring. See the discussion of "option b" in
   <xref target="applicability"/> target="applicability" format="default"/> for further discussion of one such
   scenario.
      </t>
      <t>
   RFC 8402 specifies that "SR domain boundary routers MUST <bcp14>MUST</bcp14> filter any
   external traffic" (<xref target="RFC8402"/> Section 8.1). target="RFC8402" sectionFormat="comma" section="8.1"/>). For these
   purposes, traffic introduced into a an SR domain using the Prefix-SID
   sub-TLV lies within the SR domain, even though the prefix-SIDs Prefix-SIDs used
   by the routers at the two ends of the tunnel may be different, as
   discussed in <xref target="prefix-sid"/>. target="prefix-sid" format="default"/>. This implies that the duty
   to filter external traffic extends to all routers participating in
   such tunnels.
      </t>
    </section>

	<section title="Acknowledgments"><t>
   This document contains text from RFC 5512, authored by Pradosh
   Mohapatra and Eric Rosen.  The authors of the current document wish to thank
   them for their contribution.  RFC 5512 itself built upon prior work by Gargi
   Nalawade, Ruchi Kapoor, Dan Tappan, David Ward, Scott Wainner, Simon
   Barber, Lili Wang, and Chris Metz, whom the authors also thank for their
   contributions. Eric Rosen was the principal author of earlier versions
   of this document.</t>

	<t>
   The authors wish to thank Lou Berger, Ron Bonica, Martin Djernaes,
   John Drake, Susan Hares, Satoru Matsushima, Thomas Morin, Dhananjaya Rao, Ravi
   Singh, Harish Sitaraman, Brian Trammell, Xiaohu Xu, and Zhaohui Zhang for their review,
   comments, and/or helpful discussions. Alvaro Retana provided an
   especially comprehensive review.</t>

	</section>

	<section title="Contributor Addresses"><t>
   Below is a list of other contributing authors in alphabetical order:</t>

	<figure><artwork><![CDATA[
Randy Bush
Internet Initiative Japan
5147 Crystal Springs
Bainbridge Island, Washington  98110
United States

Email: randy@psg.com

Robert Raszuk
Bloomberg LP
731 Lexington Ave
New York City, NY  10022
United States

Email: robert@raszuk.net

Eric C. Rosen

]]></artwork>
	</figure>
	</section>
  </middle>
  <back>
	<references title="Normative References">
	&RFC2119;
	&RFC7606;
	&RFC8174;
	&RFC2784;
	&RFC2890;
	&RFC3032;
	&RFC3270;
	&RFC3931;
	&RFC4023;
	&RFC5129;
	&RFC5462;
	&RFC6811;
	&RFC7348;
	&RFC7637;
	&RFC4271;
	&RFC6890;
	&RFC8669;
	&RFC2474;
	&RFC4760;
	&RFC8126;

<displayreference target="I-D.ietf-bess-evpn-inter-subnet-forwarding" to="EVPN-INTER-SUBNET"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7606.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2784.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2890.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3270.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3931.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4023.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5129.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5462.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6811.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7348.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7637.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6890.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8669.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4760.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      </references>
	<references title="Informative References">
      <references>
        <name>Informative References</name>

<!-- [I-D.ietf-bess-evpn-inter-subnet-forwarding] IESG state IESG Evaluation::AD Followup -->

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-bess-evpn-inter-subnet-forwarding.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4272.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5565.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5640.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8205.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8277.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5566.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7510.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5512.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6514.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8365.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>

<reference anchor="Ethertypes" target="http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml"><front>
	<title>IANA Ethertype Registry</title>
	<author>
	</author>

	<date/> anchor="IANA-BGP-TUNNEL-ENCAP"
           target="https://www.iana.org/assignments/bgp-tunnel-encapsulation/">
  <front>
    <title>Border Gateway Protocol (BGP) Tunnel Encapsulation</title>
    <author><organization>IANA</organization></author>
  </front>
</reference>

<reference anchor="IANA-BGP-PARAMS"
           target="https://www.iana.org/assignments/bgp-parameters/">
  <front>
    <title>Border Gateway Protocol (BGP) Parameters</title>
    <author><organization>IANA</organization></author>
  </front>
</reference>

<reference anchor="IANA-ADDRESS-FAM"
           target="https://www.iana.org/assignments/address-family-numbers/">
  <front>
    <title>Address Family Numbers</title>
    <author><organization>IANA</organization></author>
  </front>
</reference>

<reference anchor="IANA-ETHERTYPES"
           target="https://www.iana.org/assignments/ieee-802-numbers/">
  <front>
    <title>IEEE 802 Numbers: ETHER TYPES</title>
    <author><organization>IANA</organization></author>
  </front>
</reference>

<reference anchor="IANA-BGP-EXT-COMM"
           target="https://www.iana.org/assignments/bgp-extended-communities/">
  <front>
    <title>Border Gateway Protocol (BGP) Extended Communities</title>
    <author><organization>IANA</organization></author>
  </front>
</reference>

<reference anchor="IANA-SAFI"
           target="https://www.iana.org/assignments/safi-namespace/">
  <front>
    <title>Subsequent Address Family Identifiers (SAFI) Parameters</title>
    <author><organization>IANA</organization></author>
  </front>
</reference>
	&I-D.ietf-bess-evpn-inter-subnet-forwarding;
	&RFC4272;
	&RFC4364;
	&RFC5565;
	&RFC5640;
	&RFC8205;
	&RFC8277;
	&RFC5566;
	&RFC7510;
	&RFC5512;
	&RFC6514;
	&RFC8365;
	&RFC8402;
<!-->	&I-D.ietf-intarea-tunnels;-->

	</references>
    </references>
    <section title="Impact anchor="impact-on-8365" numbered="true" toc="default">
      <name>Impact on RFC 8365" anchor="impact-on-8365"> 8365</name>
      <t>
	<xref target="RFC8365"/> target="RFC8365" format="default"/> references RFC 5512 for its definition of
	the BGP Encapsulation Extended Community. That extended community is
	now defined in this document, in a way consistent with its previous
	definition.
      </t>
      <t>
	RFC 8365
	<xref target="RFC8365" section="6"/> talks in Section 6 about the use of the Encapsulation Extended
	Community to allow Network Virtualization Edge (NVE) devices (NVEs) to
	signal their supported encapsulations. We
	note that with the introduction of this specification, the Tunnel
	Encapsulation Attribute attribute can also be used for this purpose. For purposes
	where RFC 8365 talks about "advertising supported encapsulations" (for
	example, in the second paragraph of Section 6), <xref target="RFC8365" section="6" sectionFormat="bare"/>), encapsulations advertised
	using the Tunnel Encapsulation Attribute attribute should be considered equally with
	those advertised using the Encapsulation Extended Community.
      </t>
      <t>
	In particular, a review of Section 8.3.1 of RFC 8365 <xref target="RFC8365" section="8.3.1" /> is called for, to
	consider whether the introduction of the Tunnel Encapsulation Attribute attribute
	creates a need for any revisions to the split horizon split-horizon procedures.
      </t>
      <t>
	RFC 8365
	<xref target="RFC8365" format="default"/> also refers to a draft version of this specification in
	the final paragraph of section 5.1.3. Section <xref target="RFC8365" section="5.1.3" sectionFormat="bare" />. That paragraph references
	Section 8.2.2.2 of the draft. In this version of the document document, the correct reference
	would be <xref target="no-valid-vni"/>. target="no-valid-vni" format="default"/>. There are no substantive
	differences between the section in the referenced draft, draft version and that in
	this document.
      </t>
    </section>
    <section numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>
   This document contains text from RFC 5512, authored by <contact fullname="Pradosh Mohapatra"/> and <contact fullname="Eric Rosen"/>.  The authors of the current document wish to thank
   them for their contribution.  RFC 5512 itself built upon prior work by <contact fullname="Gargi Nalawade"/>, <contact fullname="Ruchi Kapoor"/>, <contact fullname="Dan Tappan"/>, <contact fullname="David Ward"/>, <contact fullname="Scott Wainner"/>, <contact fullname="Simon Barber"/>, <contact fullname="Lili Wang"/>, and <contact fullname="Chris Metz"/>, whom the authors also thank for their
   contributions. <contact fullname="Eric Rosen"/> was the principal author of earlier versions
   of this document.</t>
      <t>
   The authors wish to thank <contact fullname="Lou Berger"/>, <contact fullname="Ron Bonica"/>, <contact fullname="Martin Djernaes"/>,
   <contact fullname="John Drake"/>, <contact fullname="Susan Hares"/>, <contact fullname="Satoru Matsushima"/>, <contact fullname="Thomas Morin"/>, <contact fullname="Dhananjaya Rao"/>, <contact fullname="Ravi Singh"/>, <contact fullname="Harish Sitaraman"/>, <contact fullname="Brian Trammell"/>, <contact fullname="Xiaohu Xu"/>, and <contact fullname="Zhaohui Zhang"/> for their review, comments, and/or helpful discussions. <contact fullname="Alvaro Retana"/> provided an
   especially comprehensive review.</t>
    </section>
    <section numbered="false" toc="default">
      <name>Contributors</name>
      <t>
   Below is a list of other contributing authors in alphabetical order:</t>
<contact fullname="Randy Bush">
<organization>Internet Initiative Japan</organization>
      <address>
        <postal>
          <street>5147 Crystal Springs</street>
          <city>Bainbridge Island</city>
	  <region>WA</region>
	  <code>98110</code>
          <country>United States of America</country>
        </postal>
        <email>randy@psg.com </email>
      </address>
</contact>

<contact fullname="Robert Raszuk">
<organization>Bloomberg LP</organization>
      <address>
        <postal>
          <street>731 Lexington Ave</street>
          <city>New York City</city>
	  <region>NY</region>
	  <code>10022</code>
          <country>USA</country>
        </postal>
        <email>robert@raszuk.net</email>
      </address>
</contact>

<contact fullname="Eric C. Rosen"/>

    </section>

  </back>
</rfc>