draft-ietf-idr-tunnel-encaps-11.txt   draft-ietf-idr-tunnel-encaps-12.txt 
IDR Working Group E. Rosen, Ed. IDR Working Group K. Patel
Internet-Draft Juniper Networks, Inc. Internet-Draft Arrcus, Inc
Obsoletes: 5512 (if approved) K. Patel Obsoletes: 5512 (if approved) G. Van de Velde
Intended status: Standards Track Arrcus, Inc Intended status: Standards Track Nokia
Expires: August 26, 2019 G. Van de Velde Expires: November 21, 2019 S. Sangli
Nokia Juniper Networks, Inc
February 22, 2019 E. Rosen
May 20, 2019
The BGP Tunnel Encapsulation Attribute The BGP Tunnel Encapsulation Attribute
draft-ietf-idr-tunnel-encaps-11 draft-ietf-idr-tunnel-encaps-12.txt
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 the of tunnels. For each such tunnel, the attribute can provide the
information needed to create the tunnel and the corresponding information needed to create the tunnel and the corresponding
encapsulation header. The attribute can also provide information encapsulation header. The attribute can also provide information
that aids in choosing whether a particular packet is to be sent that aids in choosing whether a particular packet is to be sent
through a particular tunnel. RFC 5512 states that the attribute is through a particular tunnel. RFC 5512 states that the attribute is
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 August 26, 2019. This Internet-Draft will expire on November 21, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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
1.1. Brief Summary of RFC 5512 . . . . . . . . . . . . . . . . 3 1.1. Brief Summary of RFC 5512 . . . . . . . . . . . . . . . . 4
1.2. Deficiencies in RFC 5512 . . . . . . . . . . . . . . . . 4 1.2. Deficiencies in RFC 5512 . . . . . . . . . . . . . . . . 4
1.3. Brief Summary of Changes from RFC 5512 . . . . . . . . . 5 1.3. Brief Summary of Changes from RFC 5512 . . . . . . . . . 5
1.4. Impact on RFC 5566 . . . . . . . . . . . . . . . . . . . 6 1.4. Impact on RFC 5566 . . . . . . . . . . . . . . . . . . . 6
2. The Tunnel Encapsulation Attribute . . . . . . . . . . . . . 6 2. The Tunnel Encapsulation Attribute . . . . . . . . . . . . . 6
3. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 8 3. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 8
3.1. The Remote Endpoint Sub-TLV . . . . . . . . . . . . . . . 8 3.1. The Remote Endpoint Sub-TLV . . . . . . . . . . . . . . . 8
3.2. Encapsulation Sub-TLVs for Particular Tunnel Types . . . 10 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types . . . 10
3.2.1. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. VXLAN-GPE . . . . . . . . . . . . . . . . . . . . . . 12 3.2.2. VXLAN-GPE . . . . . . . . . . . . . . . . . . . . . . 12
3.2.3. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.3. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.4. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.4. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.5. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.5. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.6. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 15 3.2.6. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 15
3.2.7. IP-in-IP . . . . . . . . . . . . . . . . . . . . . . 16
3.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 16 3.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 16
3.3.1. IPv4 DS Field . . . . . . . . . . . . . . . . . . . . 16 3.3.1. IPv4 DS Field . . . . . . . . . . . . . . . . . . . . 16
3.3.2. UDP Destination Port . . . . . . . . . . . . . . . . 16 3.3.2. UDP Destination Port . . . . . . . . . . . . . . . . 17
3.4. Sub-TLVs for Aiding Tunnel Selection . . . . . . . . . . 17 3.4. Sub-TLVs for Aiding Tunnel Selection . . . . . . . . . . 17
3.4.1. Protocol Type Sub-TLV . . . . . . . . . . . . . . . . 17 3.4.1. Protocol Type Sub-TLV . . . . . . . . . . . . . . . . 17
3.4.2. Color Sub-TLV . . . . . . . . . . . . . . . . . . . . 17 3.4.2. Color Sub-TLV . . . . . . . . . . . . . . . . . . . . 17
3.5. Embedded Label Handling Sub-TLV . . . . . . . . . . . . . 17 3.5. Embedded Label Handling Sub-TLV . . . . . . . . . . . . . 18
3.6. MPLS Label Stack Sub-TLV . . . . . . . . . . . . . . . . 18 3.6. MPLS Label Stack Sub-TLV . . . . . . . . . . . . . . . . 19
3.7. Prefix-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 20 3.7. Prefix-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 20
4. Extended Communities Related to the Tunnel Encapsulation 4. Extended Communities Related to the Tunnel Encapsulation
Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Encapsulation Extended Community . . . . . . . . . . . . 21 4.1. Encapsulation Extended Community . . . . . . . . . . . . 21
4.2. Router's MAC Extended Community . . . . . . . . . . . . . 22 4.2. Router's MAC Extended Community . . . . . . . . . . . . . 23
4.3. Color Extended Community . . . . . . . . . . . . . . . . 23 4.3. Color Extended Community . . . . . . . . . . . . . . . . 23
5. Semantics and Usage of the Tunnel Encapsulation attribute . . 23 5. Semantics and Usage of the Tunnel Encapsulation attribute . . 23
6. Routing Considerations . . . . . . . . . . . . . . . . . . . 27 6. Routing Considerations . . . . . . . . . . . . . . . . . . . 27
6.1. No Impact on BGP Decision Process . . . . . . . . . . . . 27 6.1. Impact on BGP Decision Process . . . . . . . . . . . . . 27
6.2. Looping, Infinite Stacking, Etc. . . . . . . . . . . . . 27 6.2. Looping, Infinite Stacking, Etc. . . . . . . . . . . . . 27
7. Recursive Next Hop Resolution . . . . . . . . . . . . . . . . 28 7. Recursive Next Hop Resolution . . . . . . . . . . . . . . . . 28
8. Use of Virtual Network Identifiers and Embedded Labels when 8. Use of Virtual Network Identifiers and Embedded Labels when
Imposing a Tunnel Encapsulation . . . . . . . . . . . . . . . 29 Imposing a Tunnel Encapsulation . . . . . . . . . . . . . . . 28
8.1. Tunnel Types without a Virtual Network Identifier Field . 29 8.1. Tunnel Types without a Virtual Network Identifier Field . 29
8.2. Tunnel Types with a Virtual Network Identifier Field . . 29 8.2. Tunnel Types with a Virtual Network Identifier Field . . 29
8.2.1. Unlabeled Address Families . . . . . . . . . . . . . 30 8.2.1. Unlabeled Address Families . . . . . . . . . . . . . 30
8.2.2. Labeled Address Families . . . . . . . . . . . . . . 30 8.2.2. Labeled Address Families . . . . . . . . . . . . . . 30
9. Applicability Restrictions . . . . . . . . . . . . . . . . . 32 9. Applicability Restrictions . . . . . . . . . . . . . . . . . 31
10. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 33 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 32
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
12.1. Subsequent Address Family Identifiers . . . . . . . . . 35 12.1. Subsequent Address Family Identifiers . . . . . . . . . 34
12.2. BGP Path Attributes . . . . . . . . . . . . . . . . . . 35 12.2. BGP Path Attributes . . . . . . . . . . . . . . . . . . 34
12.3. Extended Communities . . . . . . . . . . . . . . . . . . 35 12.3. Extended Communities . . . . . . . . . . . . . . . . . . 35
12.4. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 35 12.4. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 35
12.5. Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 36 12.5. Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 36
13. Security Considerations . . . . . . . . . . . . . . . . . . . 36 12.6. Flags Field of Vxlan Encapsulation sub-TLV . . . . . . . 36
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 12.7. Flags Field of Vxlan-GPE Encapsulation sub-TLV . . . . . 36
15. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 37 12.8. Flags Field of NVGRE Encapsulation sub-TLV . . . . . . . 36
12.9. Embedded Label Handling sub-TLV . . . . . . . . . . . . 36
13. Security Considerations . . . . . . . . . . . . . . . . . . . 37
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
15. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 38
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
16.1. Normative References . . . . . . . . . . . . . . . . . . 38 16.1. Normative References . . . . . . . . . . . . . . . . . . 38
16.2. Informative References . . . . . . . . . . . . . . . . . 38 16.2. Informative References . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
This document obsoletes RFC 5512. The deficiencies of RFC 5512, and 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. 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 The material from RFC 5512 that is retained has been incorporated
into this document. into this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 10, line 9 skipping to change at page 10, line 9
o The IP address in the sub-TLV's address subfield is not a valid IP 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). address (e.g., it's an IPv4 broadcast address).
o It can be determined that the IP address in the sub-TLV's 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 whose number is in the subfield does not belong to the non-zero AS whose number is in the
its Autonomous System subfield. (See section Section 13 for its Autonomous System subfield. (See section Section 13 for
discussion of one way to determine this.) discussion of one way to determine this.)
If the Remote Endpoint sub-TLV is malformed, the TLV containing it is 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. also considered to be malformed, and the entire TLV MUST be ignored.
However, the Tunnel Encapsulation attribute SHOULD NOT be considered However, the Tunnel Encapsulation attribute MUST NOT be considered to
to be malformed in this case; other TLVs in the attribute SHOULD be be malformed in this case; other TLVs in the attribute MUST be
processed (if they can be parsed correctly). processed (if they can be parsed correctly).
When redistributing a route that is carrying a Tunnel Encapsulation When redistributing a route that is carrying a Tunnel Encapsulation
attribute containing a TLV that itself contains a malformed Remote attribute containing a TLV that itself contains a malformed Remote
Endpoint sub-TLV, the TLV SHOULD be removed from the attribute before Endpoint sub-TLV, the TLV MUST be removed from the attribute before
redistribution. redistribution.
See Section 11 for further discussion of how to handle errors that See Section 11 for further discussion of how to handle errors that
are encountered when parsing the Tunnel Encapsulation attribute. are 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.
attribute before redistribution. However, the tunnel identified by
the TLV 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 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types
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 tunnel types: VXLAN ([RFC7348]), VXLAN-GPE
([I-D.ietf-nvo3-vxlan-gpe]), NVGRE ([RFC7637]), MPLS-in-GRE ([I-D.ietf-nvo3-vxlan-gpe]), NVGRE ([RFC7637]), MPLS-in-GRE
([RFC2784], [RFC2890], [RFC4023]), L2TPv3 ([RFC3931]), and GRE ([RFC2784], [RFC2890], [RFC4023]), L2TPv3 ([RFC3931]), and GRE
([RFC2784], [RFC2890], [RFC4023]). ([RFC2784], [RFC2890], [RFC4023]).
Rules for forming the encapsulation based on the information in a Rules for forming the encapsulation based on the information in a
given TLV are given in Sections 5 and 8. given TLV are given in Sections 5 and 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 There are also tunnel types for which it is not necessary to define
an Encapsulation sub-TLV, because there are no fields in the an Encapsulation sub-TLV, because there are no fields in the
encapsulation header whose values need to be signaled from the remote encapsulation header whose values need to be signaled from the remote
endpoint. endpoint.
3.2.1. VXLAN 3.2.1. VXLAN
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, the following is the structure of the When the tunnel type is VXLAN, the following is the structure of the
value field in the encapsulation sub-TLV: value field in the encapsulation sub-TLV:
skipping to change at page 11, line 25 skipping to change at page 11, line 25
Figure 3: VXLAN Encapsulation Sub-TLV Figure 3: VXLAN Encapsulation Sub-TLV
V: This bit is set to 1 to indicate that a "valid" VN-ID (Virtual V: This bit is set to 1 to indicate that a "valid" VN-ID (Virtual
Network Identifier) is present in the encapsulation sub-TLV. Network Identifier) is present in the encapsulation sub-TLV.
Please see Section 8. Please see Section 8.
M: This bit is set to 1 to indicate that a valid MAC Address is M: This bit is set to 1 to indicate that a valid MAC Address is
present in the encapsulation sub-TLV. present in the encapsulation sub-TLV.
R: The remaining bits in the 8-bit flags field are reserved for R: The remaining bits in the 8-bit flags field are reserved for
further use. They SHOULD always be set to 0. 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 a
receipt of the sub-TLV.
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 MUST be set to
to zero. 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 MUST be
be set to all zeroes. set to all zeroes.
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]. section 5 of [RFC7348]).
If the M bit is not set, and the payload being sent through the If the M bit is not set, and the payload being sent through the
VXLAN tunnel is an ethernet frame, the Destination MAC Address VXLAN tunnel is an ethernet frame, the Destination MAC Address
field of the Inner Ethernet Header is just the Destination MAC field of the Inner Ethernet Header is just the Destination MAC
Address field of the payload's ethernet header. Address field of the payload's ethernet header.
If the M bit is not set, and the payload being sent through the 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 VXLAN tunnel is an IP or MPLS packet, the Inner Destination MAC
address field is set to a configured value; if there is no address field is set to a configured value; if there is no
configured value, the VXLAN tunnel cannot be used. configured value, the VXLAN tunnel cannot be used.
skipping to change at page 12, line 36 skipping to change at page 12, line 39
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VN-ID | Reserved | | VN-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: VXLAN GPE Encapsulation Sub-TLV Figure 4: VXLAN GPE Encapsulation Sub-TLV
V: This bit is set to 1 to indicate that a "valid" VN-ID is V: This bit is set to 1 to indicate that a "valid" VN-ID is
present in the encapsulation sub-TLV. Please see Section 8. present in the encapsulation sub-TLV. Please see Section 8.
R: The bits designated "R" above are reserved for future use. R: The bits designated "R" above are reserved for future use.
They SHOULD always be set to zero. 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 a receipt of the
sub-TLV.
Version (Ver): Indicates VXLAN GPE protocol version. (See the Version (Ver): Indicates VXLAN GPE protocol version. (See the
"Version Bits" section of [I-D.ietf-nvo3-vxlan-gpe].) If the "Version Bits" section of [I-D.ietf-nvo3-vxlan-gpe].) If the
indicated version is not supported, the TLV that contains this indicated version is not supported, the TLV that contains this
Encapsulation sub-TLV MUST be treated as specifying an unsupported Encapsulation sub-TLV MUST be treated as specifying an unsupported
tunnel type. The value of this field will be copied into the tunnel type. The value of this field will be copied into the
corresponding field of the VXLAN encapsulation header. corresponding field of the VXLAN encapsulation header.
VN-ID: If the V bit is set, this field contains a 3 octet VN-ID VN-ID: If the V bit is set, this field contains a 3 octet VN-ID
value. If the V bit is not set, this field SHOULD be set to zero. value. If the V bit is not set, this field MUST be set to zero.
When forming the VXLAN-GPE encapsulation header: When forming the VXLAN-GPE encapsulation header:
o The values of the V and R bits are NOT copied into the flags field o The values of the V and R bits are NOT copied into the flags field
of the VXLAN-GPE header. However, the values of the Ver bits are of the VXLAN-GPE header. However, the values of the Ver bits are
copied into the VXLAN-GPE header. Other bits in the flags field copied into the VXLAN-GPE header. Other bits in the flags field
of the VXLAN-GPE header are set as per [I-D.ietf-nvo3-vxlan-gpe]. of the VXLAN-GPE header are set as per [I-D.ietf-nvo3-vxlan-gpe].
o See Section 8 to see how the VNI field of the VXLAN-GPE o See Section 8 to see how the VNI field of the VXLAN-GPE
encapsulation header is set. encapsulation header is set.
skipping to change at page 13, line 35 skipping to change at page 13, line 40
Figure 5: NVGRE Encapsulation Sub-TLV Figure 5: NVGRE Encapsulation Sub-TLV
V: This bit is set to 1 to indicate that a "valid" VN-ID is V: This bit is set to 1 to indicate that a "valid" VN-ID is
present in the encapsulation sub-TLV. Please see Section 8. present in the encapsulation sub-TLV. Please see Section 8.
M: This bit is set to 1 to indicate that a valid MAC Address is M: This bit is set to 1 to indicate that a valid MAC Address is
present in the encapsulation sub-TLV. present in the encapsulation sub-TLV.
R: The remaining bits in the 8-bit flags field are reserved for R: The remaining bits in the 8-bit flags field are reserved for
further use. They SHOULD always be set to 0. 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 a
receipt of the sub-TLV.
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 MUST be set to
to zero. 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 MUST be
be set to all zeroes. 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 [RFC7637]. set as per [RFC7637].
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 3.2 of [RFC7637]. section 3.2 of [RFC7637]).
If the M bit is not set, and the payload being sent through the If the M bit is not set, and the payload being sent through the
NVGRE tunnel is an ethernet frame, the Destination MAC Address NVGRE tunnel is an ethernet frame, the Destination MAC Address
field of the Inner Ethernet Header is just the Destination MAC field of the Inner Ethernet Header is just the Destination MAC
Address field of the payload's ethernet header. Address field of the payload's ethernet header.
If the M bit is not set, and the payload being sent through the 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 NVGRE tunnel is an IP or MPLS packet, the Inner Destination MAC
address field is set to a configured value; if there is no address field is set to a configured value; if there is no
configured value, the NVGRE tunnel cannot be used. configured value, the NVGRE tunnel cannot be used.
skipping to change at page 16, line 19 skipping to change at page 16, line 23
also includes a Protocol Type sub-TLV (Section 3.4.1) specifying MPLS also includes a Protocol Type sub-TLV (Section 3.4.1) specifying MPLS
as the protocol to be encapsulated. That is, if a TLV specifies as the protocol to be encapsulated. That is, if a TLV specifies
MPLS-in-GRE or if it includes a Protocol Type sub-TLV specifying 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 MPLS, the GRE tunnel advertised in that TLV MUST NOT be used for
carrying IP packets. carrying IP packets.
While it is not really necessary to have both the GRE and MPLS-in-GRE While it is not really necessary to have both the GRE and MPLS-in-GRE
tunnel types, both are included for reasons of backwards tunnel types, both are included for reasons of backwards
compatibility. compatibility.
3.2.7. IP-in-IP
When the tunnel type of the TLV is IP-in-IP, it does not have Virtual
Network Identifier. See for Section 8.1 Embedded Label handling on
IP-in-IP tunnels.
3.3. Outer Encapsulation Sub-TLVs 3.3. Outer Encapsulation Sub-TLVs
The Encapsulation sub-TLV for a particular tunnel type allows one to The Encapsulation sub-TLV for a particular tunnel type allows one to
specify the values that are to be placed in certain fields of the specify the values that are to be placed in certain fields of the
encapsulation header for that tunnel type. However, some tunnel encapsulation header for that tunnel type. However, some tunnel
types require an outer IP encapsulation, and some also require an types require an outer IP encapsulation, and some also require an
outer UDP encapsulation. The Encapsulation sub-TLV for a given outer UDP encapsulation. The Encapsulation sub-TLV for a given
tunnel type does not usually provide a way to specify values for tunnel type does not usually provide a way to specify values for
fields of the outer IP and/or UDP encapsulations. If it is necessary fields of the outer IP and/or UDP encapsulations. If it is necessary
to specify values for fields of the outer encapsulation, additional to specify values for fields of the outer encapsulation, additional
skipping to change at page 19, line 34 skipping to change at page 19, line 46
other labels are pushed onto the packet. other labels are pushed onto the packet.
In particular, if the Tunnel Encapsulation attribute is attached to a In particular, if the Tunnel Encapsulation attribute is attached to a
BGP UPDATE of a labeled address family, the contents of the MPLS BGP UPDATE of a labeled address family, the contents of the MPLS
Label Stack sub-TLV MUST be pushed onto the packet before the label Label Stack sub-TLV MUST be pushed onto the packet before the label
embedded in the NLRI is pushed onto the packet. embedded in the NLRI is pushed onto the packet.
If the MPLS label stack sub-TLV is included in a TLV identifying a If the MPLS label stack sub-TLV is included in a TLV identifying a
tunnel type that uses virtual network identifiers (see Section 8), tunnel type that uses virtual network identifiers (see Section 8),
the contents of the MPLS label stack sub-TLV MUST be pushed onto the the contents of the MPLS label stack sub-TLV MUST be pushed onto the
packet before the procdures of Section 8 are applied. packet before the procedures of Section 8 are applied.
The number of label stack entries in the sub-TLV MUST be determined The number of label stack entries in the sub-TLV MUST be determined
from the sub-TLV length field. Thus it is not necessary to set the S from the sub-TLV length field. Thus it is not necessary to set the S
bit in any of the label stack entries of the sub-TLV, and the setting bit in any of the label stack entries of the sub-TLV, and the setting
of the S bit is ignored when parsing the sub-TLV. When the label of the S bit is ignored when parsing the sub-TLV. When the label
stack entries are pushed onto a packet that already has a label stack entries are pushed onto a packet that already has a label
stack, the S bits of all the entries MUST be cleared. When the label stack, the S bits of all the entries MUST be cleared. When the label
stack entries are pushed onto a packet that does not already have a stack entries are pushed onto a packet that does not already have a
label stack, the S bit of the bottommost label stack entry MUST be label stack, the S bit of the bottommost label stack entry MUST be
set, and the S bit of all the other label stack entries MUST be set, and the S bit of all the other label stack entries MUST be
cleared.. cleared.
By default, the TC (Traffic Class) field ([RFC3032], [RFC5462]) of By default, the TC (Traffic Class) field ([RFC3032], [RFC5462]) of
each label stack entry is set to 0. This may of course be changed by 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 policy at the originator of the sub-TLV. When pushing the label
stack onto a packet, the TC of the label stack entries is preserved stack onto a packet, the TC of the label stack entries is preserved
by default. However, local policy at the router that is pushing on by default. However, local policy at the router that is pushing on
the stack MAY cause modification of the TC values. the stack MAY cause modification of the TC values.
By default, the TTL (Time to Live) field of each label stack entry is By default, the TTL (Time to Live) field of each label stack entry is
set to 255. This may be changed by policy at the originator of the set to 255. This may be changed by policy at the originator of the
sub-TLV. When pushing the label stack onto a packet, the TTL of the sub-TLV. When pushing the label stack onto a packet, the TTL of the
label stack entries is preserved by default. However, local policy label stack entries is preserved by default. However, local policy
at the router that is pushing on the stack MAY cause modification of at the router that is pushing on the stack MAY cause modification of
the TTL values. If any label stack entry in the sub-TLV has a TTL the TTL values. If any label stack entry in the sub-TLV has a TTL
value of zero, the router that is pushing the stack on a packet MUST value of zero, the router that is pushing the stack on a packet MUST
change the value to a non-zero value. change the value to a non-zero value.
Note that this sub-TLV can be appear within a TLV identifying any Note that this sub-TLV can appear within a TLV identifying any type
type of tunnel, not just within a TLV identifying an MPLS tunnel. of tunnel, not just within a TLV identifying an MPLS tunnel.
However, if this sub-TLV appears within a TLV identifying an MPLS However, if this sub-TLV appears within a TLV identifying an MPLS
tunnel (or an MPLS-in-X tunnel), this sub-TLV plays the same role tunnel (or an MPLS-in-X tunnel), this sub-TLV plays the same role
that would be played by an MPLS Encapsulation sub-TLV. Therefore, an that would be played by an MPLS Encapsulation sub-TLV. Therefore, an
MPLS Encapsulation sub-TLV is not defined. MPLS Encapsulation sub-TLV is not defined.
3.7. Prefix-SID Sub-TLV 3.7. Prefix-SID Sub-TLV
[I-D.ietf-idr-bgp-prefix-sid] defines a BGP Path attribute known as [I-D.ietf-idr-bgp-prefix-sid] defines a BGP Path attribute known as
the "Prefix-SID Attribute". This attribute is defined to contain a the "Prefix-SID Attribute". This attribute is defined to contain a
sequence of one or more TLVs, where each TLV is either a "Label- sequence of one or more TLVs, where each TLV is either a "Label-
skipping to change at page 20, line 48 skipping to change at page 21, line 13
that the tunnel's Remote Endpoint uses to represent the prefix that the tunnel's Remote Endpoint uses to represent the prefix
appearing in the NLRI field of the BGP UPDATE to which the Tunnel appearing in the NLRI field of the BGP UPDATE to which the Tunnel
Encapsulation attribute is attached. Encapsulation attribute is attached.
If a Label-Index is present in the prefix-SID sub-TLV, then when a If a Label-Index is present in the prefix-SID sub-TLV, then when a
packet is sent through the tunnel identified by the TLV, the packet is sent through the tunnel identified by the TLV, the
corresponding MPLS label MUST be pushed on the packet's label stack. corresponding MPLS label MUST be pushed on the packet's label stack.
The corresponding MPLS label is computed from the Label-Index value The corresponding MPLS label is computed from the Label-Index value
and the SRGB of the route's originator. and the SRGB of the route's originator.
If the Originator SRGB is not present,it is assumed that the If the Originator SRGB is not present, it is assumed that the
originator's SRGB is known by other means. Such "other means" are originator's SRGB is known by other means. Such "other means" are
outside the scope of this document. outside the scope of this document.
The corresponding MPLS label is pushed on after the processing of the The corresponding MPLS label is pushed on after the processing of the
MPLS Label Stack sub-TLV, if present, as specified in Section 3.6. 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 It is pushed on before any other labels (e.g., a label embedded in
UPDATE's NLRI, or a label determined by the procedures of Section 8 UPDATE's NLRI, or a label determined by the procedures of Section 8
are pushed on the stack. are pushed on the stack.
The Prefix-SID sub-TLV has slightly different semantics than the The Prefix-SID sub-TLV has slightly different semantics than the
skipping to change at page 24, line 35 skipping to change at page 24, line 48
for tunnels of that type, etc.) for tunnels of that type, etc.)
* The tunnel is of a type that can be used to carry packet P * 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 (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 carrying an IP packet, UNLESS the IP packet can first be
converted to an MPLS packet). converted to an MPLS packet).
* The tunnel is specified in a TLV whose Remote Endpoint sub-TLV * The tunnel is specified in a TLV whose Remote Endpoint sub-TLV
identifies an IP address that is reachable. identifies an IP address that is reachable.
Then router R SHOULD send packet P through one of the feasible Then router R MUST send packet P through one of the feasible tunnels
tunnels identified in the Tunnel Encapsulation attribute of UPDATE U. 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 tunnel TLV contains one or
the Color sub-TLV(Section 3.4.2) and/or the Protocol Type sub-TLV more Color sub-TLVs (Section 3.4.2) and/or the Protocol Type sub-TLV
(Section 3.4.1, the choice of tunnel may be influenced by these sub- (Section 3.4.1), the choice of tunnel may be influenced by these sub-
TLVs. TLVs.
Note that if none of the TLVs specifies the MPLS tunnel type, a Label
Switched Path SHOULD NOT be used unless none of the TLVs specifies a
feasible tunnel.
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 its endpoint becomes become feasible at a later time (when its endpoint becomes
reachable). Router R SHOULD take note of this. If router R is reachable). Router R should take note of this. If router R is
already using a different tunnel, it MAY switch to the tunnel that already using a different tunnel, it MAY switch to the tunnel that
just became feasible, or it MAY decide to continue using the tunnel just became feasible, or it MAY decide to continue using the tunnel
that it is already using. How this decision is made is outside the that it is already using. How this decision is made is outside the
scope of this document. scope of this document.
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 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 be defined that affect the choice of tunnel to be used, or that
affect the contents of the tunnel encapsulation header. The affect the contents of the tunnel encapsulation header. The
documents that define any such additional sub-TLVs must specify the documents that define any such additional sub-TLVs must specify the
effect that including the sub-TLV is to have. effect that including the sub-TLV is to have.
Once it is determined to send a packet through the tunnel specified Once it is determined to send a packet through the tunnel specified
in a particular TLV of a particular Tunnel Encapsulation attribute, in a particular TLV of a particular Tunnel Encapsulation attribute,
then the tunnel's remote endpoint address is the IP address contained then the tunnel's remote endpoint address is the IP address contained
in the sub-TLV. If the TLV contains a Remote Endpoint sub-TLV whose in the sub-TLV. If the TLV contains a Remote Endpoint sub-TLV whose
skipping to change at page 26, line 13 skipping to change at page 26, line 17
specification that defines an Encapsulation sub-TLV for that tunnel specification that defines an Encapsulation sub-TLV for that tunnel
type, the transmitting endpoint of such a tunnel is presumed to know type, the transmitting endpoint of such a tunnel is presumed to know
a priori how to form the encapsulation header for that tunnel type. a priori how to form the encapsulation header for that tunnel type.
If a Tunnel Encapsulation attribute specifies several tunnels, the If a Tunnel Encapsulation attribute specifies several tunnels, the
way in which a router chooses which one to use is a matter of policy, 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 subject to the following constraint: if a router can determine that a
given tunnel is not functional, it MUST NOT use that tunnel. In 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 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 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 not reachable from router R, then the tunnel MUST be considered non-
non-functional. Other means of determining whether a given tunnel is functional. Other means of determining whether a given tunnel is
functional MAY be used; specification of such means is outside the functional MAY be used; specification of such means is outside the
scope of this specification. Of course, if a non-functional tunnel scope of this specification. Of course, if a non-functional tunnel
later becomes functional, router R SHOULD reevaluate its choice of later becomes functional, router R SHOULD reevaluate its choice of
tunnels. tunnels.
If router R determines that it cannot use any of the tunnels If router R determines that it cannot use any of the tunnels
specified in the Tunnel Encapsulation attribute, it MAY either drop specified in the Tunnel Encapsulation attribute, it MAY either drop
packet P, or it MAY transmit packet P as it would had the Tunnel 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 Encapsulation attribute not been present. This is a matter of local
policy. By default, the packet SHOULD be transmitted as if the policy. By default, the packet SHOULD be transmitted as if the
skipping to change at page 27, line 7 skipping to change at page 27, line 7
Notwithstanding anything said in this document, a BGP speaker MAY Notwithstanding anything said in this document, a BGP speaker MAY
have local policy that influences the choice of tunnel, and the way have local policy that influences the choice of tunnel, and the way
the encapsulation is formed. A BGP speaker MAY also have a local the encapsulation is formed. A BGP speaker MAY also have a local
policy that tells it to ignore the Tunnel Encapsulation attribute policy that tells it to ignore the Tunnel Encapsulation attribute
entirely or in part. Of course, interoperability issues must be entirely or in part. Of course, interoperability issues must be
considered when such policies are put into place. considered when such policies are put into place.
6. Routing Considerations 6. Routing Considerations
6.1. No Impact on BGP Decision Process 6.1. 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 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- The presence of the Tunnel Encapsulation attribute affects the BGP
TLV carried by a given UPDATE specifies an IP address that is bestpath selection algorithm. For all the tunnels described in the
different than the next hop of that UPDATE. Tunnel Encapsulation attribute for a path, if no Remote Tunnel
Endpoint address is feasible, then that path MUST NOT be considered
resolvable for the purposes of Route Resolvability Condition
[RFC4271] section 9.1.2.1.
6.2. Looping, Infinite Stacking, Etc. 6.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.
skipping to change at page 28, line 46 skipping to change at page 28, line 23
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 MUST be sent through one of the tunnels identified in
the Tunnel Encapsulation attribute of UPDATE U2. See Section 5 for the Tunnel Encapsulation attribute of UPDATE U2. See Section 5 for
further details. further details.
However, suppose that one of the TLVs in U2's Tunnel Encapsulation However, suppose that one of the TLVs in U2's Tunnel Encapsulation
attribute contains the Color Sub-TLV. In that case, packet P SHOULD attribute contains the Color Sub-TLV. In that case, packet P MUST
NOT be sent through the tunnel identified in that TLV, unless U1 is NOT be sent through the tunnel identified in that TLV, unless U1 is
carrying the Color Extended Community that is identified in U2's carrying the Color Extended Community that is identified in U2's
Color Sub-TLV. Color Sub-TLV.
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 5. Section 5).
The procedures in this section presuppose that U1's next hop resolves 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 to a BGP route, and that U2's next hop resolves (perhaps after
further recursion) to a non-BGP route. further recursion) to a non-BGP route.
8. Use of Virtual Network Identifiers and Embedded Labels when Imposing 8. Use of Virtual Network Identifiers and Embedded Labels when Imposing
a Tunnel Encapsulation a Tunnel Encapsulation
If the TLV specifying a tunnel contains an MPLS Label Stack sub-TLV, If the TLV specifying a tunnel contains an MPLS Label Stack sub-TLV,
then when sending a packet through that tunnel, the procedures of then when sending a packet through that tunnel, the procedures of
skipping to change at page 29, line 36 skipping to change at page 29, line 15
If the TLV specifying a tunnel contains a Prefix-SID sub-TLV, the 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 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 section. If the TLV also contains an MPLS Label Stack sub-TLV, the
procedures of Section 3.6 are applied before the procedures of procedures of Section 3.6 are applied before the procedures of
Section 3.7. Section 3.7.
8.1. Tunnel Types without a Virtual Network Identifier Field 8.1. Tunnel Types without a Virtual Network Identifier Field
If a Tunnel Encapsulation attribute is attached to an UPDATE of a If a Tunnel Encapsulation attribute is attached to an UPDATE of a
labeled address family, there will be one or more labels specified in labeled address family, there will be one or more labels specified in
the UPDATE's NLRI. When a packet is sent through a tunnel specified the UPDATE's NLRI.
in one of the attribute's TLVs, and that tunnel type does not contain
a virtual network identifier field, the label or labels from the NLRI o If the TLV contains an Embedded Label Handling sub-TLV whose value
are pushed on the packet's label stack. The resulting MPLS packet is is 1, the label or labels from the NLRI are pushed on the packet's
then further encapsulated, as specified by the TLV. label stack.
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 ignored completely. The tunnel is
assumed to have terminated at the corresponding VRF.
The resulting MPLS packet is then further encapsulated, as specified
by the TLV.
8.2. Tunnel Types with a Virtual Network Identifier Field 8.2. Tunnel Types with a Virtual Network Identifier Field
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 (Virtual Network Identifier) field; in this field is called the VNI (Virtual Network Identifier) field; in
the NVGRE encapsulation, this field is called the VSID (Virtual the NVGRE encapsulation, this field is called the VSID (Virtual
Subnet Identifier) field. Subnet Identifier) field.
skipping to change at page 31, line 50 skipping to change at page 31, line 39
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 does not contain an Embedded Label Handling sub-TLV, or 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 if it contains an Embedded Label Handling sub-TLV whose value is
2, the embedded label is copied into the virtual network 2, the embedded label is copied into the virtual network
identifier field of the encapsulation header. identifier field of the encapsulation header.
In this case, the payload may or may not contain an MPLS label In this case, the payload may or may not contain an MPLS label
stack, depending upon other factors. If the payload does contain stack, depending upon other factors. If the payload does contain
an MPLS lable stack, the embedded label does not appear in that an MPLS label stack, the embedded label does not appear in that
stack. stack.
9. Applicability Restrictions 9. 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
Section 8.2.2.1 or Section 8.2.2.2 cause the embedded label to be Section 8.2.2.1 or Section 8.2.2.2 cause the embedded label to be
carried by a data packet to the router whose address appears in the 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 Remote Endpoint sub-TLV. If the Remote Endpoint sub-TLV does not
skipping to change at page 32, line 24 skipping to change at page 32, line 12
through the tunnel may cause the label to be misinterpreted at the through the tunnel may cause the label to be misinterpreted at the
tunnel's remote endpoint. This may cause misdelivery of the packet. tunnel's remote endpoint. This may cause misdelivery of the packet.
Therefore the embedded label MUST NOT be carried by a data 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 traveling through a tunnel unless it is known that the label will be
properly interpreted at the tunnel's remote endpoint. How this is properly interpreted at the tunnel's remote endpoint. How this is
known is outside the scope of this document. known is outside the scope of this document.
Note that if the Tunnel Encapsulation attribute is attached to a VPN- 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 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 [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 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. route, it is very likely that the embedded label has been changed.
Therefore use of the Tunnel Encapsulation attribute in an "Inter-AS Therefore use of the Tunnel Encapsulation attribute in an "Inter-AS
option b" scenario is not supported. option b" scenario is not supported.
10. Scoping 10. Scoping
The Tunnel Encapsulation attribute is defined as a transitive The Tunnel Encapsulation attribute is defined as a transitive
attribute, so that it may be passed along by BGP speakers that do not attribute, so that it may be passed along by BGP speakers that do not
recognize it. However, it is intended that the Tunnel Encapsulation recognize it. However, it is intended that the Tunnel Encapsulation
skipping to change at page 33, line 32 skipping to change at page 33, line 19
it does not have the transitive bit set, the "Attribute Discard" it does not have the transitive bit set, the "Attribute Discard"
procedure of [RFC7606] is applied. procedure of [RFC7606] is applied.
If a Tunnel Encapsulation attribute can be parsed correctly, but If a Tunnel Encapsulation attribute can be parsed correctly, but
contains a TLV whose tunnel type is not recognized by a particular contains a TLV whose tunnel type is not recognized by a particular
BGP speaker, that BGP speaker MUST NOT consider the attribute to be BGP speaker, that BGP speaker MUST NOT consider the attribute to be
malformed. Rather, the TLV with the unrecognized tunnel type MUST be malformed. Rather, the TLV with the unrecognized tunnel type MUST be
ignored, and the BGP speaker MUST interpret the attribute as if that ignored, and the BGP speaker MUST interpret the attribute as if that
TLV had not been present. If the route carrying the Tunnel TLV had not been present. If the route carrying the Tunnel
Encapsulation attribute is propagated with the attribute, the Encapsulation attribute is propagated with the attribute, the
unrecognized TLV SHOULD remain in the attribute. unrecognized TLV MUST remain in the attribute.
If a TLV of a Tunnel Encapsulation attribute contains a sub-TLV that 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 is not recognized by a particular BGP speaker, the BGP speaker MUST
process that TLV as if the unrecognized sub-TLV had not been present. process that TLV as if the unrecognized sub-TLV had not been present.
If the route carrying the Tunnel Encapsulation attribute is If the route carrying the Tunnel Encapsulation attribute is
propagated with the attribute, the unrecognized TLV SHOULD remain in propagated with the attribute, the unrecognized TLV MUST remain in
the attribute. the attribute.
If the type code of a sub-TLV appears as "reserved" in the IANA "BGP If the type code of a sub-TLV appears as "reserved" in the IANA "BGP
Tunnel Encapsulation Attribute Sub-TLVs" registry, the sub-TLV MUST Tunnel Encapsulation Attribute Sub-TLVs" registry, the sub-TLV MUST
be treated as an unrecognized sub-TLV. be treated as an unrecognized sub-TLV.
In general, if a TLV contains a sub-TLV that is malformed (e.g., 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), 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. the sub-TLV should be treated as if it were an unrecognized sub-TLV.
This document specifies one exception to this rule -- within a tunnel This document specifies one exception to this rule -- within a tunnel
encapsulation attribute that is carried by a BGP UPDATE whose AFI/ encapsulation attribute that is carried by a BGP UPDATE whose AFI/
SAFI is one of those explicitly listed in the second paragraph of SAFI is one of those explicitly listed in the second paragraph of
Section 5, if a TLV contains a malformed Remote Endpoint sub-TLV (as Section 5, if a TLV contains a malformed Remote Endpoint sub-TLV (as
defined in Section 3.1, the entire TLV MUST be ignored, and SHOULD be defined in Section 3.1), the entire TLV MUST be ignored, and MUST be
removed from the Tunnel Encapsulation attribute before the route removed from the Tunnel Encapsulation attribute before the route
carrying that attribute is redistributed. carrying that attribute is redistributed.
Within a tunnel encapsulation attribute that is carried by a BGP Within a tunnel encapsulation attribute that is carried by a BGP
UPDATE whose AFI/SAFI is one of those explicitly listed in the second UPDATE whose AFI/SAFI is one of those explicitly listed in the second
paragraph of Section 5, a TLV that does not contain exactly one paragraph of Section 5, a TLV that does not contain exactly one
Remote Endpoint sub-TLV MUST be treated as if it contained a Remote Endpoint sub-TLV MUST be treated as if it contained a
malformed Remote Endpoint sub-TLV. malformed Remote Endpoint sub-TLV.
A TLV identifying a particular tunnel type may contain a sub-TLV that A TLV identifying a particular tunnel type may contain a sub-TLV that
is meaningless for that tunnel type. For example, perhaps the TLV is meaningless for that tunnel type. For example, perhaps the TLV
contains a "UDP Destination Port" sub-TLV, but the identified tunnel contains a "UDP Destination Port" sub-TLV, but the identified tunnel
type does not use UDP encapsulation at all. Sub-TLVs of this sort 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 MUST be treated as a no-op. That is, they MUST NOT affect the
creation of the encapsulation header. However, the sub-TLV MUST NOT creation of the encapsulation header. However, the sub-TLV MUST NOT
be considered to be malformed, and MUST NOT be removed from the TLV be considered to be malformed, and MUST NOT be removed from the TLV
before the route carrying the Tunnel Encapsulation attribute is before the route carrying the Tunnel Encapsulation attribute is
redistributed. (This allows for the possibility that such sub-TLVs redistributed. (This allows for the possibility that such sub-TLVs
may be given a meaning, in the context of the specified tunnel type, may be given a meaning, in the context of the specified tunnel type,
in the future.) in the future.)
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.
The following sub-TLVs defined in this document SHOULD NOT occur more The following sub-TLVs defined in this document MUST NOT occur more
than once in a given Tunnel TLV: Remote Endpoint (discussed above), than once in a given Tunnel TLV: Remote Endpoint (discussed above),
Encapsulation, IPv4 DS, UDP Destination Port, Embedded Label Encapsulation, IPv4 DS, UDP Destination Port, Embedded Label
Handling, MPLS Label Stack, Prefix-SID. If a Tunnel TLV has more Handling, MPLS Label Stack, Prefix-SID. If a Tunnel TLV has more
than one of any of these sub-TLVs, all but the first occurrence of than one of any of these sub-TLVs, all but the first occurrence of
each such sub-TLV type MUST be treated as a no-op. However, the each such sub-TLV type MUST be treated as a no-op. However, the
Tunnel TLV containing them MUST NOT be considered to be malformed, Tunnel TLV containing them MUST NOT be considered to be malformed,
and all the sub-TLVs SHOULD be propagated if the route carrying the and all the sub-TLVs MUST be propagated if the route carrying the
Tunnel Encapsulation attribute is propagated. Tunnel Encapsulation attribute is propagated.
The following sub-TLVs defined in this document may appear zero or The following sub-TLVs defined in this document may appear zero or
more times in a given Tunnel TLV: Protocol Type, Color. Each more times in a given Tunnel TLV: Protocol Type, Color. Each
occurrence of such sub-TLVs is meaningful. For example, the Color occurrence of such sub-TLVs is meaningful. For example, the Color
sub-TLV may appear multiple times to assign multiple colors to a sub-TLV may appear multiple times to assign multiple colors to a
tunnel. tunnel.
12. IANA Considerations 12. IANA Considerations
12.1. Subsequent Address Family Identifiers 12.1. Subsequent Address Family Identifiers
IANA is requested to modify the "Subsequent Address Family IANA is requested to modify the "Subsequent Address Family
Identifiers" registry to indicate that the Encapsulation SAFI is Identifiers" registry to indicate that the Encapsulation SAFI is
deprecated. This document should be the reference. deprecated. This document should be the reference.
12.2. BGP Path Attributes 12.2. BGP Path Attributes
IANA has previously assigned value 23 from the "BGP Path Attributes" IANA has previously assigned value 23 from the "BGP Path Attributes"
Registry to "Tunnel Encapsulation Attribute". IANA is requested to Registry to "Tunnel Encapsulation Attribute". IANA is requested to
skipping to change at page 36, line 29 skipping to change at page 36, line 20
12.5. Tunnel Types 12.5. Tunnel Types
IANA is requested to add this document as a reference for tunnel 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 types 8 (VXLAN), 9 (NVGRE), 11 (MPLS-in-GRE), and 12 (VXLAN-GPE) in
the "BGP Tunnel Encapsulation Tunnel Types" registry. the "BGP Tunnel Encapsulation Tunnel Types" registry.
IANA is requested to add this document as a reference for tunnel 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 types 1 (L2TPv3), 2 (GRE), and 7 (IP in IP) in the "BGP Tunnel
Encapsulation Tunnel Types" registry. Encapsulation Tunnel Types" registry.
12.6. Flags Field of Vxlan Encapsulation sub-TLV
IANA is requested to add this document as a reference for creating
the flags field of the Vxlan Encapsulation sub-TLV registry.
IANA is requested to add this document as a reference for flag bits V
and M in the "Flags field of Vxlan Encapsulation sub-TLV" registry.
12.7. Flags Field of Vxlan-GPE Encapsulation sub-TLV
IANA is requested to add this document as a reference for creating
the flags field of the Vxlan-GPE Encapsulation sub-TLV registry.
IANA is requested to add this document as a reference for flag bit V
in the "Flags field of Vxlan-GPE Encapsulation sub-TLV" registry.
12.8. Flags Field of NVGRE Encapsulation sub-TLV
IANA is requested to add this document as a reference for creating
the flags field of the NVGRE Encapsulation sub-TLV registry.
IANA is requested to add this document as a reference for flag bits V
and M in the "Flags field of NVGRE Encapsulation sub-TLV" registry.
12.9. Embedded Label Handling sub-TLV
IANA is requested to add this document as a reference for creating
the sub-TLV's value field of the Embedded Label Handling sub-TLV
registry.
IANA is requested to add this document as a reference for value of 1
(Payload of MPLS with embedded label) and 2 (no embedded label in
payload) in the "sub-TLV's value field of the Embedded Label Handling
sub-TLV" registry.
13. Security Considerations 13. Security Considerations
The Tunnel Encapsulation attribute can cause traffic to be diverted The Tunnel Encapsulation attribute can cause traffic to be diverted
from its normal path, especially when the Remote Endpoint sub-TLV is from its normal path, especially when the Remote Endpoint sub-TLV is
used. This can have serious consequences if the attribute is added used. This can have serious consequences if the attribute is added
or modified illegitimately, as it enables traffic to be "hijacked". or modified illegitimately, as it enables traffic to be "hijacked".
The Remote Endpoint sub-TLV contains both an IP address and an AS The Remote Endpoint sub-TLV contains both an IP address and an AS
number. BGP Origin Validation [RFC6811] can be used to obtain number. BGP Origin Validation [RFC6811] can be used to obtain
assurance that the given IP address belongs to the given AS. While assurance that the given IP address belongs to the given AS. While
skipping to change at page 38, line 25 skipping to change at page 38, line 42
731 Lexington Ave 731 Lexington Ave
New York City, NY 10022 New York City, NY 10022
United States United States
Email: robert@raszuk.net Email: robert@raszuk.net
16. References 16. References
16.1. Normative References 16.1. Normative References
[RFC2119] Bradner, S., "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>.
[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,
<https://www.rfc-editor.org/info/rfc5512>.
[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,
<https://www.rfc-editor.org/info/rfc7606>.
[RFC8174] Leiba, B., "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>.
16.2. Informative References
[Ethertypes]
"IANA Ethertype Registry",
<http://www.iana.org/assignments/ieee-802-numbers/
ieee-802-numbers.xhtml>.
[I-D.ietf-bess-evpn-inter-subnet-forwarding]
Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
Rabadan, "Integrated Routing and Bridging in EVPN", draft-
ietf-bess-evpn-inter-subnet-forwarding-07 (work in
progress), February 2019.
[I-D.ietf-idr-bgp-prefix-sid] [I-D.ietf-idr-bgp-prefix-sid]
Previdi, S., Filsfils, C., Lindem, A., Sreekantiah, A., Previdi, S., Filsfils, C., Lindem, A., Sreekantiah, A.,
and H. Gredler, "Segment Routing Prefix SID extensions for and H. Gredler, "Segment Routing Prefix SID extensions for
BGP", draft-ietf-idr-bgp-prefix-sid-27 (work in progress), BGP", draft-ietf-idr-bgp-prefix-sid-27 (work in progress),
June 2018. June 2018.
[I-D.ietf-nvo3-vxlan-gpe] [I-D.ietf-nvo3-vxlan-gpe]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-07 (work
in progress), April 2018. in progress), April 2019.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
"Definition of the Differentiated Services Field (DS Requirement Levels", BCP 14, RFC 2119,
Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2119, March 1997,
DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2119>.
<https://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,
DOI 10.17487/RFC2784, March 2000, DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>. <https://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, DOI 10.17487/RFC2890, September 2000, RFC 2890, DOI 10.17487/RFC2890, September 2000,
<https://www.rfc-editor.org/info/rfc2890>. <https://www.rfc-editor.org/info/rfc2890>.
skipping to change at page 40, line 5 skipping to change at page 39, line 34
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3)", "Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
RFC 3931, DOI 10.17487/RFC3931, March 2005, RFC 3931, DOI 10.17487/RFC3931, March 2005,
<https://www.rfc-editor.org/info/rfc3931>. <https://www.rfc-editor.org/info/rfc3931>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation "Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
<https://www.rfc-editor.org/info/rfc4023>. <https://www.rfc-editor.org/info/rfc4023>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Border Gateway Protocol 4 (BGP-4)", RFC 4271,
2006, <https://www.rfc-editor.org/info/rfc4364>. DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic "Multiprotocol Extensions for BGP-4", RFC 4760,
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February DOI 10.17487/RFC4760, January 2007,
2009, <https://www.rfc-editor.org/info/rfc5462>. <https://www.rfc-editor.org/info/rfc4760>.
[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,
<https://www.rfc-editor.org/info/rfc5512>.
[RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel [RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel
Encapsulation Attribute", RFC 5566, DOI 10.17487/RFC5566, Encapsulation Attribute", RFC 5566, DOI 10.17487/RFC5566,
June 2009, <https://www.rfc-editor.org/info/rfc5566>. June 2009, <https://www.rfc-editor.org/info/rfc5566>.
[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,
<https://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,
<https://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, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>. <https://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, "Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015, DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/info/rfc7510>. <https://www.rfc-editor.org/info/rfc7510>.
[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,
<https://www.rfc-editor.org/info/rfc7606>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation", Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015, RFC 7637, DOI 10.17487/RFC7637, September 2015,
<https://www.rfc-editor.org/info/rfc7637>. <https://www.rfc-editor.org/info/rfc7637>.
[RFC8174] Leiba, B., "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>.
16.2. Informative References
[Ethertypes]
"IANA Ethertype Registry",
<http://www.iana.org/assignments/ieee-802-numbers/
ieee-802-numbers.xhtml>.
[I-D.ietf-bess-evpn-inter-subnet-forwarding]
Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
Rabadan, "Integrated Routing and Bridging in EVPN", draft-
ietf-bess-evpn-inter-subnet-forwarding-08 (work in
progress), March 2019.
[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,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC4364] Rosen, E. 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>.
[RFC5462] Andersson, L. 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>.
[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,
<https://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,
<https://www.rfc-editor.org/info/rfc6811>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/info/rfc8205>. 2017, <https://www.rfc-editor.org/info/rfc8205>.
Authors' Addresses Authors' Addresses
Eric C. Rosen (editor)
Juniper Networks, Inc.
10 Technology Park Drive
Westford, Massachusetts 01886
United States
Email: erosen@juniper.net
Keyur Patel Keyur Patel
Arrcus, Inc Arrcus, Inc
2077 Gateway Pl 2077 Gateway Pl
San Jose, CA 95110 San Jose, CA 95110
United States United States
Email: keyur@arrcus.com Email: keyur@arrcus.com
Gunter Van de Velde Gunter Van de Velde
Nokia Nokia
Copernicuslaan 50 Copernicuslaan 50
Antwerpen 2018 Antwerpen 2018
Belgium Belgium
Email: gunter.van_de_velde@nokia.com Email: gunter.van_de_velde@nokia.com
Srihari R. Sangli
Juniper Networks, Inc
10 Technology Park Drive
Westford, Massachusetts 01886
United States
Email: ssangli@juniper.net
Eric C. Rosen
 End of changes. 68 change blocks. 
186 lines changed or deleted 211 lines changed or added

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