IDR Working Group                                          E. Rosen, Ed.
Internet-Draft                                    Juniper Networks, Inc.
Updates:
Obsoletes: 5512 (if approved)                                   K. Patel
Intended status: Standards Track                           Cisco Systems
Expires: February 20, June 23, 2016                                   G. Van de Velde
                                                          Alcatel-Lucent
                                                         August 19,
                                                       December 21, 2015

      Using the

                 The BGP Tunnel Encapsulation Attribute without the BGP
                           Encapsulation SAFI
                    draft-ietf-idr-tunnel-encaps-00
                    draft-ietf-idr-tunnel-encaps-01

Abstract

   RFC 5512 defines a BGP Path Attribute known as the "Tunnel
   Encapsulation Attribute".  This attribute allows one to specify a set
   of tunnels.  For each such tunnel, the attribute can provide
   additional the
   information used needed to create a the tunnel and the corresponding
   encapsulation header, and header.  The attribute can also provide information
   that aids in choosing whether a particular packet is to be sent
   through a particular tunnel.  RFC 5512 states that the attribute is
   only carried in BGP UPDATEs that have the "Encapsulation Subsequent
   Address Family (Encapsulation SAFI)".  This document updates RFC 5512
   by deprecating deprecates the
   Encapsulation SAFI (which has never been used),and
   by specifying used), and specifies
   semantics for the attribute when it is carried in UPDATEs of certain
   other SAFIs.  This document also extends the
   attribute by enabling it to carry additional information needed to
   create the encapsulation headers adds support for additional tunnel types not
   mentioned in RFC 5512.  Finally, this document also extends the
   attribute by allowing it to specify types,
   and allows a remote tunnel endpoint address to be specified for each
   tunnel.  This document also provides support for specifying fields of
   any inner or outer encapsulations that may be used by a particular
   tunnel.

   This document obsoletes RFC 5512.

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Tunnel Encapsulation Attribute Sub-TLVs
     1.1.  Brief Summary of RFC 5512 . . . . . . . . . . .   5
     2.1.  The Remote Endpoint Sub-TLV . . . . .   4
     1.2.  Deficiencies in RFC 5512  . . . . . . . . . .   5
     2.2.  Encapsulation Sub-TLVs for Particular Tunnel Types . . .   8
       2.2.1.  VXLAN . . .   4
     1.3.  Brief Summary of Changes from RFC 5512  . . . . . . . . .   5
   2.  The Tunnel Encapsulation Attribute  . . . . . . . . . . . . .   6
   3.  Tunnel Encapsulation Attribute Sub-TLVs .   8
       2.2.2.  VXLAN-GPE . . . . . . . . . .   7
     3.1.  The Remote Endpoint Sub-TLV . . . . . . . . . . . .   9
       2.2.3.  NVGRE . . .   7
     3.2.  Encapsulation Sub-TLVs for Particular Tunnel Types  . . .  10
       3.2.1.  VXLAN . . . . . . . . . . . . . . . . . .  10
       2.2.4.  GTP . . . . . .  10
       3.2.2.  VXLAN-GPE . . . . . . . . . . . . . . . . . . .  11
       2.2.5.  MPLS-in-GRE . . .  11
       3.2.3.  NVGRE . . . . . . . . . . . . . . . . . .  12
     2.3.  Outer Encapsulation Sub-TLVs . . . . . .  12
       3.2.4.  L2TPv3  . . . . . . . .  13
       2.3.1.  IPv4 DS Field . . . . . . . . . . . . . . .  13
       3.2.5.  GTP . . . . .  13
       2.3.2.  UDP Destination Port . . . . . . . . . . . . . . . .  13
     2.4.  Embedded Label Handling Sub-TLV . . . .  14
       3.2.6.  GRE . . . . . . . . .  14
   3.  Tunnel Encapsulation Extended Community . . . . . . . . . . .  15
   4.  Semantics and Usage of the Tunnel Encapsulation
       attribute . . . . .  15
       3.2.7.  MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . .  15
   5.  Routing Considerations
     3.3.  Outer Encapsulation Sub-TLVs  . . . . . . . . . . . . . .  16
       3.3.1.  IPv4 DS Field . . . . .  18
     5.1.  No Impact on BGP Decision Process . . . . . . . . . . . .  18
     5.2.  Looping, Infinite Stacking, Etc. . . .  17
       3.3.2.  UDP Destination Port  . . . . . . . . .  19
   6.  Recursive Next Hop Resolution . . . . . . .  17
     3.4.  Sub-TLVs for Aiding Tunnel Selection  . . . . . . . . .  19
   7.  Use of Virtual Network Identifiers and Embedded Labels
       when Imposing a Tunnel Encapsulation .  17
       3.4.1.  Protocol Type Sub-TLV . . . . . . . . . . .  20
     7.1.  Unlabeled Address Families . . . . .  17
       3.4.2.  Color Sub-TLV . . . . . . . . . .  20
     7.2.  Labeled Address Families . . . . . . . . . .  18
     3.5.  Embedded Label Handling Sub-TLV . . . . . .  21
       7.2.1.  When a Valid VNI has been Signaled . . . . . . .  18
     3.6.  MPLS Label Stack Sub-TLV  . .  21
       7.2.2.  When a Valid VNI has not been Signaled . . . . . . .  22
       7.2.3.  Applicability Restrictions . . . . . . .  19
     3.7.  Prefix-SID Sub-TLV  . . . . . .  22
   8.  Scoping . . . . . . . . . . . . .  20
   4.  Extended Communities Related to the Tunnel Encapsulation
       Attribute . . . . . . . . . . . . . .  23
   9.  Error Handling . . . . . . . . . . . .  21
     4.1.  Encapsulation Extended Community  . . . . . . . . . . .  23
   10. IANA Considerations .  21
     4.2.  Router's MAC Extended Community . . . . . . . . . . . . .  22
     4.3.  Color Extended Community  . . . . . . .  24
   11. Security Considerations . . . . . . . . .  22

   5.  Semantics and Usage of the Tunnel Encapsulation
       attribute . . . . . . . . . .  25
   12. Acknowledgments . . . . . . . . . . . . . . . .  22
   6.  Routing Considerations  . . . . . . .  26
   13. Contributor Addresses . . . . . . . . . . . .  26
     6.1.  No Impact on BGP Decision Process . . . . . . . . . . . .  26
   14. References
     6.2.  Looping, Infinite Stacking, Etc.  . . . . . . . . . . . .  26
   7.  Recursive Next Hop Resolution . . . . . . . . . . . . . . . .  27
     14.1.  Normative References
   8.  Use of Virtual Network Identifiers and Embedded Labels
       when Imposing a Tunnel Encapsulation  . . . . . . . . . . . .  28
     8.1.  Tunnel Types without a Virtual Network Identifier
           Field . . . . . . . . .  27
     14.2.  Informative References . . . . . . . . . . . . . . . . .  27
   Authors' Addresses  28
     8.2.  Tunnel Types with a Virtual Network Identifier Field  . .  28
       8.2.1.  Unlabeled Address Families  . . . . . . . . . . . . .  29
       8.2.2.  Labeled Address Families  . . . . . . . . . . . . . .  29

1.  Introduction

   [RFC5512] defines
         8.2.2.1.  When a BGP Path Attribute known as the Tunnel
   Encapsulation attribute.  This attribute consists of one or more
   TLVs.  Each TLV identifies Valid VNI has been Signaled  . . . . . . .  29
         8.2.2.2.  When a particular type of tunnel.  Each TLV
   also contains one or more sub-TLVs.  Some of the sub-TLVs, e.g., the
   "Encapsulation sub-TLV", contain information that may be used to form
   the encapsulation header for the specified tunnel type.  Other sub-
   TLVs, e.g., the Valid VNI has not been Signaled  . . . . .  30
   9.  Applicability Restrictions  . . . . . . . . . . . . . . . . .  30
   10. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . .  31
   11. Error Handling  . . . . . . . . . . . . . . . . . . . . . . .  31
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  33
     12.1.  Subsequent Address Family Identifiers  . . . . . . . . .  33
     12.2.  BGP Path Attributes  . . . . . . . . . . . . . . . . . .  33
     12.3.  Extended Communities . . . . . . . . . . . . . . . . . .  33
     12.4.  BGP Tunnel Encapsulation Attribute Sub-TLVs  . . . . . .  33
     12.5.  Tunnel Types . . . . . . . . . . . . . . . . . . . . . .  34
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  34
   14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  35
   15. Contributor Addresses . . . . . . . . . . . . . . . . . . . .  36
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  36
     16.1.  Normative References . . . . . . . . . . . . . . . . . .  36
     16.2.  Informative References . . . . . . . . . . . . . . . . .  37
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  39

1.  Introduction

   This document obsoletes RFC 5512.  The deficiencies of RFC 5512, and
   a summary of the changes made, are discussed in Sections 1.1-1.3.
   The material from RFC 5512 that is retained has been incorporated
   into this document.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL", when and only when appearing in all capital letters, are
   to be interpreted as described in [RFC2119].

1.1.  Brief Summary of RFC 5512

   [RFC5512] defines a BGP 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, e.g., the
   "Encapsulation sub-TLV", contain information that may be used to form
   the encapsulation header for the specified tunnel type.  Other sub-
   TLVs, e.g., the "color sub-TLV" and the "protocol sub-TLV", contain
   information "protocol sub-TLV", contain
   information that aids in determining whether particular packets
   should be sent through the tunnel that the TLV identifies.

   [RFC5512] only allows the Tunnel Encapsulation attribute to be
   attached to BGP UPDATE messages that have the "Encapsulation SAFI"
   (i.e., UPDATE messages with AFI/SAFI 1/7 or 2/7).  In an UPDATE of
   the Encapsulation SAFI, the NLRI is an address of the BGP speaker
   originating the UPDATE.  Consider the following scenario:

   o  BGP speaker R1 has received and installed UPDATE U;

   o  UPDATE U's SAFI is the Encapsulation SAFI;

   o  UPDATE U has the address R2 as its NLRI;

   o  UPDATE U has a Tunnel Encapsulation attribute.

   o  R1 has a packet, P, to transmit to destination D;

   o  R1's best path to D is a BGP route that has R2 as its next hop;

   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 remote endpoint of
   each such tunnel is R2.  Packet P is known as the tunnel's "payload".

1.2.  Deficiencies in RFC 5512

   While the ability to specify tunnel information in a BGP UPDATE is
   useful, the procedures of [RFC5512] have certain limitations:

   o  The requirement to use the "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.

   o  There is no way to use the Tunnel Encapsulation attribute to
      specify the remote endpoint address of a given tunnel; [RFC5512]
      assumes that the remote endpoint of each tunnel is specified as
      the NLRI of an UPDATE of the Encapsulation-SAFI.

   o  If the respective best paths to two different address prefixes
      have the same next hop, [RFC5512] does not provide a
      straightforward method to associate each prefix with a different
      tunnel.

   o  If a particular 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.

