• BGP speaker R1 has received and selected UPDATE U for local use;
• UPDATE U's SAFI is the Encapsulation SAFI;
• UPDATE U has the address R2 as its NLRI;
• UPDATE U has a Tunnel Encapsulation attribute.
• R1 has a packet, P, to transmit to destination D; and
• R1's best route to D is a BGP route that has R2 as its next hop.

• 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.
• There is no way to use the Tunnel Encapsulation attribute to specify the tunnel egress endpoint address of a given tunnel; [RFC 5512] assumes that the tunnel egress endpoint of each tunnel is specified as the NLRI of an UPDATE of the Encapsulation SAFI.
• If the respective best routes to two different address prefixes have the same next hop, [RFC 5512] does not provide a straightforward method to associate each prefix with a different tunnel.
• 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.
• In the specification of the sub-TLVs in [RFC 5512], each sub-TLV has a one-octet Length field. In some cases, where a sub-TLV may require more than 255 octets for its encoding, a two-octet Length field may be needed.

• Deprecating the Encapsulation SAFI.
• Defining a new "Tunnel Egress Endpoint sub-TLV" (Section 3.1) 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.
• 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.
• 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.
• Defining the Sub-TLV Type field so that a sub-TLV whose type is in the range from 0 to 127 (inclusive) has a one-octet Length field, but a sub-TLV whose type is in the range from 128 to 255 (inclusive) has a two-octet Length field.

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

Tunnel Type (2 octets):

Identifies a type of tunnel. The field contains values from the IANA registry"BGP Tunnel Encapsulation Attribute Tunnel Types" [IANA-BGP-TUNNEL-ENCAP]. See Section 3.4.1 for discussion of special treatment of tunnel types with names of the form "X-in-Y".

Length (2 octets):

The total number of octets of the Value field.

Value (variable):

Comprised of multiple sub-TLVs.

                    +--------------------------------+
                    | Sub-TLV Type (1 octet)         |
                    +--------------------------------+
                    | Sub-TLV Length (1 or 2 octets) |
                    +--------------------------------+
                    | Sub-TLV Value (variable)       |
                    +--------------------------------+

Sub-TLV Type (1 octet):

Each sub-TLV type defines a certain property about the Tunnel TLV that contains this sub-TLV. The field contains values from the IANA registry "BGP Tunnel Encapsulation Attribute Sub-TLVs" [IANA-BGP-TUNNEL-ENCAP].

Sub-TLV Length (1 or 2 octets):

The total number of octets of the Sub-TLV Value field. The Sub-TLV Length field contains 1 octet if the Sub-TLV Type field contains a value in the range from 0-127. The Sub-TLV Length field contains two octets if the Sub-TLV Type field contains a value in the range from 128-255.

Sub-TLV Value (variable):

Encodings of the Value field depend on the sub-TLV type. The following subsections define the encoding in detail.

1. a two-octet Address Family subfield
2. an Address subfield, 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       Reserved (4 octets)                     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Address Family (2 octets)   |           Address             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          (variable)           +
  ~                                                               ~
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• The length of the sub-TLV's Value field is other than 6 added to the defined length for the address family given in its Address Family subfield. Therefore, for address family behaviors defined in this document, the permitted values are:
  • 10, if the Address Family subfield contains the value for IPv4.
  • 22, if the Address Family subfield contains the value for IPv6.
  • 6, if the Address Family subfield contains the value zero.
• The IP address in the sub-TLV's Address subfield lies within a block listed in the relevant Special-Purpose IP Address registry [RFC 6890] with either a "destination" attribute value or a "forwardable" attribute value of "false". (Such routes are sometimes colloquially known as "Martians".) This restriction MAY be relaxed by explicit configuration.
• It can be determined that the IP address in the sub-TLV's Address subfield does not belong to the Autonomous System (AS) that originated the route that contains the attribute. Section 3.1.1 describes an optional procedure to make this determination.

   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 (2 octets)      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

V:

This bit is set to 1 to indicate that a Virtual Network Identifier (VN-ID) is present in the Encapsulation sub-TLV. If set to 0, the VN-ID field is disregarded. Please see Section 9.

M:

This bit is set to 1 to indicate that a Media Access Control (MAC) Address is present in the Encapsulation sub-TLV. If set to 0, the MAC Address field is disregarded.

R:

The remaining bits in the 8-bit Flags field are reserved for further use. They MUST always be set to 0 by the originator of the sub-TLV. Intermediate routers MUST propagate them without modification. Any receiving routers MUST ignore these bits upon receipt.

