draft-rosen-idr-tunnel-encaps-02.txt   draft-rosen-idr-tunnel-encaps-03.txt 
IDR Working Group E. Rosen, Ed. IDR Working Group E. Rosen, Ed.
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Updates: 5512 (if approved) K. Patel Updates: 5512 (if approved) K. Patel
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: January 7, 2016 G. Van de Velde Expires: February 7, 2016 G. Van de Velde
Alcatel-Lucent Alcatel-Lucent
July 6, 2015 August 6, 2015
Using the BGP Tunnel Encapsulation Attribute without the BGP Using the BGP Tunnel Encapsulation Attribute without the BGP
Encapsulation SAFI Encapsulation SAFI
draft-rosen-idr-tunnel-encaps-02 draft-rosen-idr-tunnel-encaps-03
Abstract Abstract
RFC 5512 defines a BGP Path Attribute known as the "Tunnel RFC 5512 defines a BGP Path Attribute known as the "Tunnel
Encapsulation Attribute". This attribute allows one to specify a set Encapsulation Attribute". This attribute allows one to specify a set
of tunnels. For each such tunnel, the attribute can provide of tunnels. For each such tunnel, the attribute can provide
additional information used to create a tunnel and the corresponding additional information used to create a tunnel and the corresponding
encapsulation header, and can also provide information that aids in encapsulation header, and can also provide information that aids in
choosing whether a particular packet is to be sent through a choosing whether a particular packet is to be sent through a
particular tunnel. RFC 5512 states that the attribute is only particular tunnel. RFC 5512 states that the attribute is only
carried in BGP UPDATEs that have the "Encapsulation Subsequent carried in BGP UPDATEs that have the "Encapsulation Subsequent
Address Family (Encapsulation SAFI)". This document updates RFC 5512 Address Family (Encapsulation SAFI)". This document updates RFC 5512
by removing that restriction, and by specifying semantics for the by deprecating the Encapsulation SAFI (which has never been used),and
attribute when it is carried in UPDATEs of certain other SAFIs. This by specifying semantics for the attribute when it is carried in
document also extends the attribute by enabling it to carry UPDATEs of certain other SAFIs. This document also extends the
additional information needed to create the encapsulation headers attribute by enabling it to carry additional information needed to
additional tunnel types not mentioned in RFC 5512. Finally, this create the encapsulation headers additional tunnel types not
document also extends the attribute by allowing it to specify a mentioned in RFC 5512. Finally, this document also extends the
remote tunnel endpoint address for each tunnel. attribute by allowing it to specify a remote tunnel endpoint address
for each tunnel.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 7, 2016.
This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 26
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 5 2. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 5
2.1. The Remote Endpoint Sub-TLV . . . . . . . . . . . . . . . 5 2.1. The Remote Endpoint Sub-TLV . . . . . . . . . . . . . . . 5
2.2. Encapsulation Sub-TLVs for Particular Tunnel Types . . . 7 2.2. Encapsulation Sub-TLVs for Particular Tunnel Types . . . 8
2.2.1. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2. VXLAN-GPE . . . . . . . . . . . . . . . . . . . . . . 9 2.2.2. VXLAN-GPE . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.3. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.4. GTP . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.4. GTP . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.5. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 11 2.2.5. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 12
2.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 12 2.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 13
2.3.1. IPv4 DS Field . . . . . . . . . . . . . . . . . . . . 13 2.3.1. IPv4 DS Field . . . . . . . . . . . . . . . . . . . . 13
2.3.2. UDP Destination Port . . . . . . . . . . . . . . . . 13 2.3.2. UDP Destination Port . . . . . . . . . . . . . . . . 13
2.4. Embedded Label Handling Sub-TLV . . . . . . . . . . . . . 13 2.4. Embedded Label Handling Sub-TLV . . . . . . . . . . . . . 14
3. Semantics and Usage of the Tunnel Encapsulation 3. Tunnel Encapsulation Extended Community . . . . . . . . . . . 15
attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Semantics and Usage of the Tunnel Encapsulation
4. Routing Considerations . . . . . . . . . . . . . . . . . . . 17 attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. No Impact on BGP Decision Process . . . . . . . . . . . . 17 5. Routing Considerations . . . . . . . . . . . . . . . . . . . 18
4.2. Looping, Infinite Stacking, Etc. . . . . . . . . . . . . 18 5.1. No Impact on BGP Decision Process . . . . . . . . . . . . 18
5. Recursive Next Hop Resolution . . . . . . . . . . . . . . . . 18 5.2. Looping, Infinite Stacking, Etc. . . . . . . . . . . . . 19
6. Tunnel Encapsulation Extended Community . . . . . . . . . . . 19 6. Recursive Next Hop Resolution . . . . . . . . . . . . . . . . 19
7. Use of Virtual Network Identifiers and Embedded Labels 7. Use of Virtual Network Identifiers and Embedded Labels
when Imposing a Tunnel Encapsulation . . . . . . . . . . . . 19 when Imposing a Tunnel Encapsulation . . . . . . . . . . . . 20
7.1. Unlabeled Address Families . . . . . . . . . . . . . . . 20 7.1. Unlabeled Address Families . . . . . . . . . . . . . . . 20
7.2. Labeled Address Families . . . . . . . . . . . . . . . . 20 7.2. Labeled Address Families . . . . . . . . . . . . . . . . 21
7.2.1. When a Valid VNID has been Signaled . . . . . . . . . 20 7.2.1. When a Valid VNI has been Signaled . . . . . . . . . 21
7.2.2. When a Valid VNID has not been Signaled . . . . . . . 21 7.2.2. When a Valid VNI has not been Signaled . . . . . . . 22
7.2.3. Applicability Restrictions . . . . . . . . . . . . . 21 7.2.3. Applicability Restrictions . . . . . . . . . . . . . 22
8. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 22 9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
13. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 26 13. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 26
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
14.1. Normative References . . . . . . . . . . . . . . . . . . 26 14.1. Normative References . . . . . . . . . . . . . . . . . . 27
14.2. Informative References . . . . . . . . . . . . . . . . . 27 14.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
[RFC5512] defines a BGP Path Attribute known as the Tunnel [RFC5512] defines a BGP Path Attribute known as the Tunnel
Encapsulation attribute. This attribute consists of one or more Encapsulation attribute. This attribute consists of one or more
TLVs. Each TLV identifies a particular type of tunnel. Each TLV 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 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 "Encapsulation sub-TLV", contain information that may be used to form
the encapsulation header for the specified tunnel type. Other sub- the encapsulation header for the specified tunnel type. Other sub-
TLVs, e.g., the "color sub-TLV" and the "protocol sub-TLV", contain TLVs, e.g., the "color sub-TLV" and the "protocol sub-TLV", contain
skipping to change at page 4, line 5 skipping to change at page 4, line 8
to R2 through one of the tunnels specified in U's Tunnel to R2 through one of the tunnels specified in U's Tunnel
Encapsulation attribute. The IP address of the remote endpoint of Encapsulation attribute. The IP address of the remote endpoint of
each such tunnel is R2. Packet P is known as the tunnel's "payload". each such tunnel is R2. Packet P is known as the tunnel's "payload".
While the ability to specify tunnel information in a BGP UPDATE is While the ability to specify tunnel information in a BGP UPDATE is
useful, the procedures of [RFC5512] have certain limitations: useful, the procedures of [RFC5512] have certain limitations:
o The requirement to use the "Encapsulation SAFI" presents an o The requirement to use the "Encapsulation SAFI" presents an
unfortunate operational cost, as each BGP session that may need to unfortunate operational cost, as each BGP session that may need to
carry tunnel encapsulation information needs to be reconfigured to carry tunnel encapsulation information needs to be reconfigured to
support the Encapsulation SAFI. 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 o There is no way to use the Tunnel Encapsulation attribute to
specify the remote endpoint address of a given tunnel; [RFC5512] specify the remote endpoint address of a given tunnel; [RFC5512]
assumes that the remote endpoint of each tunnel is specified as assumes that the remote endpoint of each tunnel is specified as
the NLRI of an UPDATE of the Encapsulation-SAFI. the NLRI of an UPDATE of the Encapsulation-SAFI.
o If the respective best paths to two different address prefixes o If the respective best paths to two different address prefixes
have the same next hop, [RFC5512] does not provide a have the same next hop, [RFC5512] does not provide a
straightforward method to associate each prefix with a different straightforward method to associate each prefix with a different
tunnel. tunnel.
In this document we address these deficiencies by: 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 o Defining a new "Remote Endpoint Address sub-TLV" that can be
included in any of the TLVs contained in the Tunnel Encapsulation included in any of the TLVs contained in the Tunnel Encapsulation
attribute. This sub-TLV can be used to specify the remote attribute. This sub-TLV can be used to specify the remote
endpoint address of a particular tunnel. endpoint address of a particular tunnel.
o Allowing the Tunnel Encapsulation attribute to be carried by BGP o Allowing the Tunnel Encapsulation attribute to be carried by BGP
UPDATEs of additional AFI/SAFIs. Appropriate semantics are UPDATEs of additional AFI/SAFIs. Appropriate semantics are
provided for this way of using the attribute. provided for this way of using the attribute.
One of the sub-TLVs defined in [RFC5512] is the "Encapsulation sub- One of the sub-TLVs defined in [RFC5512] is the "Encapsulation sub-
skipping to change at page 6, line 41 skipping to change at page 7, line 5
setting the two high order octets to zero, and carrying the number in setting the two high order octets to zero, and carrying the number in
the two low order octets of the field. 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 AS number in the sub-TLV MUST be the number of the AS to which
the IP address in the sub-TLV belongs. the IP address in the sub-TLV belongs.
There is one special case: the Remote Endpoint sub-TLV MAY have a There is one special case: the Remote Endpoint sub-TLV MAY have a
value field whose Address Family subfield contains 0. This means value field whose Address Family subfield contains 0. This means
that the tunnel's remote endpoint is the UPDATE's BGP next hop. If that the tunnel's remote endpoint is the UPDATE's BGP next hop. If
the Address Family subfield contains 0, the Address subfield is the Address Family subfield contains 0, the Address subfield is
omitted, and the Autonomus System number field is set to 0. omitted, and the Autonomous System number field is set to 0.
If any of the following conditions hold, the Remote Endpoint sub-TLV If any of the following conditions hold, the Remote Endpoint sub-TLV
is considered to be "malformed": is considered to be "malformed":
o The sub-TLV contains the value for IPv4 in its Address Family 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 subfield, but the length of the sub-TLV's value field is other
than 10 (0xa). than 10 (0xa).
o The sub-TLV contains the value for IPv6 in its Address Family 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 subfield, but the length of the sub-TLV's value field is other
skipping to change at page 7, line 36 skipping to change at page 7, line 49
redistribution. redistribution.
See Section 9 for further discussion of how to handle errors that are See Section 9 for further discussion of how to handle errors that are
encountered when parsing the Tunnel Encapsulation attribute. encountered when parsing the Tunnel Encapsulation attribute.
If the Remote Endpoint sub-TLV contains an IPv4 or IPv6 address that 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 is valid but not reachable, the sub-TLV is NOT considered to be
malformed, and the containing TLV SHOULD NOT be removed from the malformed, and the containing TLV SHOULD NOT be removed from the
attribute before redistribution. However, the tunnel identified by attribute before redistribution. However, the tunnel identified by
the TLV containing that sub-TLV cannot be used until such time as the the TLV containing that sub-TLV cannot be used until such time as the
address becomes reachable. See Section 3. address becomes reachable. See Section 4.
2.2. Encapsulation Sub-TLVs for Particular Tunnel Types 2.2. Encapsulation Sub-TLVs for Particular Tunnel Types
Tunnel Encapsulation sub-TLVs for the following tunnel types are Tunnel Encapsulation sub-TLVs for the following tunnel types are
defined in [RFC5512]: L2TPv3, and GRE. defined in [RFC5512]: L2TPv3, and GRE.
This section defines Tunnel Encapsulation sub-TLVs for the following This section defines Tunnel Encapsulation sub-TLVs for the following
tunnel types: VXLAN ([RFC7348]), VXLAN-GPE ([VXLAN-GPE]), NVGRE tunnel types: VXLAN ([RFC7348]), VXLAN-GPE ([VXLAN-GPE]), NVGRE
([NVGRE]), GTP [GTP-U], and MPLS-in-GRE ([RFC2784], [RFC2890], ([NVGRE]), GTP [GTP-U], and MPLS-in-GRE ([RFC2784], [RFC2890],
[RFC4023]). [RFC4023]).
skipping to change at page 8, line 40 skipping to change at page 9, line 5
further use. They SHOULD always be set to 0. further use. They SHOULD always be set to 0.
VN-ID: If the V bit is set, the VN-id field contains a 3 octet VN- VN-ID: If the V bit is set, the VN-id field contains a 3 octet VN-
ID value. If the V bit is not set, the VN-id field SHOULD be set ID value. If the V bit is not set, the VN-id field SHOULD be set
to zero. to zero.
MAC Address: If the M bit is set, this field contains a 6 octet MAC Address: If the M bit is set, this field contains a 6 octet
Ethernet MAC address. If the M bit is not set, this field SHOULD Ethernet MAC address. If the M bit is not set, this field SHOULD
be set to all zeroes. be set to all zeroes.
Note that, strictly speaking, VXLAN tunnels only carry ethernet
frames. To send an IP packet or an MPLS packet through a VXLAN
tunnel, it is necessary to form an IP-in-ethernet-in-VXLAN or an
MPLS-in-ethernet-in-VXLAN tunnel.
When forming the VXLAN encapsulation header: When forming the VXLAN encapsulation header:
o The values of the V, M, and R bits are NOT copied into the flags o 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 field of the VXLAN header. The flags field of the VXLAN header is
set as per [RFC7348]. set as per [RFC7348].
o If the M bit is set, the MAC Address is copied into the Inner o If the M bit is set, the MAC Address is copied into the Inner
Destination MAC Address field of the Inner Ethernet Header (see Destination MAC Address field of the Inner Ethernet Header (see
section 5 of [RFC7348]. If the M bit is not set, the Inner section 5 of [RFC7348].
Destination MAC address field is set to a configured value. If
the M bit is not set, and there is no configured value, the VXLAN If the M bit is not set, and the payload being sent through the
tunnel cannot be used. 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 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 be used.
o See Section 7 to see how the VNI field of the VXLAN encapsulation o See Section 7 to see how the VNI field of the VXLAN encapsulation
header is set. header is set.
Note that what we are calling a "VXLAN tunnel" is actually an
"ethernet-in-VXLAN" tunnel. Although, strictly speaking, VXLAN
tunnels only carry ethernet frames, a IP packet or an MPLS packet can
be carried through a "VXLAN tunnel" by forming an IP-in-ethernet-in-
VXLAN or MPLS-in-ethernet-in-VXLAN tunnel.
2.2.2. VXLAN-GPE 2.2.2. VXLAN-GPE
This document defines an encapsulation sub-TLV for VXLAN tunnels. This document defines an encapsulation sub-TLV for VXLAN tunnels.
When the tunnel type is VXLAN-GPE, the following is the structure of When the tunnel type is VXLAN-GPE, the following is the structure of
the value field in the encapsulation sub-TLV: the value field in the encapsulation sub-TLV:
0 1 2 3 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 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 | |Ver|V|R|R|R|R|R| Reserved |
skipping to change at page 10, line 51 skipping to change at page 11, line 21
be set to all zeroes. be set to all zeroes.
When forming the NVGRE encapsulation header: When forming the NVGRE encapsulation header:
o The values of the V, M, and R bits are NOT copied into the flags o 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 VXLAN header is field of the NVGRE header. The flags field of the VXLAN header is
set as per [NVGRE]. set as per [NVGRE].
o If the M bit is set, the MAC Address is copied into the Inner o If the M bit is set, the MAC Address is copied into the Inner
Destination MAC Address field of the Inner Ethernet Header (see Destination MAC Address field of the Inner Ethernet Header (see
section 5 of [NVGRE]. If the M bit is not set, the Inner section 3.2 of [NVGRE].
Destination MAC address field is set to a configured value. If
the M bit is not set, and there is no configured value, the NVGRE
tunnel cannot be used.
o See Section 7 to see how the VNI field of the VXLAN encapsulation 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 the Inner Ethernet Header is just the Destination MAC
Address field of the payload's ethernet header.
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 is no
configured value, the NVGRE tunnel cannot be used.
o See Section 7 to see how the VSID field of the NVGRE encapsulation
header is set. header is set.
2.2.4. GTP 2.2.4. GTP
When the tunnel type is GTP [GTP-U], the Encapsulation sub-TLV When the tunnel type is GTP [GTP-U], the Encapsulation sub-TLV
contains information needed to send data packets through a GTP contains information needed to send data packets through a GTP
tunnel, and also contains information needed by the tunnel's remote tunnel, and also contains information needed by the tunnel's remote
endpoint to create a "reverse" tunnel back to the transmitter. This endpoint to create a "reverse" tunnel back to the transmitter. This
allows a bidirectional control connection to be created. The format allows a bidirectional control connection to be created. The format
of the Encapsulation Sub-TLV is: of the Encapsulation Sub-TLV is:
skipping to change at page 14, line 26 skipping to change at page 15, line 5
either in the virtual network identifier field of the either in the virtual network identifier field of the
encapsulation header, or else is ignored entirely. encapsulation header, or else is ignored entirely.
Please see Section 7 for the details of how this sub-TLV is used when Please see Section 7 for the details of how this sub-TLV is used when
it is carried by an UPDATE of a labeled address family. it is carried by an UPDATE of a labeled address family.
If the Embedded Label sub-TLV is carried by an UPDATE of a non- If the Embedded Label sub-TLV is carried by an UPDATE of a non-
labeled address family, it is treated as a no-op. However, it SHOULD labeled address family, it is treated as a no-op. However, it SHOULD
NOT be stripped from the TLV before the UPDATE is forwarded. NOT be stripped from the TLV before the UPDATE is forwarded.
3. Semantics and Usage of the Tunnel Encapsulation attribute 3. Tunnel Encapsulation Extended Community
[RFC5512] defines an Encapsulation Extended Community. This Extended
Community may be attached to a route 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 of the route to which it is attached,
and
o has no other sub-TLVs.
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.
[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. Semantics and Usage of the Tunnel Encapsulation attribute
[RFC5512] specifies the use of the Tunnel Encapsulation attribute in [RFC5512] specifies the use of the Tunnel Encapsulation attribute in
BGP UPDATE messages of AFI/SAFI 1/7 and 2/7. That document restricts 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 the use of this attribute to UPDATE messsages of those SAFIs. This
document removes that restriction. document removes that restriction.
The BGP Tunnel Encapsulation attribute MAY be carried in any BGP The BGP Tunnel Encapsulation attribute MAY be carried in any BGP
UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6 UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6
Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast), Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast),
1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast),
skipping to change at page 15, line 36 skipping to change at page 16, line 44
Then router R SHOULD send packet P through one of the feasible Then router R SHOULD send packet P through one of the feasible
tunnels identified in the Tunnel Encapsulation attribute of UPDATE U. tunnels identified in the Tunnel Encapsulation attribute of UPDATE U.
If the Tunnel Encapsulation attribute contains several TLVs (i.e., if If the Tunnel Encapsulation attribute contains several TLVs (i.e., if
it specifies several tunnels), router R may choose any one of those it specifies several tunnels), router R may choose any one of those
tunnels, based upon local policy. If any of tunnels' TLVs contain tunnels, based upon local policy. If any of tunnels' TLVs contain
the Color sub-TLV and/or the Protocol Type sub-TLV defined in the Color sub-TLV and/or the Protocol Type sub-TLV defined in
[RFC5512], the choice of tunnel may be influenced by these sub-TLVs. [RFC5512], the choice of tunnel may be influenced by these sub-TLVs.
Note that if none of the TLVs specifies the MPLS tunnel type, a Label
Switched Path SHOULD NOT be used.
If a particular tunnel is not feasible at some moment because its If a particular tunnel is not feasible at some moment because its
Remote Endpoint cannot be reached at that moment, the tunnel may Remote Endpoint cannot be reached at that moment, the tunnel may
become feasible at a later time. When this happens, router R SHOULD 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 reconsider its choice of tunnel to use, and MAY choose to now use the
tunnel. tunnel.
A TLV specifying a non-feasible tunnel is not considered to be 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 malformed or erroneous in any way, and the TLV SHOULD NOT be stripped
from the Tunnel Encapsulation attribute before redistribution. from the Tunnel Encapsulation attribute before redistribution.
skipping to change at page 17, line 13 skipping to change at page 18, line 23
etc. Choosing between two such tunnels is a matter of local policy. etc. Choosing between two such tunnels is a matter of local policy.
Once router R has decided to send packet P through a particular Once router R has decided to send packet P through a particular
tunnel, it encapsulates packet P appropriately and then forwards it tunnel, it encapsulates packet P appropriately and then forwards it
according to the route that leads to the tunnel's remote endpoint. according to the route that leads to the tunnel's remote endpoint.
This route may itself be a BGP route with a Tunnel Encapsulation This route may itself be a BGP route with a Tunnel Encapsulation
attribute. If so, the encapsulated packet is treated as the payload attribute. If so, the encapsulated packet is treated as the payload
and is encapsulated according to the Tunnel Encapsulation attribute and is encapsulated according to the Tunnel Encapsulation attribute
of that route. That is, tunnels may be "stacked". of that route. That is, tunnels may be "stacked".
4. Routing Considerations 5. Routing Considerations
4.1. No Impact on BGP Decision Process 5.1. No Impact on BGP Decision Process
The presence of the Tunnel Encapsulation attribute does not affect The presence of the Tunnel Encapsulation attribute does not affect
the BGP bestpath selection algorithm. the BGP bestpath selection algorithm.
Under certain circumstances, this may need to counter-intuitive Under certain circumstances, this may need to counter-intuitive
consequences. For example, suppose: consequences. For example, suppose:
o router R1 receives a BGP UPDATE message from router R2, such that o router R1 receives a BGP UPDATE message from router R2, such that
* the NLRI of that UPDATE is prefix X, * the NLRI of that UPDATE is prefix X,
skipping to change at page 18, line 5 skipping to change at page 19, line 13
* R1 can use at least one of the two tunnels * R1 can use at least one of the two tunnels
Since the Tunnel Encapsulation attribute does not affect bestpath Since the Tunnel Encapsulation attribute does not affect bestpath
selection, R1 may well install the route from R2 rather than the selection, R1 may well install the route from R2 rather than the
route from R3, even though R2's route contains no usable tunnels. route from R3, even though R2's route contains no usable tunnels.
This possibility must be kept in mind whenever a Remote Endpoint sub- This possibility must be kept in mind whenever a Remote Endpoint sub-
TLV carried by a given UPDATE specifies an IP address that is TLV carried by a given UPDATE specifies an IP address that is
different than the next hop of that UPDATE. different than the next hop of that UPDATE.
4.2. Looping, Infinite Stacking, Etc. 5.2. Looping, Infinite Stacking, Etc.
Consider a packet destined for address X. Suppose a BGP UPDATE for Consider a packet destined for address X. Suppose a BGP UPDATE for
address prefix X carries a Tunnel Encapsulation attribute that address prefix X carries a Tunnel Encapsulation attribute that
specifies a remote tunnel endpoint of Y. And suppose that a BGP specifies a remote tunnel endpoint of Y. And suppose that a BGP
UPDATE for address prefix Y carries a Tunnel Encapsulation attribute UPDATE for address prefix Y carries a Tunnel Encapsulation attribute
that specifies a Remote Endpoint of X. It is easy to see that this 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 will cause an infinite number of encapsulation headers to be put on
the given packet. the given packet.
This could happen as a result of misconfiguration, either accidental This could happen as a result of misconfiguration, either accidental
skipping to change at page 18, line 35 skipping to change at page 19, line 43
destined for X, it will apply the encapsulation and send the destined for X, it will apply the encapsulation and send the
encapsulated packet to Y. Y will decapsulate the packet and forward 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 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 possible that the path from Y to X will traverse R. This would cause
a long-lasting routing loop. a long-lasting routing loop.
These possibilities must also be kept in mind whenever the Remote These possibilities must also be kept in mind whenever the Remote
Endpoint for a given prefix differs from the BGP next hop for that Endpoint for a given prefix differs from the BGP next hop for that
prefix. prefix.
5. Recursive Next Hop Resolution 6. Recursive Next Hop Resolution
Suppose that: Suppose that:
o a given packet P must be forwarded by router R1; 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 o the path along which P is to be forwarded is determined by BGP
UPDATE U1; UPDATE U1;
o UPDATE U1 does not have a Tunnel Encapsulation attribute; o UPDATE U1 does not have a Tunnel Encapsulation attribute;
o the next hop of UPDATE U1 is router R2; 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 o the best path to router R2 is a BGP route that was advertised in
UPDATE U2; UPDATE U2;
o UPDATE U2 has a Tunnel Encapsulation attribute. o UPDATE U2 has a Tunnel Encapsulation attribute.
Then packet P SHOULD be sent through one of the tunnels identified in Then packet P SHOULD be sent through one of the tunnels identified in
the Tunnel Encapsulation attribute of UPDATE U2. See Section 3 for the Tunnel Encapsulation attribute of UPDATE U2. See Section 4 for
further details. further details.
Note that if UPDATE U1 and UPDATE U2 both have Tunnel Encapsulation Note that if UPDATE U1 and UPDATE U2 both have Tunnel Encapsulation
attributes, packet P will be carried through a pair of nested attributes, packet P will be carried through a pair of nested
tunnels. P will first be encapsulated based on the Tunnel tunnels. P will first be encapsulated based on the Tunnel
Encapsulation attribute of U1. This encapsulated packet then becomes Encapsulation attribute of U1. This encapsulated packet then becomes
the payload, and is encapsulated based on the Tunnel Encapsulation the payload, and is encapsulated based on the Tunnel Encapsulation
attribute of U2. This is another way of "stacking" tunnels (see also attribute of U2. This is another way of "stacking" tunnels (see also
Section 3. Section 4.
6. Tunnel Encapsulation Extended Community
[RFC5512] defines an Encapsulation Extended Community. This Extended
Community may be attached to a route 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 of the route to which it is attached,
and
o has no other sub-TLVs.
7. Use of Virtual Network Identifiers and Embedded Labels when Imposing 7. Use of Virtual Network Identifiers and Embedded Labels when Imposing
a Tunnel Encapsulation a Tunnel Encapsulation
Three of the tunnel types that can be specified in a Tunnel Three of the tunnel types that can be specified in a Tunnel
Encapsulation TLV have virtual network identifier fields in their Encapsulation TLV have virtual network identifier fields in their
encapsulation headers. In the VXLAN and VXLAN-GPE encapsulations, encapsulation headers. In the VXLAN and VXLAN-GPE encapsulations,
this field is called the VNI field; in the NVGRE encapsulation, this this field is called the VNI field; in the NVGRE encapsulation, this
field is called the VSID field. field is called the VSID field.
skipping to change at page 20, line 45 skipping to change at page 21, line 33
o the Tunnel Encapsulation attribute is carried on a BGP UPDATE of a o the Tunnel Encapsulation attribute is carried on a BGP UPDATE of a
labeled address family, and labeled address family, and
o at least one of the attribute's TLVs identifies a tunnel type that o at least one of the attribute's TLVs identifies a tunnel type that
uses a virtual network identifier, and uses a virtual network identifier, and
o it has been determined to send a packet through one of those o it has been determined to send a packet through one of those
tunnels. tunnels.
7.2.1. When a Valid VNID has been Signaled 7.2.1. When a Valid VNI has been Signaled
If the TLV identifying the tunnel contains an Encapsulation sub-TLV If the TLV identifying the tunnel contains an Encapsulation sub-TLV
whose V bit is set, the virtual network identifier field of the whose V bit is set, the virtual network identifier field of the
encapsulation header is set as follows: encapsulation header is set as follows:
o If the TLV does not contain an Embedded Label Handling sub-TLV, or o If the TLV contains an Embedded Label Handling sub-TLV whose value
if it contains an Embedded Label Handling sub-TLV whose value is is 1, then the virtual network identifier field of the
1, then the virtual network identifier field of the encapsulation encapsulation header is set to the value of the virtual network
header is set to the value of the virtual network identifier field identifier field of the Encapsulation sub-TLV.
of the Encapsulation sub-TLV.
The embedded label (from the NLRI of the route that is carrying The embedded label (from the NLRI of the route that is carrying
the Tunnel Encapsulation attribute) appears at the top of the MPLS the Tunnel Encapsulation attribute) appears at the top of the MPLS
label stack in the encapsulation payload. label stack in the encapsulation payload.
o If the TLV contains an Embedded Label Handling sub-TLV whose value o If the TLV does not contain an Embedded Label Handling sub-TLV, or
is 2, the embedded label is ignored entirely, and the virtual if contains an Embedded Label Handling sub-TLV whose value is 2,
network identifier field of the encapsulation header is set to the the embedded label is ignored entirely, and the virtual network
value of the virtual network identifier field of the Encapsulation identifier field of the encapsulation header is set to the value
sub-TLV. of the virtual network identifier field of the Encapsulation sub-
TLV.
7.2.2. When a Valid VNID has not been Signaled 7.2.2. When a Valid VNI has not been Signaled
If the TLV identifying the tunnel does not contain an Encapsulation If the TLV identifying the tunnel does not contain an Encapsulation
sub-TLV whose V bit is set, the virtual network identifier field of sub-TLV whose V bit is set, the virtual network identifier field of
the encapsulation header is set as follows: the encapsulation header is set as follows:
o If the TLV does not contain an Embedded Label Handling sub-TLV, or o If the TLV contains an Embedded Label Handling sub-TLV whose value
if it contains an Embedded Label Handling sub-TLV whose value is is 1, then the virtual network identifier field of the
1, then the virtual network identifier field of the encapsulation encapsulation header is set to a configured value.
header is set to a configured value.
If there is no configured value, the tunnel cannot be used. If there is no configured value, the tunnel cannot be used.
The embedded label (from the NLRI of the route that is carrying The embedded label (from the NLRI of the route that is carrying
the Tunnel Encapsulation attribute) appears at the top of the MPLS the Tunnel Encapsulation attribute) appears at the top of the MPLS
label stack in the encapsulation payload. label stack in the encapsulation payload.
o If the TLV contains an Embedded Label Handling sub-TLV whose value o If the TLV does not contain an Embedded Label Handling sub-TLV, or
is 2, the embedded label is copied into the virtual network 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. identifier field of the encapsulation header.
The embedded label does not appear in the MPLS label stack of the The embedded label does not appear in the MPLS label stack of the
payload. payload.
7.2.3. Applicability Restrictions 7.2.3. Applicability Restrictions
In a given UPDATE of a labeled address family, the label embedded in 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 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 whose address appears as the next hop. Certain of the procedures of
skipping to change at page 24, line 12 skipping to change at page 24, line 50
before the route carrying the Tunnel Encapsulation attribute is before the route carrying the Tunnel Encapsulation attribute is
redistributed. redistributed.
There is no significance to the order in which the TLVs occur within There is no significance to the order in which the TLVs occur within
the Tunnel Encapsulation attribute. Multiple TLVs may occur for a the Tunnel Encapsulation attribute. Multiple TLVs may occur for a
given tunnel type; each such TLV is regarded as describing a given tunnel type; each such TLV is regarded as describing a
different tunnel. different tunnel.
10. IANA Considerations 10. IANA Considerations
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.
IANA is requested to change the registration policy of the "BGP IANA is requested to change the registration policy of the "BGP
Tunnel Encapsulation Attribute Sub-TLVs" registry to the following: Tunnel Encapsulation Attribute Sub-TLVs" registry to the following:
o The values 0 and 255 are reserved. o The values 0 and 255 are reserved.
o The values in the range 1-127 are to be allocated using the o The values in the range 1-127 are to be allocated using the
"Standards Action" registration procedure. "Standards Action" registration procedure.
o The values in the range 128-251 are to be allocated using the o The values in the range 128-251 are to be allocated using the
"First Come, First Served" registration procedure. "First Come, First Served" registration procedure.
skipping to change at page 26, line 8 skipping to change at page 26, line 42
If BGP Origin Validation is used as specified above, and the tunnel If BGP Origin Validation is used as specified above, and the tunnel
specified in a particular TLV of a Tunnel Encapsulation attribute is specified in a particular TLV of a Tunnel Encapsulation attribute is
therefore regarded as "suspicious", that tunnel should not be used. therefore regarded as "suspicious", that tunnel should not be used.
Other tunnels specified in (other TLVs of) the Tunnel Encapsulation Other tunnels specified in (other TLVs of) the Tunnel Encapsulation
attribute may still be used. attribute may still be used.
12. Acknowledgments 12. Acknowledgments
The authors wish to think Ron Bonica, John Drake, Satoru Matushima, The authors wish to think Ron Bonica, John Drake, Satoru Matushima,
Dhananjaya Rao, John Scudder, and Ravi Singh for their review, Dhananjaya Rao, John Scudder, Ravi Singh, Thomas Morin, and Xiaohu Xu
comments, and/or helpful discussions. for their review, comments, and/or helpful discussions.
13. Contributor Addresses 13. Contributor Addresses
Below is a list of other contributing authors in alphabetical order: Below is a list of other contributing authors in alphabetical order:
Randy Bush Randy Bush
Internet Initiative Japan Internet Initiative Japan
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, Washington 98110 Bainbridge Island, Washington 98110
United States United States
skipping to change at page 26, line 41 skipping to change at page 27, line 31
14. References 14. References
14.1. Normative References 14.1. Normative References
[ERRORS] Chen, E., Scudder, J., Mohapatra, P., and K. Patel, [ERRORS] Chen, E., Scudder, J., Mohapatra, P., and K. Patel,
"Revised Error Handling for BGP UPDATE Messages", "Revised Error Handling for BGP UPDATE Messages",
internet-draft draft-ietf-idr-error-handling-19, April internet-draft draft-ietf-idr-error-handling-19, April
2015. 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP Subsequent Address Family Identifier (SAFI) and the BGP
Tunnel Encapsulation Attribute", RFC 5512, April 2009. Tunnel Encapsulation Attribute", RFC 5512,
DOI 10.17487/RFC5512, April 2009,
<http://www.rfc-editor.org/info/rfc5512>.
14.2. Informative References 14.2. Informative References
[BGPSEC] Lepinski, M. and S. Turner, "An Overview of BGPsec", [BGPSEC] Lepinski, M. and S. Turner, "An Overview of BGPsec",
internet-draft draft-ietf-sidr-bgpsec-overview, January internet-draft draft-ietf-sidr-bgpsec-overview, January
2015. 2015.
[EVPN-Inter-Subnet]
Sajassi, A., "Integrated Routing and Bridging in EVPN",
internet-draft draft-ietf-bess-evpn-inter-subnet-
forwarding, November 2014.
[GTP-U] 3GPP, "GPRS Tunneling Protocol User Plane, TS 29.281", [GTP-U] 3GPP, "GPRS Tunneling Protocol User Plane, TS 29.281",
2014. 2014.
[NVGRE] Garg, P. and Y. Wang, "NVGRE: Network Virtualization using [NVGRE] Garg, P. and Y. Wang, "NVGRE: Network Virtualization using
Generic Routing Encapsulation", internet-draft draft- Generic Routing Encapsulation", internet-draft draft-
sridharan-virtualization-nvgre, April 2015. sridharan-virtualization-nvgre, April 2015.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December Field) in the IPv4 and IPv6 Headers", RFC 2474,
1998. DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000. DOI 10.17487/RFC2784, March 2000,
<http://www.rfc-editor.org/info/rfc2784>.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000. RFC 2890, DOI 10.17487/RFC2890, September 2000,
<http://www.rfc-editor.org/info/rfc2890>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
MPLS in IP or Generic Routing Encapsulation (GRE)", RFC "Encapsulating MPLS in IP or Generic Routing Encapsulation
4023, March 2005. (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 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811, January Austein, "BGP Prefix Origin Validation", RFC 6811,
2013. DOI 10.17487/RFC6811, January 2013,
<http://www.rfc-editor.org/info/rfc6811>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, August 2014. 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, [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510, April 2015. "Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015,
<http://www.rfc-editor.org/info/rfc7510>.
[vEPC] Matsushima, S. and R. Wakikawa, "Stateless User-Plane [vEPC] Matsushima, S. and R. Wakikawa, "Stateless User-Plane
Architecture for Virtualized EPC", internet-draft draft- Architecture for Virtualized EPC", internet-draft draft-
matsushima-stateless-uplane-vepc-04, March 2015. matsushima-stateless-uplane-vepc-04, March 2015.
[VXLAN-GPE] [VXLAN-GPE]
Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F.,
Smith, M., Agarwal, P., Xu, X., Elzur, U., Garg, P., Smith, M., Agarwal, P., Xu, X., Elzur, U., Garg, P.,
Melman, D., and R. Manur, "Generic Protocol Extension for Melman, D., and R. Manur, "Generic Protocol Extension for
VXLAN", internet-draft draft-ietf-nvo3-vxlan-gpe, May VXLAN", internet-draft draft-ietf-nvo3-vxlan-gpe, May
 End of changes. 49 change blocks. 
111 lines changed or deleted 164 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/