1.3.  Brief Summary of Changes from RFC 5512

   In this document we address these deficiencies by:

   o  Deprecating the Encapsulation SAFI.

   o  Defining a new "Remote Endpoint Address sub-TLV" 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.

   o  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.

   o  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.

   One of the sub-TLVs defined in [RFC5512] 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
   [RFC5512]: VXLAN, VXLAN-GPE, NVGRE, GTP, and MPLS-in-GRE.  MPLS-in-
   UDP [RFC7510] is also supported, but an Encapsulation sub-TLV for it
   is not needed.

   Some of the encapsulations mentioned in the previous paragraph need
   to be further encapsulated inside UDP and/or IP.  [RFC5512] 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.

   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 field.

   [RFC5512] defines a Tunnel Encapsulation Extended Community, that can
   be used instead of the Tunnel Encapsulation attribute under certain
   circumstances.  This document addresses the issue of how to handle a
   BGP UPDATE that carries both a Tunnel Encapsulation attribute and one
   or more Tunnel Encapsulation Extended Communities.

2.  The Tunnel Encapsulation Attribute

   The Tunnel Encapsulation attribute is an optional transitive BGP Path
   attribute.  IANA has assigned the value 23 as the type code of the
   attribute.  The attribute is composed of a set of Type-Length-Value
   (TLV) encodings.  Each TLV contains information corresponding to a
   particular tunnel type.  A TLV is structured as follows:

      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)     |        Length (2 Octets)      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                             Value                             |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 1: Tunnel Encapsulation TLV Value Field

   o  Tunnel Type (2 octets): identifies a type of tunnel.  The field
      contains values from the IANA Registry "BGP Tunnel Encapsulation
      Attribute Tunnel Types".

      Note that for tunnel types whose names are of the form "X-in-Y",
      e.g., "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 "Y" and including in its
      TLV a Protocol Type sub-TLV (see Section 3.4.1 specifying protocol
      "X".

   o  Length (2 octets): the total number of octets of the value field.

   o  Value (variable): comprised of multiple sub-TLVs.

   Each sub-TLV consists of three fields: a 1-octet type, 1-octet
   length, and zero or more octets of value.  A sub-TLV is structured as
   follows:

                   +-----------------------------------+
                   |      Sub-TLV Type (1 Octet)       |
                   +-----------------------------------+
                   |     Sub-TLV Length (1 Octet)      |
                   +-----------------------------------+
                   |     Sub-TLV Value (Variable)      |
                   |                                   |
                   +-----------------------------------+

               Figure 2: Tunnel Encapsulation Sub-TLV Format

   o  Sub-TLV Type (1 octet): each sub-TLV type defines a certain
      property about the tunnel TLV that contains this sub-TLV.

   o  Sub-TLV Length (1 octet): the total number of octets of the sub-
      TLV value field.

   o  Sub-TLV Value (variable): encodings of the value field depend on
      the sub-TLV type as enumerated above.  The following sub-sections
      define the encoding in detail.

3.  Tunnel Encapsulation Attribute Sub-TLVs

   In this section, we specify a number of sub-TLVs.  These sub-TLVs can
   be included in a TLV of the Tunnel Encapsulation attribute.

3.1.  The Remote Endpoint Sub-TLV

   The Remote Endpoint sub-TLV is a sub-TLV whose value field contains
   three sub-fields:

   1.  a four-octet Autonomous System (AS) number sub-field

   2.  a two-octet Address Family sub-field

   3.  an address sub-field, whose length depends upon the Address
       Family.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Autonomous System Number                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Address Family           |           Address             ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
     ~                                                               ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 3: Remote Endpoint Sub-TLV Value Field

   The Address Family subfield contains a value from IANA's "Address
   Family Numbers" registry.  In this document, we assume that the
   Address Family is either IPv4 or IPv6; use of other address families
   is outside the scope of this document.

   If the Address Family subfield contains the value for IPv4, the
   address subfield must contain an IPv4 address (a /32 IPv4 prefix).
   In this case, the length field of Remote Endpoint sub-TLV must
   contain the value 10 (0xa).  IPv4 broadcast addresses are not valid
   values of this field.

   If the Address Family subfield contains the value for IPv6, the
   address sub-field must contain an IPv6 address (a /128 IPv6 prefix).
   In this case, the length field of Remote Endpoint sub-TLV must
   contain the value 22 (0x16).  IPv6 link local addresses are not valid
   values of the IP address field.

   In a given BGP UPDATE, the address family (IPv4 or IPv6) of a Remote
   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 Remote Endpoint sub-
   TLVs that contain IPv6 addresses.  Also, different tunnels
   represented in the Tunnel Encapsulation attribute may have Remote
   Endpoints of different address families.

   A two-octet AS number can be carried in the AS number field by
   setting the two high order octets to zero, and carrying the number in
   the two low order octets of the field.

   The AS number in the sub-TLV MUST be the number of the AS to which
   the IP address in the sub-TLV belongs.

   There is one special case: the Remote Endpoint sub-TLV MAY have a
   value field whose Address Family subfield contains 0.  This means
   that the tunnel's remote endpoint is the UPDATE's BGP next hop.  If
   the Address Family subfield contains 0, the Address subfield is
   omitted, and the Autonomous System number field is set to 0.

   If any of the following conditions hold, the Remote Endpoint sub-TLV
   is considered to be "malformed":

   o  The sub-TLV contains the value for IPv4 in its Address Family
      subfield, but the length of the sub-TLV's value field is other
      than 10 (0xa).

   o  The sub-TLV contains the value for IPv6 in its Address Family
      subfield, but the length of the sub-TLV's value field is other
      than 22 (0x16).

   o  The sub-TLV contains the value zero in its Address Family field,
      but the length of the sub-TLV's value field is other than 6, or
      the Autonomous System subfield is not set to zero.

   o  The IP address in the sub-TLV's address subfield is not a valid IP
      address (e.g., it's an IPv4 broadcast address).

   o  It can be determined that aids the IP address in determining whether particular packets
   should the sub-TLV's address
      subfield does not belong to the non-zero AS whose number is in the
      its Autonomous System subfield.  (See section Section 13 for
      discussion of one way to determine this.)

   If the Remote Endpoint sub-TLV is malformed, the TLV containing it is
   also considered to be malformed, and the entire TLV MUST be ignored.
   However, the Tunnel Encapsulation attribute SHOULD NOT be considered
   to be malformed in this case; other TLVs in the attribute SHOULD be
   processed (if they can be parsed correctly).

   When redistributing a route that is carrying a Tunnel Encapsulation
   attribute containing a TLV that itself contains a malformed Remote
   Endpoint sub-TLV, the TLV SHOULD be removed from the attribute before
   redistribution.

   See Section 11 for further discussion of how to handle errors that
   are encountered when parsing the Tunnel Encapsulation attribute.

   If the Remote Endpoint sub-TLV contains an IPv4 or IPv6 address that
   is valid but not reachable, the sub-TLV is NOT considered to be sent through
   malformed, and the containing TLV SHOULD NOT be removed from the
   attribute before redistribution.  However, the tunnel that identified by
   the TLV identifies.

   [RFC5512] only allows containing that sub-TLV cannot be used until such time as the
   address becomes reachable.  See Section 5.

3.2.  Encapsulation Sub-TLVs for Particular Tunnel Types

   This section defines Tunnel Encapsulation attribute to be
   attached to BGP UPDATE messages that have sub-TLVs for the "Encapsulation SAFI"
   (i.e., UPDATE messages with AFI/SAFI 1/7 or 2/7).  In an UPDATE of following
   tunnel types: VXLAN ([RFC7348]), VXLAN-GPE ([VXLAN-GPE]), NVGRE
   ([RFC7637]), GTP ([GTP-U]), MPLS-in-GRE ([RFC2784], [RFC2890],
   [RFC4023]), L2TPv3 ([RFC3931]), and GRE ([RFC2784], [RFC2890],
   [RFC4023]).

   Rules for forming the Encapsulation SAFI, encapsulation based on the NLRI information in a
   given TLV are given in Section 8.  For some tunnel types, the rules
   are obvious and not mentioned in this document.  There are also
   tunnel types for which it is not necessary to define an address of the BGP speaker
   originating Encapsulation
   sub-TLV.

3.2.1.  VXLAN

   This document defines an encapsulation sub-TLV for VXLAN tunnels.
   When the UPDATE.  Consider tunnel type is VXLAN, the following scenario:

   o  BGP speaker R1 has received and installed UPDATE U;

   o  UPDATE U's SAFI is the Encapsulation SAFI;

   o  UPDATE U has structure of the address R2 as its NLRI;

   o  UPDATE U has a Tunnel
   value field in the encapsulation sub-TLV:

      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)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 MAC Address (4 Octets)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  MAC Address (2 Octets)       |          Reserved             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 4: VXLAN Encapsulation attribute.

   o  R1 has a packet, P, to transmit Sub-TLV

      V: This bit is set to destination D;

   o  R1's best path 1 to D is a BGP route indicate that has R2 as its next hop;

   In this scenario, when R1 transmits packet P, it should transmit it
   to R2 through one of the tunnels specified a "valid" VN-ID is
      present in U's Tunnel
   Encapsulation attribute.  The IP address of the remote endpoint of
   each such tunnel encapsulation sub-TLV.  Please see Section 8.

      M: This bit is R2.  Packet P set to 1 to indicate that a valid MAC Address is known as
      present in the tunnel's "payload".

   While encapsulation sub-TLV.

      R: The remaining bits in the ability 8-bit flags field are reserved for
      further use.  They SHOULD always be set to specify tunnel information in 0.

      VN-ID: If the V bit is set, the VN-id field contains a BGP UPDATE 3 octet VN-
      ID value.  If the V bit is
   useful, not set, the procedures of [RFC5512] have certain limitations:

   o  The requirement VN-id field SHOULD be set
      to use zero.

      MAC Address: If the "Encapsulation SAFI" presents an
      unfortunate operational cost, as each BGP session that may need M bit is set, this field contains a 6 octet
      Ethernet MAC address.  If the M bit is not set, this field SHOULD
      be set to all zeroes.

   Note that, strictly speaking, VXLAN tunnels only carry tunnel encapsulation information needs to be reconfigured ethernet
   frames.  To send an IP packet or an MPLS packet through a VXLAN
   tunnel, it is necessary to
      support form an IP-in-ethernet-in-VXLAN or an
   MPLS-in-ethernet-in-VXLAN tunnel.

   When forming the Encapsulation SAFI. VXLAN encapsulation header:

   o  The Encapsulation SAFI has never
      been used, and this requirement has served only to discourage the
      use values of the Tunnel Encapsulation attribute.

   o  There is no way to use the Tunnel Encapsulation attribute to
      specify V, M, and R bits are NOT copied into the remote endpoint address flags
      field of a given tunnel; [RFC5512]
      assumes that the remote endpoint VXLAN header.  The flags field of each tunnel the VXLAN header is specified
      set as
      the NLRI of an UPDATE of the Encapsulation-SAFI. per [RFC7348].

   o  If the respective best paths to two different address prefixes
      have M bit is set, the same next hop, [RFC5512] does not provide a
      straightforward method to associate each prefix with a different
      tunnel.

   In this document we address these deficiencies by:

   o  Deprecating MAC Address is copied into the Encapsulation SAFI.

   o  Defining a new "Remote Endpoint Inner
      Destination MAC Address sub-TLV" that can be
      included in any field of the TLVs contained in Inner Ethernet Header (see
      section 5 of [RFC7348].

      If the Tunnel Encapsulation
      attribute.  This sub-TLV can be used to specify M bit is not set, and the remote
      endpoint address of a particular tunnel.

   o  Allowing payload being sent through the Tunnel Encapsulation attribute to be carried by BGP
      UPDATEs of additional AFI/SAFIs.  Appropriate semantics are
      provided for this way of using
      VXLAN tunnel is an ethernet frame, the attribute.

   One Destination MAC Address
      field of the sub-TLVs defined in [RFC5512] Inner Ethernet Header is just the "Encapsulation sub-
   TLV".  For a given tunnel, the encapsulation sub-TLV specifies some Destination MAC
      Address field of the information needed to construct payload's ethernet header.

      If the encapsulation header used
   when sending packets through that tunnel.  This document defines
   encapsulation sub-TLVs for a number of tunnel types M bit is not discussed in
   [RFC5512]: VXLAN, VXLAN-GPE, NVGRE, GTP, set, and MPLS-in-GRE.  MPLS-in-
   UDP [RFC7510] the payload being sent through the
      VXLAN tunnel is also supported, but an Encapsulation sub-TLV for it
   is not needed.

   Some of the encapsulations mentioned in IP or MPLS packet, the previous paragraph need Inner Destination MAC
      address field is set to be further encapsulated inside UDP and/or IP.  [RFC5512] provides a configured value; if there is no way
      configured value, the VXLAN tunnel cannot be used.

   o  See Section 8 to specify that certain information see how the VNI field of the VXLAN encapsulation
      header is to appear in these
   outer IP and/or UDP encapsulations. set.

3.2.2.  VXLAN-GPE

   This document provides a
   framework defines an encapsulation sub-TLV for including such information in the TLVs of the Tunnel
   Encapsulation attribute. VXLAN tunnels.
   When the Tunnel Encapsulation attribute tunnel type is attached to a BGP UPDATE
   whose AFI/SAFI identifies one of VXLAN-GPE, the labeled address families, it following is
   not always obvious whether the label embedded in structure of
   the NLRI is to
   appear somewhere value field in the tunnel encapsulation header (and if so,
   where), or whether it sub-TLV:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Ver|V|R|R|R|R|R|                 Reserved                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       VN-ID                   |   Reserved    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 5: VXLAN GPE Encapsulation Sub-TLV

      V: This bit is set to appear 1 to indicate that a "valid" VN-ID is
      present in the payload, or whether it can encapsulation sub-TLV.  Please see Section 8.

      R: The bits designated "R" above are reserved for future use.
      They SHOULD always be omitted altogether.  This set to zero.

      Version (Ver): Indicates VXLAN GPE protocol version.  If the
      indicated version is especially true if not supported, the TLV that contains this
      Encapsulation sub-TLV MUST be treated as specifying an unsupported
      tunnel type.  The value of this field will be copied into the
      corresponding field of the VXLAN encapsulation header itself header.

      VN-ID: If the V bit is set, this field contains a "virtual network identifier".
   This document provides a mechanism that allows one to signal (by
   using sub-TLVs of 3 octet VN-ID
      value.  If the Tunnel Encapsulation attribute) how one wants V bit is not set, this field SHOULD be set to use the embedded label when zero.

   When forming the tunnel VXLAN-GPE encapsulation has its own
   virtual network identifier field.

   [RFC5512] defines a Tunnel Encapsulation Extended Community, that can
   be used instead header:

   o  The values of the Tunnel Encapsulation attribute under certain
   circumstances.  This document addresses the issue of how to handle a
   BGP UPDATE that carries both a Tunnel Encapsulation attribute and one
   or more Tunnel Encapsulation Extended Communities.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL", when V and only when appearing in all capital letters, R bits are
   to be interpreted as described in [RFC2119].

2.  Tunnel Encapsulation Attribute Sub-TLVs

   [RFC5512] specifies three sub-TLVs for the Tunnel Encapsulation
   attribute: NOT copied into the Encapsulation sub-TLV, flags field
      of the Color sub-TLV, and VXLAN-GPE header.  However, the
   Protocol Type sub-TLV.  In this section we specify a number of
   additional sub-TLVs.  We also specify Encapsulation sub-TLVs for a
   number values of tunnel types that the Ver bits are not mentioned
      copied into the VXLAN-GPE header.  Other bits in [RFC5512].

2.1.  The Remote Endpoint Sub-TLV

   The Remote Endpoint sub-TLV the flags field
      of the VXLAN-GPE header are set as per [VXLAN-GPE].

   o  See Section 8 to see how the VNI field of the VXLAN-GPE
      encapsulation header is a set.

3.2.3.  NVGRE

   This document defines an encapsulation sub-TLV whose for NVGRE tunnels.
   When the tunnel type is NVGRE, the following is the structure of the
   value field contains
   three sub-fields:

   1.  a four-octet Autonomous System (AS) number sub-field

   2.  a two-octet Address Family sub-field

   3.  an address sub-field, whose length depends upon in the Address
       Family. encapsulation sub-TLV:

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Autonomous System Number
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |V|M|R|R|R|R|R|R|          VN-ID (3 Octets)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 MAC Address Family (4 Octets)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  MAC Address             ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      ~                                                             ~ (2 Octets)       |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 1: Remote Endpoint 6: NVGRE Encapsulation Sub-TLV Value Field

   The Address Family subfield contains a value from IANA's "Address
   Family Numbers" registry.  In this document, we assume

      V: This bit is set to 1 to indicate that a "valid" VN-ID is
      present in the
   Address Family encapsulation sub-TLV.  Please see Section 8.

      M: This bit is either IPv4 or IPv6; use of other address families set to 1 to indicate that a valid MAC Address is outside the scope of this document.

   If
      present in the Address Family subfield contains encapsulation sub-TLV.

      R: The remaining bits in the value 8-bit flags field are reserved for IPv4,
      further use.  They SHOULD always be set to 0.

      VN-ID: If the
   address subfield must contain an IPv4 address (a /32 IPv4 prefix).
   In this case, V bit is set, the length VN-id field of Remote Endpoint sub-TLV must
   contain contains a 3 octet VN-
      ID value.  If the value 10 (0xa).  IPv4 broadcast addresses are V bit is not valid
   values of this field. set, the VN-id field SHOULD be set
      to zero.

      MAC Address: If the Address Family subfield M bit is set, this field contains a 6 octet
      Ethernet MAC address.  If the value for IPv6, the
   address sub-field must contain an IPv6 address (a /128 IPv6 prefix).
   In M bit is not set, this case, the length field of Remote Endpoint sub-TLV must
   contain SHOULD
      be set to all zeroes.

   When forming the value 22 (0x16).  IPv6 link local addresses are not valid NVGRE encapsulation header:

   o  The values of the IP address field.

   In a given BGP UPDATE, V, M, and R bits are NOT copied into the address family (IPv4 or IPv6) of a Remote
   Endpoint sub-TLV is independent flags
      field of the address family NVGRE header.  The flags field of the UPDATE
   itself.  For example, an UPDATE whose NLRI VXLAN header is an IPv4 address may
   have a Tunnel Encapsulation attribute containing Remote Endpoint sub-
   TLVs that contain IPv6 addresses.  Also, different tunnels
   represented in
      set as per [RFC7637].

   o  If the Tunnel Encapsulation attribute may have Remote
   Endpoints of different address families.

   A two-octet AS number can be carried in M bit is set, the AS number MAC Address is copied into the Inner
      Destination MAC Address field by
   setting of the two high order octets to zero, Inner Ethernet Header (see
      section 3.2 of [RFC7637].

      If the M bit is not set, and carrying the number in payload being sent through the two low order octets of
      NVGRE tunnel is an ethernet frame, the field.

   The AS number in Destination MAC Address
      field of the sub-TLV MUST be Inner Ethernet Header is just the number Destination MAC
      Address field of the AS to which payload's ethernet header.

      If the IP address in M bit is not set, and the sub-TLV belongs.

   There payload being sent through the
      NVGRE tunnel is one special case: an IP or MPLS packet, the Remote Endpoint sub-TLV MAY have Inner Destination MAC
      address field is set to a
   value configured value; if there is no
      configured value, the NVGRE tunnel cannot be used.

   o  See Section 8 to see how the VSID field whose Address Family subfield contains 0.  This means
   that of the tunnel's remote endpoint NVGRE encapsulation
      header is set.

3.2.4.  L2TPv3

   When the UPDATE's BGP next hop.  If tunnel type of the Address Family subfield contains 0, TLV is L2TPv3 over IP, the Address subfield following is
   omitted, and
   the Autonomous System number structure of the value field is set of the encapsulation sub-TLV:

      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)                      |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 7: L2TPv3 Encapsulation Sub-TLV

      Session ID: a non-zero 4-octet value locally assigned by the
      advertising router that serves as a lookup key in the incoming
      packet's context.

      Cookie: an optional, variable length (encoded in octets -- 0 to 0.

   If any 8
      octets) value used by L2TPv3 to check the association of a
      received data message with the following conditions hold, session identified by the Remote Endpoint sub-TLV
   is considered to be "malformed":

   o  The sub-TLV contains Session
      ID.  Generation and usage of the cookie value for IPv4 is as specified in its Address Family
      subfield, but the
      [RFC3931].

      The length of the sub-TLV's value field cookie is other
      than 10 (0xa).

   o  The sub-TLV contains the value for IPv6 in its Address Family
      subfield, not encoded explicitly, but the can be
      calculated as (sub-TLV length of - 4).

3.2.5.  GTP

   When the sub-TLV's value field tunnel type is other
      than 22 (0x16).

   o  The GTP [GTP-U], the Encapsulation sub-TLV
   contains information needed to send data packets through a GTP
   tunnel, and also contains information needed by the value zero in its Address Family field,
      but tunnel's remote
   endpoint to create a "reverse" tunnel back to the length transmitter.  This
   allows a bidirectional control connection to be created.  The format
   of the sub-TLV's value field is other than 6, or Encapsulation Sub-TLV is:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Remote TEID (4 Octets)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Local TEID (4 Octets)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Local Endpoint Address (4/16 Octets (IPv4/IPv6))        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 8: GTP Encapsulation Sub-TLV

      Remote TEID: Contains the Autonomous System subfield is not set 32-bit Tunnel Endpoint Identifier of the
      GTP tunnel through which data packets are to zero.

   o  The IP address be sent.  When data
      packets are sent through the tunnel, the Remote TEID is carried in
      the sub-TLV's address subfield GTP encapsulation header.  The GTP header is not a valid IP
      address (e.g., it's itself
      encapsulation within an IPv4 broadcast address).

   o  It can be determined that the IP address in the sub-TLV's address
      subfield does not belong to the non-zero AS header, whose number IP destination address
      field is in set to the
      its Autonomous System subfield.  (See section Section 11 for
      discussion value of one way to determine this.)

   If the Remote Endpoint sub-TLV is malformed, the TLV containing it sub-TLV.

      Local TEID: Contains a 32-bit Tunnel Endpoint Identifier of a GTP
      tunnel assigned by EPC ([vEPC]).

      Local Endpoint Address: Contains an IPv4 or IPv6 anycast address.
      This is
   also considered to be malformed, and the entire TLV MUST be ignored.
   However, used, along with the Tunnel Encapsulation attribute SHOULD NOT be considered Local TEID, to be malformed in this case; other TLVs set up a tunnel in the attribute SHOULD be
   processed (if they can be parsed correctly).
      reverse direction.  See [vEPC] for details.

3.2.6.  GRE

   When redistributing a route that is carrying a Tunnel Encapsulation
   attribute containing a TLV that itself contains a malformed Remote
   Endpoint sub-TLV, the tunnel type of the TLV SHOULD be removed from is GRE, the attribute before
   redistribution.

   See Section 9 for further discussion following is the
   structure of how to handle errors that are
   encountered when parsing the Tunnel value field of the encapsulation sub-TLV:

      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)                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 9: GRE Encapsulation attribute.

   If the Remote Endpoint sub-TLV contains an IPv4 or IPv6 address Sub-TLV

      GRE Key: 4-octet field [RFC2890] that is valid but not reachable, generated by the sub-TLV
      advertising router.  The actual method by which the key is NOT considered to be
   malformed, and
      obtained is beyond the containing TLV SHOULD NOT be removed from scope of this document.  The key is
      inserted into the
   attribute before redistribution.  However, GRE encapsulation header of the tunnel identified payload packets
      sent by ingress routers to the TLV containing that sub-TLV cannot advertising router.  It is intended
      to be used until such time as the
   address becomes reachable.  See Section 4.

2.2.  Encapsulation Sub-TLVs for Particular Tunnel Types

   Tunnel Encapsulation sub-TLVs for the following tunnel types are
   defined in [RFC5512]: L2TPv3, and GRE.

   This section defines Tunnel Encapsulation sub-TLVs for the following
   tunnel types: VXLAN ([RFC7348]), VXLAN-GPE ([VXLAN-GPE]), NVGRE
   ([NVGRE]), GTP [GTP-U], and MPLS-in-GRE ([RFC2784], [RFC2890],
   [RFC4023]).

   Rules for forming identifying extra context information about the encapsulation based on
      received payload.

      Note that the information in key is optional.  Unless a
   given TLV are given in Section 7.

2.2.1.  VXLAN

   This document defines an key value is being
      advertised, the GRE encapsulation sub-TLV for VXLAN tunnels. MUST NOT be present.

3.2.7.  MPLS-in-GRE

   When the tunnel type is VXLAN, MPLS-in-GRE, the following is the structure
   of the value field in the an optional encapsulation sub-TLV:

      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)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 MAC Address                       GRE-Key (4 Octets)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MAC Address (2 Octets)     |   Reserved                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 2: VXLAN 10: MPLS-in-GRE Encapsulation Sub-TLV

      V: This bit is set to 1 to indicate

      GRE-Key: 4-octet field [RFC2890] that a valid VN-ID is present
      in generated by the
      advertising router.  The actual method by which the key is
      obtained is beyond the scope of this document.  The key is
      inserted into the GRE encapsulation sub-TLV.

      M: This bit is set header of the payload packets
      sent by ingress routers to 1 the advertising router.  It is intended
      to indicate be used for identifying extra context information about the
      received payload.  Note that the key is optional.  Unless a valid MAC Address key
      value is
      present in being advertised, the MPLS-in-GRE encapsulation sub-TLV.

      R: The remaining bits in sub-TLV
      MUST NOT be present.

   Note that the 8-bit flags field are reserved for
      further use.  They SHOULD always GRE tunnel type defined in Section 3.2.6 can be set to 0.

      VN-ID: If used
   instead of the V bit MPLS-in-GRE tunnel type when it is set, the VN-id field contains necessary to
   encapsulate MPLS in GRE.  Including a 3 octet VN-
      ID value.  If TLV of the V bit MPLS-in-GRE tunnel
   type is not set, the VN-id field SHOULD be set equivalent to zero.

      MAC Address: If including a TLV of the M bit is set, this field contains GRE tunnel type that
   also includes a 6 octet
      Ethernet MAC address.  If Protocol Type sub-TLV ([RFC5512]) specifying MPLS as
   the M bit protocol to be encapsulated.  That is, if a TLV specifies MPLS-
   in-GRE or if it includes a Protocol Type sub-TLV specifying MPLS, the
   GRE tunnel advertised in that TLV MUST NOT be used for carrying IP
   packets.

   While it is not set, this field SHOULD
      be set really necessary to all zeroes.

   Note that, strictly speaking, VXLAN tunnels only carry ethernet
   frames.  To send an IP packet or an MPLS packet through have both the GRE and MPLS-in-GRE
   tunnel types, both are included for reasons of backwards
   compatibility.