VN-ID:

If the V bit is set to 1, the VN-ID field contains a 3-octet VN-ID value. If the V bit is set to 0, the VN-ID field MUST be set to zero on transmission and disregarded on receipt.

MAC Address:

If the M bit is set to 1, this field contains a 6-octet Ethernet MAC address. If the M bit is set to 0, this field MUST be set to all zeroes on transmission and disregarded on receipt.

Reserved:

MUST be set to zero on transmission and disregarded on receipt.

• The values of the V, M, and R bits are NOT copied into the Flags field of the VXLAN header. The Flags field of the VXLAN header is set as per [RFC 7348].
• If the M bit is set to 1, the MAC Address is copied into the Inner Destination MAC Address field of the Inner Ethernet Header (see Section 5 of RFC 7348). If the M bit is set to 0, and the payload being sent through the VXLAN tunnel is an Ethernet frame, the Destination MAC Address field of the Inner Ethernet Header is just the Destination MAC Address field of the payload's Ethernet header. If the M bit is set to 0, and the payload being sent through the VXLAN tunnel is an IP or MPLS packet, the Inner Destination MAC Address field is set to a configured value; if there is no configured value, the VXLAN tunnel cannot be used.
• If the V bit is set to 0, and the BGP UPDATE message has an AFI/SAFI other than Ethernet VPNs (SAFI 70, "BGP EVPNs"), then the VXLAN tunnel cannot be used.
• Section 9 describes how the VNI (VXLAN Network Identifier) field of the VXLAN encapsulation header is set.

   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 (2 octets)      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

V:

This bit is set to 1 to indicate that a VN-ID is present in the Encapsulation sub-TLV. If set to 0, the VN-ID field is disregarded. Please see Section 9.

M:

This bit is set to 1 to indicate that a MAC Address is present in the Encapsulation sub-TLV. If set to 0, the MAC Address field is disregarded.

R:

The remaining bits in the 8-bit Flags field are reserved for further use. They MUST always be set to 0 by the originator of the sub-TLV. Intermediate routers MUST propagate them without modification. Any receiving routers MUST ignore these bits upon receipt.

VN-ID:

If the V bit is set to 1, the VN-ID field contains a 3-octet VN-ID value, used to set the NVGRE Virtual Subnet Identifier (VSID; see Section 9). If the V bit is set to 0, the VN-ID field MUST be set to zero on transmission and disregarded on receipt.

MAC Address:

If the M bit is set to 1, this field contains a 6-octet Ethernet MAC address. If the M bit is set to 0, this field MUST be set to all zeroes on transmission and disregarded on receipt.

Reserved:

MUST be set to zero on transmission and disregarded on receipt.

• The values of the V, M, and R bits are NOT copied into the Flags field of the NVGRE header. The Flags field of the NVGRE header is set as per [RFC 7637].
• If the M bit is set to 1, the MAC Address is copied into the Inner Destination MAC Address field of the Inner Ethernet Header (see Section 3.2 of RFC 7637). If the M bit is set to 0, and the payload being sent through the NVGRE tunnel is an Ethernet frame, the Destination MAC Address field of the Inner Ethernet Header is just the Destination MAC Address field of the payload's Ethernet header. If the M bit is set to 0, and the payload being sent through the NVGRE tunnel is an IP or MPLS packet, the Inner Destination MAC Address field is set to a configured value; if there is no configured value, the NVGRE tunnel cannot be used.
• If the V bit is set to 0, and the BGP UPDATE message has an AFI/SAFI other than Ethernet VPNs (EVPNs), then the NVGRE tunnel cannot be used.
• Section 9 describes how the VSID field of the NVGRE encapsulation header is set.

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

Session ID:

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

Cookie:

An optional, variable-length (encoded in 0 to 8 octets) value used by L2TPv3 to check the association of a received data message with the session identified by the Session ID. Generation and usage of the cookie value is as specified in [RFC 3931].

The length of the cookie is not encoded explicitly but can be calculated as (sub-TLV length - 4).

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

GRE Key:

4-octet field [RFC 2890] that is generated by the advertising router. Note that the key is optional. Unless a key value is being advertised, the GRE Encapsulation sub-TLV MUST NOT be present.

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

GRE Key:

4-octet field [RFC 2890] that is generated by the advertising router. Note that the key is optional. Unless a key value is being advertised, the MPLS-in-GRE Encapsulation sub-TLV MUST NOT be present.

1:

The payload will be an MPLS packet with the embedded label at the top of its label stack.

2:

The embedded label is not carried in the payload but is either carried in the Virtual Network Identifier field of the encapsulation header or else ignored entirely.

   0 1 2 3 4 5 6 7
  +-+-+-+-+-+-+-+-+
  |     1 or 2    |
  +-+-+-+-+-+-+-+-+

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | 0x03 (1 octet)| 0x0c (1 octet)|       Reserved (2 octets)     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Reserved (2 octets)       |    Tunnel Type (2 octets)     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1. It identifies the same tunnel type.
2. It has a Tunnel Egress Endpoint sub-TLV for which one of the following two conditions holds:
   1. Its Address Family subfield contains zero, or
   2. Its Address subfield contains the address of the Next Hop field of the route to which the Tunnel Encapsulation attribute is attached.
3. It has no other sub-TLVs.

• a given packet P must be forwarded by router R;
• the path along which P is to be forwarded is determined by BGP UPDATE U;
• UPDATE U has a Tunnel Encapsulation attribute, containing at least one TLV that identifies a "feasible tunnel" for packet P. A tunnel is considered feasible if it has the following four properties:
  1. The tunnel type is supported (that is, router R knows how to set up tunnels of that type, how to create the encapsulation header for tunnels of that type, etc.).
  2. The tunnel is of a type that can be used to carry packet P (for example, an MPLS-in-UDP tunnel would not be a feasible tunnel for carrying an IP packet, unless the IP packet can first be encapsulated in a MPLS packet).
  3. The tunnel is specified in a TLV whose Tunnel Egress Endpoint sub-TLV identifies an IP address that is reachable. The reachability condition is evaluated as per [RFC 4271]. If the IP address is reachable via more than one forwarding table, local policy is used to determine which table to use.
  4. There is no local policy that prevents the use of the tunnel.

• a given packet P must be forwarded by router R1;
• the path along which P is to be forwarded is determined by BGP UPDATE U1;
• UPDATE U1 does not have a Tunnel Encapsulation attribute;
• the address of the next hop of UPDATE U1 is router R2;
• the best route to router R2 is a BGP route that was advertised in UPDATE U2; and
• UPDATE U2 has a Tunnel Encapsulation attribute.

• the Tunnel Encapsulation attribute is carried in a BGP UPDATE of an unlabeled address family,
• at least one of the attribute's TLVs identifies a tunnel type that uses a virtual network identifier, and
• it has been determined to send a packet through one of those tunnels.

• the Tunnel Encapsulation attribute is carried in a BGP UPDATE of a labeled address family,
• at least one of the attribute's TLVs identifies a tunnel type that uses a virtual network identifier, and
• it has been determined to send a packet through one of those tunnels.

• If the TLV contains an Embedded Label Handling sub-TLV whose value is 1, the embedded label (from the NLRI of the route that is carrying the Tunnel Encapsulation attribute) appears at the top of the MPLS label stack in the encapsulation payload.
• If the TLV does not contain an Embedded Label Handling sub-TLV, or it contains an Embedded Label Handling sub-TLV whose value is 2, the embedded label is ignored entirely.

• 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.
• If the TLV does not contain an Embedded Label Handling sub-TLV, or if it contains an Embedded Label Handling sub-TLV whose value is 2, the embedded label is copied into the lower 3 octets of the Virtual Network Identifier field of the encapsulation header. In this case, the payload may or may not contain an MPLS label stack, depending upon other factors. If the payload does contain an MPLS label stack, the embedded label does not appear in that stack.

• Any BGP speaker that understands it MUST be able to filter it from incoming BGP UPDATE messages.
• It MUST be possible to filter the Encapsulation Extended Community from outgoing messages.
• In both cases, this filtering MUST be enabled by default for EBGP sessions.

• "Border Gateway Protocol (BGP) Extended Communities" registry [IANA-BGP-EXT-COMM]
• "Border Gateway Protocol (BGP) Parameters" registry [IANA-BGP-PARAMS]
• "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry [IANA-BGP-TUNNEL-ENCAP]
• "Subsequent Address Family Identifiers (SAFI) Parameters" registry [IANA-SAFI]

[RFC2119]

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

[RFC2474]

K. Nichols, S. Blake, F. Baker, 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,
<https://www.rfc-editor.org/info/rfc2474>.