3.3.  Outer Encapsulation Sub-TLVs

   The Encapsulation sub-TLV for a VXLAN
   tunnel, it is necessary particular tunnel type allows one to form an IP-in-ethernet-in-VXLAN or an
   MPLS-in-ethernet-in-VXLAN tunnel.

   When forming
   specify the VXLAN encapsulation header:

   o  The values of the V, M, and R bits that are NOT copied into the flags
      field to be placed in certain fields of the VXLAN header.
   encapsulation header for that tunnel type.  However, some tunnel
   types require an outer IP encapsulation, and some also require an
   outer UDP encapsulation.  The flags field Encapsulation sub-TLV for a given
   tunnel type does not usually provide a way to specify values for
   fields of the VXLAN header is
      set as per [RFC7348].

   o outer IP and/or UDP encapsulations.  If the M bit is set, the MAC Address it is copied into the Inner
      Destination MAC Address field necessary
   to specify values for fields of the Inner Ethernet Header (see
      section 5 of [RFC7348]. outer encapsulation, additional
   sub-TLVs must be used.  This document defines two such sub-TLVs.

   If the M bit is an outer encapsulation sub-TLV occurs in a TLV for a tunnel type
   that does not set, and use the payload being sent through corresponding outer encapsulation, the
      VXLAN tunnel sub-TLV
   is treated as if it were an ethernet frame, the Destination MAC Address
      field unknown type of the Inner Ethernet Header is just the Destination MAC
      Address field sub-TLV.

3.3.1.  IPv4 DS Field

   Most of the payload's ethernet header.

      If the M bit is not set, 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 types that can be used.

   o  See Section 7 to see how the VNI field of specified in the VXLAN encapsulation
      header is set.

2.2.2.  VXLAN-GPE

   This document defines Tunnel
   Encapsulation attribute require an encapsulation outer IP encapsulation.  The IPv4
   DS Field sub-TLV for VXLAN tunnels.
   When can be carried in the TLV of any such tunnel type is VXLAN-GPE, the following is type.
   It specifies the structure setting of one-octet Differentiated Services field
   in the outer IP encapsulation (see [RFC2474]).  The value field is
   always a single octet.

3.3.2.  UDP Destination Port

   Some of the tunnel types that can be specified in the encapsulation sub-TLV:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Ver|V|R|R|R|R|R|                 Reserved                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       VN-ID                   |   Reserved    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 3: VXLAN GPE Tunnel
   Encapsulation Sub-TLV

      V: This bit attribute require an outer UDP encapsulation.
   Generally there is set a standard UDP Destination Port value for a
   particular tunnel type.  However, sometimes it is useful to 1 be able
   to indicate that use a valid VN-ID non-standard UDP destination port.  If a particular tunnel
   type requires an outer UDP encapsulation, and it is present
      in desired to use a
   UDP destination port other than the encapsulation standard one, the port to be used
   can be specified by including a UDP Destination Port sub-TLV.

      R:  The bits designated "R" above are reserved for future use.
      They SHOULD
   value field of this sub-TLV is always a two-octet field, containing
   the port value.

3.4.  Sub-TLVs for Aiding Tunnel Selection

3.4.1.  Protocol Type Sub-TLV

   The protocol type sub-TLV MAY be set included in a given TLV to zero.

      Version (Ver): Indicates VXLAN GPE protocol version.  If indicate
   the
      indicated version is not supported, type of the TLV payload packets that contains this
      Encapsulation sub-TLV MUST may be treated as specifying an unsupported encapsulated with the
   tunnel type. parameters that are being signaled in the TLV.  The value of this field will be copied into the
      corresponding
   field of the VXLAN encapsulation header.

      VN-ID: If the V bit is set, this field sub-TLV contains a 3 octet VN-ID
      value.  If the V bit is not set, this field SHOULD be set 2-octet value from IANA's ethertype
   registry [Ethertypes].

   For example, if we want to zero.

   When forming use three L2TPv3 sessions, one carrying
   IPv4 packets, one carrying IPv6 packets, and one carrying MPLS
   packets, the VXLAN-GPE egress router will include three TLVs of L2TPv3
   encapsulation header:

   o type, each specifying a different Session ID and a
   different payload type.  The values of the V protocol type sub-TLV for these will be
   IPv4 (protocol type = 0x0800), IPv6 (protocol type = 0x86dd), and R bits are NOT copied into
   MPLS (protocol type = 0x8847), respectively.  This informs the flags field
   ingress routers of the VXLAN-GPE header.  However, appropriate encapsulation information to use
   with each of the values given protocol types.  Insertion of the Ver bits are
      copied into specified
   Session ID at the VXLAN-GPE header.  Other bits in ingress routers allows the flags field
      of egress to process the VXLAN-GPE header are set
   incoming packets correctly, according to their protocol type.

3.4.2.  Color Sub-TLV

   The color sub-TLV MAY be encoded as per [VXLAN-GPE].

   o  See Section 7 a way to see how "color" the VNI
   corresponding tunnel TLV.  The value field of the VXLAN-GPE
      encapsulation header is set.

2.2.3.  NVGRE

   This document defines an encapsulation sub-TLV for NVGRE tunnels.
   When the tunnel type is NVGRE, the following is consists of
   a Color Extended Community, as defined in Section 4.3.  For the structure use
   of the
   value field this sub-TLV and Extended Community, please see Section 7.

3.5.  Embedded Label Handling Sub-TLV

   Certain BGP address families (corresponding to particular AFI/SAFI
   pairs, e.g., 1/4, 2/4, 1/128, 2/128) have MPLS labels embedded in
   their NLRIs.  We will use the encapsulation sub-TLV:

      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)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 MAC Address (4 Octets)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MAC Address (2 Octets)     |   Reserved                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 4: NVGRE Encapsulation Sub-TLV

      V: This bit is set term "embedded label" to 1 refer to indicate the
   MPLS label that a valid VN-ID is present embedded in an NLRI, and the encapsulation sub-TLV.

      M: This bit is set term "labeled address
   family" to 1 refer to indicate any AFI/SAFI that a valid MAC Address is
      present has embedded labels.

   Some of the tunnel types (e.g., VXLAN, VXLAN-GPE, and NVGRE) that can
   be specified in the Tunnel Encapsulation attribute have an
   encapsulation sub-TLV.

      R: header containing "Virtual Network" identifier of some
   sort.  The remaining bits in the 8-bit flags field are reserved Encapsulation sub-TLVs for
      further use.  They SHOULD always be set to 0.

      VN-ID: If the V bit is set, the VN-id field contains these tunnel types may
   optionally specify a 3 octet VN-
      ID value.  If value for the V bit virtual network identifier.

   Suppose a Tunnel Encapsulation attribute is not set, the VN-id field SHOULD be set
      to zero.

      MAC Address: If the M bit attached to an UPDATE of
   an embedded address family, and it is set, this field contains decided to use a 6 octet
      Ethernet MAC address.  If particular
   tunnel (specified in one of the M bit attribute's TLVs) for transmitting a
   packet that is not set, this field SHOULD
      be set being forwarded according to all zeroes. that UPDATE.  When
   forming the NVGRE encapsulation header:

   o  The values header for that packet, different
   deployment scenarios require different handling of the V, M, and R bits are NOT copied into the flags
      field of embedded label
   and/or the NVGRE header. virtual network identifier.  The flags field of the VXLAN header is
      set as per [NVGRE].

   o  If the M bit is set, the MAC Address is copied into the Inner
      Destination MAC Address field of Embedded Label Handling
   sub-TLV can be used to control the Inner Ethernet Header (see
      section 3.2 placement of [NVGRE].

      If the M bit is not set, and the payload being sent through the
      NVGRE tunnel is an ethernet frame, the Destination MAC Address
      field of embedded label
   and/or the Inner Ethernet Header is just virtual network identifier in the Destination MAC
      Address field encapsulation.

   The Embedded Label Handling sub-TLV may be included in any TLV of the payload's ethernet header.
   Tunnel Encapsulation attribute.  If the M bit is not set, 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 Tunnel Encapsulation
   attribute is no
      configured value, the NVGRE tunnel cannot be used.

   o  See Section 7 attached to see how the VSID field an UPDATE of a non-labeled address family,
   the NVGRE encapsulation
      header sub-TLV is set.

2.2.4.  GTP

   When treated as a no-op.  If the sub-TLV is contained in a
   TLV whose tunnel type is GTP [GTP-U], the Encapsulation sub-TLV
   contains information needed to send data packets through does not have a GTP
   tunnel, and also contains information needed by virtual network identifier in
   its encapsulation header, the tunnel's remote
   endpoint to create sub-TLV is treated as a "reverse" tunnel back to no-op.  In
   those cases where the transmitter.  This
   allows sub-TLV is treated as a bidirectional control connection to no-op, it SHOULD NOT be created.
   stripped from the TLV before the UPDATE is forwarded.

   The format sub-TLV's Length field always contains the value 1, and its value
   field consists of a single octet.  The following values are defined:

   1: The payload will be an MPLS packet with the Encapsulation Sub-TLV is:

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Remote TEID (4 Octets)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Local TEID (4 Octets)                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Local Endpoint Address (4/16 Octets (IPv4/IPv6))      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 5: GTP Encapsulation Sub-TLV

      Remote TEID: Contains embedded label at the 32-bit Tunnel Endpoint Identifier
      top of its label stack.

   2: The embedded label is not carried in the
      GTP tunnel through which data packets are to be sent.  When data
      packets are sent through payload, but is carried
      either in the tunnel, virtual network identifier field of the Remote TEID
      encapsulation header, or else is ignored entirely.

   Please see Section 8 for the details of how this sub-TLV is carried in
      the GTP encapsulation header.  The GTP header used when
   it is itself
      encapsulation within carried by an IP header, whose IP destination UPDATE of a labeled address
      field is set family.

3.6.  MPLS Label Stack Sub-TLV

   This sub-TLV allows an MPLS label stack to the be associated with a
   particular tunnel.

   The value field of the Remote Endpoint sub-TLV.

      Local TEID: Contains this sub-TLV is a 32-bit Tunnel Endpoint Identifier sequence of a GTP
      tunnel assigned by EPC ([vEPC]).

      Local Endpoint Address: Contains an IPv4 or IPv6 anycast address.
      This MPLS label stack
   entries.  The first entry in the sequence is used, along with the Local TEID, to set up a tunnel in "topmost" label, the
      reverse direction.  See [vEPC] for details.

2.2.5.  MPLS-in-GRE

   When
   final entry in the tunnel type sequence is MPLS-in-GRE, the following "bottommost" label.  When this
   label stack is pushed onto a packet, this ordering MUST be preserved.

   Each label stack entry has the structure
   of the value field in an optional encapsulation sub-TLV: following format:

      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)                Label                  | ToS |S|      TTL      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 6: MPLS-in-GRE Encapsulation 11: MPLS Label Stack Sub-TLV

      GRE-Key: 4-octet field [RFC2890] that

   If a packet is generated by to be sent through the
      advertising router.  The actual method by which tunnel identified in a
   particular TLV, and if that TLV contains an MPLS Label Stack sub-TLV,
   then the key is
      obtained is beyond label stack appearing in the scope of this document.  The key sub-TLV MUST be pushed onto the
   packet.  This label stack MUST be pushed onto the packet before any
   other labels are pushed onto the packet.

   In particular, if the Tunnel Encapsulation attribute is
      inserted into attached to a
   BGP UPDATE of a labeled address family, the GRE encapsulation header contents of the payload packets
      sent by ingress routers to MPLS
   Label Stack sub-TLV MUST be pushed onto the advertising router.  It packet before the label
   embedded in the NLRI is intended
      to be used for identifying extra context information about pushed onto the
      received payload.  Note that packet.

   If the key MPLS label stack sub-TLV is optional.  Unless included in a key
      value is being advertised, TLV identifying a
   tunnel type that uses virtual network identifiers (see Section 8),
   the MPLS-in-GRE encapsulation contents of the MPLS label stack sub-TLV MUST NOT be present.

   Note that pushed onto the GRE tunnel type defined
   packet before the procdures of Section 8 are applied.

   The number of label stack entries in [RFC5512] can the sub-TLV MUST be used
   instead of determined
   from the MPLS-in-GRE tunnel type when sub-TLV length field.  Thus it is not necessary to
   encapsulate MPLS set the S
   bit in GRE.  Including a TLV any of the MPLS-in-GRE tunnel
   type is equivalent to including a TLV label stack entries of the GRE tunnel type 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
   also includes already has a Protocol Type sub-TLV ([RFC5512]) specifying MPLS as label
   stack, the protocol to S bits of all the entries MUST be encapsulated.  That is, if cleared.  When the label
   stack entries are pushed onto a TLV specifies MPLS-
   in-GRE or if it includes packet that does not already have a Protocol Type sub-TLV specifying MPLS,
   label stack, the
   GRE tunnel advertised in that TLV S bit of the bottommost label stack entry MUST NOT be used for carrying IP
   packets.

2.3.  Outer Encapsulation Sub-TLVs

   The Encapsulation sub-TLV for
   set, and the S bit of all the other label stack entries MUST be
   cleared..

   By default, the ToS field of each label stack entry is set to 0.
   This may of course be changed by policy at the originator of the sub-
   TLV.  When pushing the label stack onto a particular tunnel type allows one to
   specify packet, the values ToS of the
   label stack entries is preserved by default.  However, local policy
   at the router that are is pushing on the stack MAY cause modification of
   the ToS values.

   By default, the TTL field of each label stack entry is set to 255.
   This may be placed in certain fields changed by policy at the originator of the
   encapsulation header for that 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 does not usually provide sub-TLV.  When
   pushing the label stack onto a way to specify values for
   fields packet, the TTL of the outer IP and/or UDP encapsulations.  If it label stack
   entries is necessary
   to specify values for fields preserved by default.  However, local policy at the router
   that is pushing on the stack MAY cause modification of the outer encapsulation, additional
   sub-TLVs must be used.  This document defines two such sub-TLVs. TTL
   values.  If an outer encapsulation sub-TLV occurs any label stack entry in a TLV for a tunnel type
   that does not use the corresponding outer encapsulation, the sub-TLV
   as if it were an unknown type of sub-TLV.

2.3.1.  IPv4 DS Field

   Most has a TTL value of
   zero, the tunnel types router that can be specified in is pushing the Tunnel
   Encapsulation attribute require an outer IP encapsulation.  The IPv4
   DS Field stack on a packet MUST change
   the value to a non-zero value.

   Note that this sub-TLV can be carried in the TLV of any such tunnel type.
   It specifies the setting of one-octet Differentiated Services field
   in the outer IP encapsulation (see [RFC2474]).  The value field is
   always appear within a single octet.

2.3.2.  UDP Destination Port

   Some TLV identifying any
   type of the tunnel, not just within a TLV identifying an MPLS tunnel.
   However, if this sub-TLV appears within a TLV identifying an MPLS
   tunnel types (or an MPLS-in-X tunnel), this sub-TLV plays the same role
   that can would be specified in the Tunnel played by an MPLS Encapsulation attribute require sub-TLV.  Therefore, an outer UDP encapsulation.
   Generally there
   MPLS Encapsulation sub-TLV is not defined.

3.7.  Prefix-SID Sub-TLV

   [Prefix-SID-Attribute] defines a standard UDP Destination Port value for a
   particular tunnel type.  However, sometimes it BGP Path attribute known as the
   "Prefix-SID Attribute".  This attribute is useful to be able defined to use a non-standard UDP destination port.  If contain a particular tunnel
   type requires an outer UDP encapsulation, and it
   sequence of one or more TLVs, where each TLV is desired to use either a
   UDP destination port other than the standard one, the port to be used
   can be specified by including "Label-
   Index" TLV, an "IPv6 SID" TLV, or an "Originator SRGB" TLV.

   In this document, we define a UDP Destination Port Prefix-SID sub-TLV.  The value field of this
   the Prefix-SID sub-TLV is always a two-octet field, containing can be set to any valid value of the port value.

2.4.  Embedded Label Handling Sub-TLV

   Certain value
   field of a BGP address families (corresponding to particular AFI/SAFI
   pairs, e.g., 1/4, 2/4, 1/128, 2/128) have MPLS labels embedded Prefix-SID attribute, as defined in
   their NLRIs.  We will use the term "embedded label" to refer to the
   MPLS label that is embedded
   [Prefix-SID-Attribute].

   The Prefix-SID sub-TLV can occur in a TLV identifying any type of
   tunnel.  If an NLRI, and Originator SRGB is specified in the term "labeled address
   family" to refer sub-TLV, the SRGB
   MUST be interpreted to any AFI/SAFI that has embedded labels.

   Some of be the tunnel types (e.g., VXLAN, VXLAN-GPE, and NVGRE) SRGB used by the tunnel's Remote
   Endpoint.  The Label-Index, if present, is the Segment Routing SID
   that can
   be specified the tunnel's Remote Endpoint uses to represent the prefix
   appearing in the Tunnel Encapsulation attribute have an
   encapsulation header containing "Virtual Network" identifier NLRI field of some
   sort.  The Encapsulation sub-TLVs for these tunnel types may
   optionally specify a value for the virtual network identifier.

   Suppose a BGP UPDATE to which the Tunnel
   Encapsulation attribute is attached to an UPDATE of
   an embedded address family, and it is decided to use attached.

   If a particular
   tunnel (specified Label-Index is present in one of the attribute's TLVs) for transmitting prefix-SID sub-TLV, then when a
   packet that is being forwarded according to that UPDATE.  When
   forming sent through the encapsulation header for that packet, different
   deployment scenarios require different handling tunnel identified by the TLV, the
   corresponding MPLS label MUST be pushed on the packet's label stack.
   If the Originator SRGB is present, the corresponding MPLS label is
   computed from the combination of the embedded Label-Index and the Originator
   SRGB (see [Prefix-SID-Attribute]).  If the Originator SRGB is not
   present, the corresponding MPLS label
   and/or is just the virtual network identifier. Label-Index value
   itself.  The Embedded Label Handling
   sub-TLV can be used to control corresponding MPLS label is pushed on after the placement
   processing of the MPLS Label Stack sub-TLV, if present, as specified
   in Section 3.6.  It is pushed on before any other labels (e.g., a
   label embedded in UPDATE's NLRI, or a label
   and/or determined by the virtual network identifier in
   procedures of Section 8 are pushed on the encapsulation. stack.

   The Embedded Label Handling Prefix-SID sub-TLV may be included in any TLV of has slightly different semantics than the
   Tunnel Encapsulation
   Prefix-SID attribute.  If  When the Tunnel Encapsulation Prefix-SID attribute is attached to an UPDATE of a non-labeled address family,
   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 that the sub-TLV prefix-SID is treated as a no-op.  If
   for the sub-TLV is contained in a
   TLV whose tunnel type does not have a virtual network identifier advertised prefix in
   its encapsulation header, that Segment Routing domain.  When the
   Prefix-SID sub-TLV is treated as a no-op.

   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:

   1: The payload will be an MPLS packet with used, the embedded label BGP speaker at the
      top head end of its label stack.

   2: The embedded label is not carried in the payload, but is carried
      either
   tunnel need even not be in the virtual network identifier field of same Segment Routing Domain as the
      encapsulation header, or else
   tunnel's Remote Endpoint, and there is ignored entirely.

   Please see Section 7 no implication that the
   prefix-SID for the details of how this sub-TLV is used when
   it advertised prefix is carried by an UPDATE the same in the Segment
   Routing domains of a labeled address family.

   If the Embedded Label BGP speaker that originated the sub-TLV is carried by an UPDATE of a non-
   labeled address family, it is treated as a no-op.  However, it SHOULD
   NOT be stripped from and
   the TLV before BGP speaker that received it.

4.  Extended Communities Related to the UPDATE is forwarded.

3. Tunnel Encapsulation Attribute

4.1.  Encapsulation Extended Community

   [RFC5512] defines an

   The Encapsulation Extended Community is a Transitive Opaque Extended
   Community.  This 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 identifies a particular tunnel type.  If
   the Encapsulation Extended Community identifies a particular tunnel
   type, its semantics are exactly equivalent to the semantics of a
   Tunnel Encapsulation attribute TLV that:

   o  identifies the same tunnel type, and

   o  has a Remote Endpoint sub-TLV whose IP address field contains the
      address of the BGP next hop BGP next hop of the route to which it is attached,
      and

   o  has no other sub-TLVs.

   The Encapsulation Extended Community was first defined in [RFC5512].
   It provides a small subset of the functionality of the Tunnel
   Encapsulation attribute, and, strictly speaking, is no longer needed.
   However, it is included here for backwards compatibility.

   Note that for tunnel types of the form "X-in-Y", e.g., MPLS-in-GRE,
   the Encapsulation Extended Community implies that only packets of the route
   specified payload type "X" are to which it is attached,
      and

   o  has no other sub-TLVs. be carried through the tunnel of
   type "Y".

   In the remainder of this specification, when we speak of a route as
   containing a Tunnel Encapsulation attribute with a TLV identifying a
   particular tunnel type, we are implicitly including the case where
   the route contains a Tunnel Encapsulation Extended Community
   identifying that tunnel type.

4.2.  Router's MAC Extended Community

   [EVPN-Inter-Subnet] defines a Router's MAC Extended Community.  This
   Extended Community provides information that may conflict with
   information in one or more of the Encapsulation Sub-TLVs of a Tunnel
   Encapsulation attribute.  In case of such a conflict, the information
   in the Encapsulation Sub-TLV takes precedence.

4.

4.3.  Color Extended Community

   The Color Extended Community is a Transitive Opaque Extended
   Community with the following encoding:

      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    |     0x0b      |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Color Value                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 12: Color Extended Community

   For the use of this Extended Community please see Section 7.

5.  Semantics and Usage of the Tunnel Encapsulation attribute

   [RFC5512] specifies the use of the Tunnel Encapsulation attribute in
   BGP UPDATE messages of AFI/SAFI 1/7 and 2/7.  That document restricts
   the use of this attribute to UPDATE messsages of those SAFIs.  This
   document removes that restriction.

   The BGP Tunnel Encapsulation attribute MAY 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 (EVPN).  Use of the Tunnel Encapsulation attribute in BGP
   UPDATE messages of other AFI/SAFIs is outside the scope of this
   document.

   It has been suggested that it may sometimes be useful to attach a
   Tunnel Encapsulation attribute to a BGP UPDATE message that is also
   carrying a PMSI (Provider Multicast Service Interface) Tunnel
   attribute [RFC6514].  If the PMSI Tunnel attribute specifies an IP
   tunnel, the Tunnel Encapsulation attribute could be used to provide
   additional information about the IP tunnel.  The usage of the Tunnel
   Encapsulation attribute in combination with the PMSI Tunnel attribute
   is outside the scope of this document.

   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.

   When the Tunnel Encapsulation attribute is carried in an UPDATE of
   one of the AFI/SAFIs specifies in the previous paragraph, each TLV
   MUST have a Remote Endpoint sub-TLV.  If a TLV that does not have a
   Remote Endpoint sub-TLV, that TLV should be treated as if it had a
   malformed Remote Endpoint sub-TLV (see Section 2.1). 3.1).

   Suppose that:

   o  a given packet P must be forwarded by router R;

   o  the path along which P is to be forwarded is determined by BGP
      UPDATE U;

   o  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 two
      properties:

      *  The tunnel type is supported (i.e., router R knows how to set
         up tunnels of that type, how to create the encapsulation header
         for tunnels of that type, etc.)

      *  The tunnel is of a type that can be used to carry packet P
         (e.g., an MPLS-in-UDP tunnel would not be a feasible tunnel for
         carrying an IP packet, UNLESS the IP packet can first be
         converted to an MPLS packet).

      *  The tunnel is specified in a TLV whose Remote Endpoint sub-TLV
         identifies an IP address that is reachable.

   Then router R SHOULD send packet P through one of the feasible
   tunnels identified in the Tunnel Encapsulation attribute of UPDATE U.

   If the Tunnel Encapsulation attribute contains several TLVs (i.e., if
   it specifies several tunnels), router R may choose any one of those
   tunnels, based upon local policy.  If any of tunnels' TLVs contain
   the Color sub-TLV sub-TLV(Section 3.4.2) and/or the Protocol Type sub-TLV defined in
   [RFC5512],
   (Section 3.4.1, the choice of tunnel may be influenced by these sub-TLVs. sub-
   TLVs.

   Note that if none of the TLVs specifies the MPLS tunnel type, a Label
   Switched Path SHOULD NOT be used. used unless none of the TLVs specifies a
   feasible tunnel.

   If a particular tunnel is not feasible at some moment because its
   Remote Endpoint cannot be reached at that moment, the tunnel may
   become feasible at a later time.  When this happens, router R SHOULD
   reconsider its choice of tunnel to use, and MAY choose to now use the
   tunnel.

   A TLV specifying a non-feasible tunnel is not considered to be
   malformed or erroneous in any way, and the TLV SHOULD NOT be stripped
   from the Tunnel Encapsulation attribute before redistribution.

   In addition to the sub-TLVs already defined, additional sub-TLVs may
   be defined that affect the choice of tunnel to be used, or that
   affect the contents of the tunnel encapsulation header.  The
   documents that define any such additional sub-TLVs must specify the
   effect that including the sub-TLV is to have.

   If it is determined to send a packet through the tunnel specified in
   a particular TLV of a particular Tunnel Encapsulation attribute, and
   if that TLV contains a Remote Endpoint sub-TLV, then
   the tunnel's remote endpoint address is the IP address contained in
   the sub-TLV.  If the TLV does not contain a Remote Endpoint sub-TLV, or if it contains a Remote Endpoint sub-TLV whose
   value field is all zeroes, then the tunnel's remote endpoint is the
   IP address specified as the Next Hop of the BGP Update containing the
   Tunnel Encapsulation attribute.

   The procedure for sending a packet through a particular tunnel type
   to a particular remote endpoint depends upon the tunnel type, and is
   outside the scope of this document.  The contents of the tunnel
   encapsulation header MAY be influenced by the Encapsulation sub-TLV.

   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.
   Whenever a new Tunnel Type TLV is defined, the specification of that
   TLV must describe (or reference) the procedures for creating the
   encapsulation header used to forward packets through that tunnel
   type.

   If a Tunnel Encapsulation attribute specifies several tunnels, the
   way in which a router chooses which one to use is a matter of policy,
   subject to the following constraint: if a router can determine that a
   given tunnel is not functional, it MUST NOT use that tunnel.  In
   particular, if the tunnel is identified in a TLV that has a Remote
   Endpoint sub-TLV, and if the IP address specified in the sub-TLV is
   not reachable from router R, then the tunnel SHOULD be considered
   non-functional.  Other means of determining whether a given tunnel is
   functional MAY be used; specification of such means is outside the
   scope of this specification.  Of course, if a non-functional tunnel
   later becomes functional, router R SHOULD reevaluate its choice of
   tunnels.

   If router R determines that it cannot use any of the tunnels
   specified in the Tunnel Encapsulation attribute, it MAY either drop
   packet P, or it MAY transmit packet P as it would had the Tunnel
   Encapsulation attribute not been present.  This is a matter of local
   policy.  By default, the packet SHOULD be transmitted as if the
   Tunnel Encapsulation attribute had not been present.

   A Tunnel Encapsulation attribute may contain several TLVs that all
   specify the same tunnel type.  Each TLV should be considered as
   specifying a different tunnel.  Two tunnels of the same type may have
   different Remote Endpoint sub-TLVs, different Encapsulation sub-TLVs,
   etc.  Choosing between two such tunnels is a matter of local policy.

   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 remote 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
   of that route.  That is, tunnels may be "stacked".

   Notwithstanding anything said in this document, a BGP speaker MAY
   have local policy that influences the choice of tunnel, and the way
   the encapsulation is formed.  A BGP speaker MAY also have a local
   policy that tells it to ignore the Tunnel Encapsulation attribute
   entirely or in part.  Of course, interoperability issues must be "stacked".

5.
   considered when such policies are put into place.

6.  Routing Considerations

5.1.

6.1.  No Impact on BGP Decision Process

   The presence of the Tunnel Encapsulation attribute does not affect
   the BGP bestpath selection algorithm.

   Under certain circumstances, this may need lead to counter-intuitive
   consequences.  For example, suppose:

   o  router R1 receives a BGP UPDATE message from router R2, such that

      *  the NLRI of that UPDATE is prefix X,

      *  the UPDATE contains a Tunnel Encapsulation attribute specifying
         two tunnels, T1 and T2,

      *  R1 cannot use tunnel T1 or tunnel T2, either because the tunnel
         remote endpoint is not reachable or because R1 does not support
         that kind of tunnel

   o  router R1 receives a BGP UPDATE message from router R3, such that

      *  the NLRI of that UPDATE is prefix X,

      *  the UPDATE contains a Tunnel Encapsulation attribute specifying
         two tunnels, T3 and T4,

      *  R1 can use at least one of the two tunnels

   Since the Tunnel Encapsulation attribute does not affect bestpath
   selection, R1 may well install the route from R2 rather than the
   route from R3, even though R2's route contains no usable tunnels.

   This possibility must be kept in mind whenever a Remote Endpoint sub-
   TLV carried by a given UPDATE specifies an IP address that is
   different than the next hop of that UPDATE.

5.2.

6.2.  Looping, Infinite Stacking, Etc.

   Consider a packet destined for address X.  Suppose a BGP UPDATE for
   address prefix X carries a Tunnel Encapsulation attribute that
   specifies a remote tunnel endpoint of Y.  And suppose that a BGP
   UPDATE for address prefix Y carries a Tunnel Encapsulation attribute
   that specifies a Remote Endpoint of X.  It is easy to see that this
   will cause an infinite number of encapsulation headers to be put on
   the given packet.

   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 of this.

   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 remote tunnel endpoint of Y.  Suppose router R
   receives and processes the update.  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.

   These possibilities must also be kept in mind whenever the Remote
   Endpoint for a given prefix differs from the BGP next hop for that
   prefix.

6.

7.  Recursive Next Hop Resolution

   Suppose that:

   o  a given packet P must be forwarded by router R1;

   o  the path along which P is to be forwarded is determined by BGP
      UPDATE U1;

   o  UPDATE U1 does not have a Tunnel Encapsulation attribute;

   o  the next hop of UPDATE U1 is router R2;

   o  the best path to router R2 is a BGP route that was advertised in
      UPDATE U2;

   o  UPDATE U2 has a Tunnel Encapsulation attribute.

   Then packet P SHOULD be sent through one of the tunnels identified in
   the Tunnel Encapsulation attribute of UPDATE U2.  See Section 4 5 for
   further details.

   However, suppose that one of the TLVs in U2's Tunnel Encapsulation
   attribute contains the Color Sub-TLV.  In that case, packet P SHOULD
   NOT be sent through the tunnel identified in that TLV, unless U1 is
   carrying the Color Extended Community that is identified in U2's
   Color Sub-TLV.

   Note that if UPDATE U1 and UPDATE U2 both have Tunnel Encapsulation
   attributes, packet P will be carried carried through a pair of nested
   tunnels.  P will first be encapsulated based on the Tunnel
   Encapsulation attribute of U1.  This encapsulated packet then becomes
   the payload, and is encapsulated based on the Tunnel Encapsulation
   attribute of U2.  This is another way of "stacking" tunnels (see also
   Section 5.

   The procedures in this section presuppose that U1's next hop resolves
   to a BGP route, and that U2's next hop resolves (perhaps after
   further recursion) to a non-BGP route.

8.  Use of Virtual Network Identifiers and Embedded Labels when Imposing
    a Tunnel Encapsulation

   If the TLV specifying a tunnel contains an MPLS Label Stack sub-TLV,
   then when sending a packet through that tunnel, the procedures of
   Section 3.6 are applied before the procedures of this section.

   If the TLV specifying a tunnel contains a Prefix-SID sub-TLV, the
   procedures of Section 3.7 are applied before the procedures of this
   section.  If the TLV also contains an MPLS Label Stack sub-TLV, the
   procedures of Section 3.6 are applied before the procedures of
   Section 3.7.

8.1.  Tunnel Types without a Virtual Network Identifier Field

   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 pair tunnel specified
   in one of nested
   tunnels.  P will first be encapsulated based the attribute's TLVs, and that tunnel type does not contain
   a virtual network identifier field, the label or labels from the NLRI
   are pushed on the Tunnel
   Encapsulation attribute of U1.  This encapsulated packet's label stack.  The resulting MPLS packet then becomes
   the payload, and is encapsulated based on
   then further encapsulated, as specified by the TLV.

8.2.  Tunnel Encapsulation
   attribute of U2.  This is another way of "stacking" tunnels (see also
   Section 4.

7.  Use of Types with a Virtual Network Identifiers and Embedded Labels when Imposing
    a Tunnel Encapsulation Identifier Field

   Three of the tunnel types that can be specified in a Tunnel
   Encapsulation TLV have virtual network identifier fields in their
   encapsulation headers.  In the VXLAN and VXLAN-GPE encapsulations,
   this field is called the VNI field; in the NVGRE encapsulation, this
   field is called the VSID field.

   When one of these tunnel encapsulations is imposed on a packet, the
   setting of the 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 on a BGP UPDATE of a labeled address family, the setting of
   the virtual network identifier field also depends upon the contents
   of the Embedded Label Handling sub-TLV (if present).

   This section specifies the procedures for choosing the value to set
   in the virtual network identifier field of the encapsulation header.
   These procedures apply only when the tunnel type is VXLAN, VXLAN-GPE,
   or NVGRE.

7.1.

8.2.1.  Unlabeled Address Families

   This sub-section applies when:

   o  the Tunnel Encapsulation attribute is carried on a BGP UPDATE of
      an unlabeled address family, and

   o  at least one of the attribute's TLVs identifies a tunnel type that
      uses a virtual network identifier, and

   o  it has been determined to send a packet through one of those
      tunnels.

   If the TLV identifying the tunnel contains an Encapsulation sub-TLV
   whose V bit is set, the virtual network identifier field of the
   encapsulation header is set to the value of the virtual network
   identifier field of the Encapsulation sub-TLV.

   Otherwise, the 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.

7.2.

8.2.2.  Labeled Address Families

   This sub-section applies when:

   o  the Tunnel Encapsulation attribute is carried on a BGP UPDATE of a
      labeled address family, and

   o  at least one of the attribute's TLVs identifies a tunnel type that
      uses a virtual network identifier, and

   o  it has been determined to send a packet through one of those
      tunnels.

7.2.1.

8.2.2.1.  When a Valid VNI has been Signaled

   If the TLV identifying the tunnel contains an Encapsulation sub-TLV
   whose V bit is set, the virtual network identifier field of the
   encapsulation header is set as follows:

   o  If the TLV contains an Embedded Label Handling sub-TLV whose value
      is 1, then the virtual network identifier field of the
      encapsulation header is set to the value of the virtual network
      identifier field of the Encapsulation sub-TLV.

      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.

   o  If the TLV does not contain an Embedded Label Handling sub-TLV, or
      if contains an Embedded Label Handling sub-TLV whose value is 2,
      the embedded label is ignored entirely, and the virtual network
      identifier field of the encapsulation header is set to the value
      of the virtual network identifier field of the Encapsulation sub-
      TLV.

7.2.2.

8.2.2.2.  When a Valid VNI has not been Signaled

   If the TLV identifying the tunnel does not contain an Encapsulation
   sub-TLV whose V bit is set, the virtual network identifier field of
   the encapsulation header is set as follows:

   o  If the TLV contains an Embedded Label Handling sub-TLV whose value
      is 1, then the 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.

      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.

   o  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 virtual network
      identifier field of the encapsulation header.

      The embedded label does not appear in the MPLS label stack of the
      payload.

7.2.3.

9.  Applicability Restrictions

   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
   whose address appears as the next hop.  Certain of the procedures of
   Section 7.2.1 8.2.2.1 or Section 7.2.2 8.2.2.2 cause the embedded label to be
   carried by a data packet to the router whose address appears in the
   Remote Endpoint sub-TLV.  If the Remote Endpoint sub-TLV does not
   identify the same router that is the next hop, sending the packet
   through the tunnel may cause the label to be misinterpreted at the
   tunnel's remote endpoint.  This may cause misdelivery of the packet.

   Therefore the embedded label MUST NOT be carried by a data packet
   traveling through a tunnel unless it is known that the label will be
   properly interpreted at the tunnel's remote endpoint.  How this is
   known is outside the scope of this document.

   Note that if the Tunnel Encapsulation attribute is attached to a VPN-
   IP route [RFC4364], and if Inter-AS "option b" (see section 10 of
   [RFC4364] is being used, and if the Remote Endpoint sub-TLV contains
   an IP address that is not in same AS as the router receiving the
   route, it is very likely that the embedded label has been changed.
   Therefore use of the Tunnel Encapsulation attribute in an "Inter-AS
   option b" scenario is not supported.

8.

10.  Scoping

   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, it is intended that the Tunnel Encapsulation
   attribute be used only within a well-defined scope, e.g., within a
   set of Autonomous Systems 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.

   To prevent the Tunnel Encapsulation attribute from being distributed
   beyond its intended scope, any BGP speaker that understands the
   attribute MUST 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 redistributed.  This
   filtering SHOULD be possible on a per-BGP-session basis.  For each
   session, filtering of the attribute on incoming UPDATEs MUST be
   enabled by default.

   In addition, any BGP speaker that understands the attribute MUST be
   able to filter the attribute from outgoing BGP UPDATE messages.  This
   filtering SHOULD be possible on a per-BGP-session basis.  For each
   session, filtering of the attribute on outgoing UPDATEs MUST be
   enabled by default.

9.

11.  Error Handling

   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 field.  Similarly, the final octet of a sub-
   TLV is determined by its length field.  The final octet of a TLV must MUST
   also be the final octet of its final sub-TLV.  If this is not the
   case, the TLV MUST be considered to be malformed.  A TLV that is
   found to be malformed for this reason MUST NOT be processed, and MUST
   be stripped from the Tunnel Encapsulation attribute before
   redistribution. the
   attribute is propagated.  Subsequent TLVs in the Tunnel Encapsulation
   attribute may still be valid, in which case they MUST be processed
   and redistributed normally.

   If a Tunnel Encapsulation attribute does not have any valid TLVs, or
   it does not have the transitive bit set, the "Attribute Discard"
   procedure of [ERRORS] [RFC7606] is applied.

   If a Tunnel Encapsulation attribute can be parsed correctly, but
   contains a TLV that is not recognized (i.e., the whose tunnel type is not
   recognized) recognized by a particular
   BGP speaker, that BGP speaker MUST NOT consider the attribute is NOT
   considered to be
   malformed.  The unrecognized  Rather, the TLV with the unrecognized tunnel type MUST be
   ignored, and the BGP speaker MUST interpret the attribute as if the
   unrecognized that
   TLV had not been present.  If the route carrying the Tunnel
   Encapsulation attribute is redistributed propagated with the attribute, the
   unrecognized TLV SHOULD remain in the attribute.

   If a TLV of a Tunnel Encapsulation attribute contains a sub-TLV that
   is not recognized by a particular BGP speaker, the BGP speaker SHOULD
   process that TLV as if the unrecognized sub-TLV had not been present.
   If the route carrying the Tunnel Encapsulation attribute is
   redistributed
   propagated with the attribute, the unrecognized TLV SHOULD remain in
   the attribute.

   In general, if a TLV contains a sub-TLV that is malformed (e.g.,
   contains a length field whose value is not legal for that sub-TLV),
   the sub-TLV should be treated as if it were an unrecognized sub-TLV.
   This document specifies one exception to this rule -- if a TLV
   contains a malformed Remote Endpoint sub-TLV (as defined in
   Section 2.1, 3.1, the entire TLV MUST be ignored, and SHOULD be removed
   from the Tunnel Encapsulation attribute before the route carrying
   that attribute is redistributed.

   A TLV that does not contain the Remote Endpoint sub-TLV MUST be
   treated as if it contained a malformed Remote Endpoint sub-TLV.

   A TLV identifying a particular tunnel type may contain a sub-TLV that
   is meaningless for that 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.  Sub-TLVs of this sort
   SHOULD be treated as no-ops.  That is, they SHOULD NOT affect the
   creation of the encapsulation header.  However, the sub-TLV MUST NOT
   be considered to be malformed, and MUST NOT be removed from the TLV
   before the route carrying the Tunnel Encapsulation attribute is
   redistributed.  (This allows for the possibility that such sub-TLVs
   may be given a meaning, in the context of the specified tunnel type,
   in the future.)

   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; each such TLV is regarded as describing a
   different tunnel.

10.

12.  IANA Considerations

12.1.  Subsequent Address Family Identifiers

   IANA is requested to modify the "Subsequent Address Family
   Identifiers" registry to indicate that the Encapsulation SAFI is
   deprecated.  This document should be the reference.

12.2.  BGP Path Attributes

   IANA has assigned value 23 from the "BGP Path Attributes" Registry,
   to "Tunnel Encapsulation Attribute".  IANA is requested to add this
   document as a reference.

12.3.  Extended Communities

   IANA has assigned values from the "Transitive Opaque Extended
   Community" type Registry to the "Color Extended Community" (sub-type
   0x0b), and to the "Encapsulation Extended Community"(0x030c).  IANA
   is requested to add this document as a reference for both
   assignments.

12.4.  BGP Tunnel Encapsulation Attribute Sub-TLVs

   IANA is requested to change the registration policy of the "BGP
   Tunnel Encapsulation Attribute Sub-TLVs" registry to the following:

   o  The values 0 and 255 are reserved.

   o  The values in the range 1-127 are to be allocated using the
      "Standards Action" registration procedure.

   o  The values in the range 128-251 are to be allocated using the
      "First Come, First Served" registration procedure.

   o  The values in the range 252-254 are reserved for experimental use;
      IANA shall not allocate values from this range.

   IANA is requested to assign a codepoint from the "BGP Tunnel
   Encapsulation Attribute Sub-TLVs" registry for "Remote Endpoint", "Remote Endpoint",
   with this document being the reference.

   IANA is requested to assign a codepoint from the "BGP Tunnel
   Encapsulation Attribute Sub-TLVs" registry for "IPv4 DS Field", with
   this document being the reference.

   IANA is requested to assign a codepoint from the "BGP Tunnel
   Encapsulation Attribute Sub-TLVs" registry for "IPv4 DS Field", "UDP Destination
   Port", with this document being the reference.

   IANA is requested to assign a codepoint from the "BGP Tunnel
   Encapsulation Attribute Sub-TLVs" registry for "UDP Destination
   Port", "Embedded Label
   Handling", with this document being the reference.

   IANA is requested to assign a codepoint from the "BGP Tunnel
   Encapsulation Attribute Sub-TLVs" registry for "Embedded "MPLS Label
   Handling", Stack",
   with this document being the reference.

   IANA is requested to assign a codepoint from the "BGP Tunnel
   Encapsulation Attribute Sub-TLVs" registry for "Prefix SID", with
   this document being the reference.

   IANA has assigned codepoints from the "BGP Tunnel Types" Encapsulation
   Attribute Sub-TLVs" registry for "GTP". "Encapsulation", "Protocol Type",
   and "Color".  IANA is requested to add this document as a reference.

12.5.  Tunnel Types

   IANA is requested to add this document as a reference for tunnel
   types 8 (VXLAN), 9 (NVGRE), 11 (MPLS-in-GRE), and 12 (VXLAN-GPE) in
   the "BGP Tunnel Encapsulation Tunnel Types" registry.

11.

   IANA is requested to assign a codepoint from the "BGP Tunnel
   Encapsulation Tunnel Types" registry for "GTP".

   IANA is requested to add this document as a reference for tunnel
   types 1 (L2TPv3), 2 (GRE), and 7 (IP in IP) in the "BGP Tunnel
   Encapsulation Tunnel Types" registry.

13.  Security Considerations

   The Tunnel Encapsulation attribute can cause traffic to be diverted
   from its normal path, especially when the Remote Endpoint sub-TLV is
   used.  This can have serious consequences if the attribute is added
   or modified illegitimately, as it enables traffic to be "hijacked".

   The Remote Endpoint sub-TLV contains both an IP address and an AS
   number.  BGP Origin Validation [RFC6811] can be used to obtain
   assurance that the given IP address belongs to the given AS.  While
   this provides some protection against misconfiguration, it does not
   prevent a malicious agent from inserting a sub-TLV that will appear
   valid.

   Before sending a packet through the tunnel identified in a particular
   TLV of a Tunnel Encapsulation attribute, it may be advisable to use
   BGP Origin Validation to obtain the following additional assurances:

   o  the origin AS of the route carrying the Tunnel Encapsulation
      attribute is correct;

   o  the origin AS of the route to the IP address specified in the
      Remote Endpoint sub-TLV is correct, and is the same AS that is
      specified in the Remote Endpoint sub-TLV.

   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.  However, this may
   not suit all use cases, and in any event is not very strong
   protection against hijacking.

   For these reasons, BGP Origin Validation should not be relied upon
   exclusively, and the filtering procedures of Section 8 10 should always
   be in place.

   Increased protection can be obtained by using BGP Path Validation
   [BGPSEC] to ensure that the route carrying the Tunnel Encapsulation
   attribute, and the routes to the Remote Endpoint of each specified
   tunnel, have not been altered illegitimately.

   If BGP Origin Validation is used as specified above, and the tunnel
   specified in a particular TLV of a Tunnel Encapsulation attribute is
   therefore regarded as "suspicious", that tunnel should not be used.
   Other tunnels specified in (other TLVs of) the Tunnel Encapsulation
   attribute may still be used.

12.

14.  Acknowledgments

   This document contains text from RFC5512, co-authored by Pradosh
   Mohapatra.  The authors of the current document wish to thank Pradosh
   for his contribution.  RFC5512 itself built upon prior work by Gargi
   Nalawade, Ruchi Kapoor, Dan Tappan, David Ward, Scott Wainner, Simon
   Barber, and Chris Metz, whom we also thank for their contributions.

   The authors wish to think Ron Bonica, John Drake, Satoru Matsushima,
   Dhananjaya Rao, John Scudder, Ravi Singh, Thomas Morin, and Xiaohu Xu Xu,
   and Zhaohui Zhang for their review, comments, and/or helpful
   discussions.

13.

15.  Contributor Addresses

   Below is a list of other contributing authors in alphabetical order:

   Randy Bush
   Internet Initiative Japan
   5147 Crystal Springs
   Bainbridge Island, Washington  98110
   United States

   Email: randy@psg.com

   Robert Raszuk
   Mirantis Inc.
   615 National Ave. #100
   Mountain View, California  94043
   Bloomberg LP
   731 Lexington Ave
   New York City, NY  10022
   United States

   Email: robert@raszuk.net

14.

16.  References

14.1.

16.1.  Normative References

   [ERRORS]   Chen, E., Scudder, J., Mohapatra, P., and K. Patel,
              "Revised Error Handling for BGP UPDATE Messages",
              internet-draft draft-ietf-idr-error-handling-19, April
              2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5512]  Mohapatra, P. and E. Rosen, "The BGP Encapsulation
              Subsequent Address Family Identifier (SAFI) and the BGP
              Tunnel Encapsulation Attribute", RFC 5512,
              DOI 10.17487/RFC5512, April 2009,
              <http://www.rfc-editor.org/info/rfc5512>.

14.2.

   [RFC7606]  Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
              Patel, "Revised Error Handling for BGP UPDATE Messages",
              RFC 7606, DOI 10.17487/RFC7606, August 2015,
              <http://www.rfc-editor.org/info/rfc7606>.

16.2.  Informative References

   [BGPSEC]   Lepinski, M. and S. Turner, "An Overview of BGPsec",
              internet-draft draft-ietf-sidr-bgpsec-overview, June 2015.

   [Ethertypes]
              "IANA Ethertype Registry",
              <http://www.iana.org/assignments/ieee-802-numbers/
              ieee-802-numbers.xhtml>.

   [EVPN-Inter-Subnet]
              Sajassi, A., Salem, S., Thoria, S., Rekhter, Y., Drake,
              J., Yong, L., Dunbar, L., Henderickx, W., Rabadan, J.,
              Balus, F., and D. Cai, "Integrated Routing and Bridging in
              EVPN", internet-draft draft-ietf-bess-evpn-inter-subnet-
              forwarding, November 2014. October 2015.

   [GTP-U]    3GPP, "GPRS Tunneling Protocol User Plane, TS 29.281",
              2014.

   [NVGRE]    Garg, P.

   [Prefix-SID-Attribute]
              Previdi, S., Filsfils, C., Lindem, A., Patel, K.,
              Sreekantiah, A., Ray, S., and Y. Wang, "NVGRE: Network Virtualization using
              Generic H. Gredler, "Segment Routing Encapsulation",
              Prefix SID extensions for BGP", internet-draft draft-
              sridharan-virtualization-nvgre, April draft-ietf-
              idr-bgp-prefix-sid-02, October 2015.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              DOI 10.17487/RFC2474, December 1998,
              <http://www.rfc-editor.org/info/rfc2474>.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              DOI 10.17487/RFC2784, March 2000,
              <http://www.rfc-editor.org/info/rfc2784>.

   [RFC2890]  Dommety, G., "Key and Sequence Number Extensions to GRE",
              RFC 2890, DOI 10.17487/RFC2890, September 2000,
              <http://www.rfc-editor.org/info/rfc2890>.

   [RFC3931]  Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
              "Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
              RFC 3931, DOI 10.17487/RFC3931, March 2005,
              <http://www.rfc-editor.org/info/rfc3931>.

   [RFC4023]  Worster, T., Rekhter, Y., and E. Rosen, Ed.,
              "Encapsulating MPLS in IP or Generic Routing Encapsulation
              (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
              <http://www.rfc-editor.org/info/rfc4023>.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <http://www.rfc-editor.org/info/rfc4364>.

   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
              <http://www.rfc-editor.org/info/rfc6514>.

   [RFC6811]  Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
              Austein, "BGP Prefix Origin Validation", RFC 6811,
              DOI 10.17487/RFC6811, January 2013,
              <http://www.rfc-editor.org/info/rfc6811>.

   [RFC7348]  Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
              L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
              eXtensible Local Area Network (VXLAN): A Framework for
              Overlaying Virtualized Layer 2 Networks over Layer 3
              Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
              <http://www.rfc-editor.org/info/rfc7348>.

   [RFC7510]  Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
              "Encapsulating MPLS in UDP", RFC 7510,
              DOI 10.17487/RFC7510, April 2015,
              <http://www.rfc-editor.org/info/rfc7510>.

   [RFC7637]  Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
              Virtualization Using Generic Routing Encapsulation",
              RFC 7637, DOI 10.17487/RFC7637, September 2015,
              <http://www.rfc-editor.org/info/rfc7637>.

   [vEPC]     Matsushima, S. and R. Wakikawa, "Stateless User-Plane
              Architecture for Virtualized EPC", internet-draft draft-
              matsushima-stateless-uplane-vepc-04, March 2015.

   [VXLAN-GPE]
              Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F.,
              Smith, M., Agarwal, P., Xu, X., Elzur, U., Garg, P.,
              Melman, D., and R. Manur, "Generic Protocol Extension for
              VXLAN", internet-draft draft-ietf-nvo3-vxlan-gpe, May
              2015.

Authors' Addresses

   Eric C. Rosen (editor)
   Juniper Networks, Inc.
   10 Technology Park Drive
   Westford, Massachusetts  01886
   United States

   Email: erosen@juniper.net

   Keyur Patel
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA  95134
   United States

   Email: keyupate@cisco.com

   Gunter Van de Velde
   Alcatel-Lucent
   Copernicuslaan 50
   Antwerpen  2018
   Belgium

   Email: gunter.van_de_velde@alcatel-lucent.com