[RFC2784]

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

[RFC2890]

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

[RFC3032]

E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, T. Li, and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>.

[RFC3270]

F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, DOI 10.17487/RFC3270, May 2002,
<https://www.rfc-editor.org/info/rfc3270>.

[RFC3931]

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

[RFC4023]

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

[RFC4271]

Y. Rekhter, T. Li, and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.

[RFC4760]

T. Bates, R. Chandra, D. Katz, and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.

[RFC5129]

B. Davie, B. Briscoe, and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 2008,
<https://www.rfc-editor.org/info/rfc5129>.

[RFC5462]

L. Andersson, and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009,
<https://www.rfc-editor.org/info/rfc5462>.

[RFC6811]

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

[RFC6890]

M. Cotton, L. Vegoda, R. Bonica, and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013,
<https://www.rfc-editor.org/info/rfc6890>.

[RFC7348]

M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, 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,
<https://www.rfc-editor.org/info/rfc7348>.

[RFC7606]

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

[RFC7637]

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

[RFC8126]

M. Cotton, B. Leiba, and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8669]

S. Previdi, C. Filsfils, A. Lindem, A. Sreekantiah, and H. Gredler, "Segment Routing Prefix Segment Identifier Extensions for BGP", RFC 8669, DOI 10.17487/RFC8669, December 2019,
<https://www.rfc-editor.org/info/rfc8669>.

[EVPN-INTER-SUBNET]

Nokia, , , , , and , "Integrated Routing and Bridging in EVPN", Internet-Draft draft-ietf-bess-evpn-inter-subnet-forwarding-13, February 2021,
<https://tools.ietf.org/html/draft-ietf-bess-evpn-inter-subnet-forwarding-13>.

[IANA-ADDRESS-FAM]

IANA, "Address Family Numbers",
<https://www.iana.org/assignments/address-family-numbers/>.

[IANA-BGP-EXT-COMM]

IANA, "Border Gateway Protocol (BGP) Extended Communities",
<https://www.iana.org/assignments/bgp-extended-communities/>.

[IANA-BGP-PARAMS]

IANA, "Border Gateway Protocol (BGP) Parameters",
<https://www.iana.org/assignments/bgp-parameters/>.

[IANA-BGP-TUNNEL-ENCAP]

IANA, "Border Gateway Protocol (BGP) Tunnel Encapsulation",
<https://www.iana.org/assignments/bgp-tunnel-encapsulation/>.

[IANA-ETHERTYPES]

IANA, "IEEE 802 Numbers: ETHER TYPES",
<https://www.iana.org/assignments/ieee-802-numbers/>.

[IANA-SAFI]

IANA, "Subsequent Address Family Identifiers (SAFI) Parameters",
<https://www.iana.org/assignments/safi-namespace/>.

[RFC4272]

S. Murphy, "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>.

[RFC4364]

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

[RFC5512]

P. Mohapatra, 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,
<https://www.rfc-editor.org/info/rfc5512>.

[RFC5565]

J. Wu, Y. Cui, C. Metz, and E. Rosen, "Softwire Mesh Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009,
<https://www.rfc-editor.org/info/rfc5565>.

[RFC5566]

L. Berger, R. White, and E. Rosen, "BGP IPsec Tunnel Encapsulation Attribute", RFC 5566, DOI 10.17487/RFC5566, June 2009,
<https://www.rfc-editor.org/info/rfc5566>.

[RFC5640]

C. Filsfils, P. Mohapatra, and C. Pignataro, "Load-Balancing for Mesh Softwires", RFC 5640, DOI 10.17487/RFC5640, August 2009,
<https://www.rfc-editor.org/info/rfc5640>.

[RFC6514]

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

[RFC7510]

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

[RFC8205]

M. Lepinski, and K. Sriram, "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017,
<https://www.rfc-editor.org/info/rfc8205>.

[RFC8277]

E. Rosen, "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
<https://www.rfc-editor.org/info/rfc8277>.

[RFC8365]

A. Sajassi, J. Drake, N. Bitar, R. Shekhar, J. Uttaro, and W. Henderickx, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>.

[RFC8402]

C. Filsfils, S. Previdi, L. Ginsberg, B. Decraene, S. Litkowski, and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018,
<https://www.rfc-editor.org/info/rfc8402>.

Randy Bush

Robert Raszuk

Eric C. Rosen

Keyur Patel

Gunter Van de Velde

Srihari R. Sangli

John Scudder