draft-ietf-idr-tunnel-encaps-06.txt   draft-ietf-idr-tunnel-encaps-07.txt 
IDR Working Group E. Rosen, Ed. IDR Working Group E. Rosen, Ed.
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Obsoletes: 5512 (if approved) K. Patel Obsoletes: 5512 (if approved) K. Patel
Intended status: Standards Track Arrcus Intended status: Standards Track Arrcus
Expires: December 16, 2017 G. Van de Velde Expires: January 18, 2018 G. Van de Velde
Nokia Nokia
June 14, 2017 July 17, 2017
The BGP Tunnel Encapsulation Attribute The BGP Tunnel Encapsulation Attribute
draft-ietf-idr-tunnel-encaps-06 draft-ietf-idr-tunnel-encaps-07
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 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 December 16, 2017. This Internet-Draft will expire on January 18, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Brief Summary of RFC 5512 . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . . 11
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. GTP . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.5. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.6. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.6. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 15
3.2.7. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 16 3.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 16
3.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 17 3.3.1. IPv4 DS Field . . . . . . . . . . . . . . . . . . . . 16
3.3.1. IPv4 DS Field . . . . . . . . . . . . . . . . . . . . 17
3.3.2. UDP Destination Port . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . 18 3.4.2. Color Sub-TLV . . . . . . . . . . . . . . . . . . . . 17
3.5. Embedded Label Handling Sub-TLV . . . . . . . . . . . . . 18 3.5. Embedded Label Handling Sub-TLV . . . . . . . . . . . . . 17
3.6. MPLS Label Stack Sub-TLV . . . . . . . . . . . . . . . . 19 3.6. MPLS Label Stack Sub-TLV . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . 22 4.1. Encapsulation Extended Community . . . . . . . . . . . . 21
4.2. Router's MAC Extended Community . . . . . . . . . . . . . 23 4.2. Router's MAC Extended Community . . . . . . . . . . . . . 22
4.3. Color Extended Community . . . . . . . . . . . . . . . . 23 4.3. Color Extended Community . . . . . . . . . . . . . . . . 23
5. Semantics and Usage of the Tunnel Encapsulation 5. Semantics and Usage of the Tunnel Encapsulation
attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 24 attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Routing Considerations . . . . . . . . . . . . . . . . . . . 27 6. Routing Considerations . . . . . . . . . . . . . . . . . . . 27
6.1. No Impact on BGP Decision Process . . . . . . . . . . . . 27 6.1. No Impact on BGP Decision Process . . . . . . . . . . . . 27
6.2. Looping, Infinite Stacking, Etc. . . . . . . . . . . . . 28 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 8. Use of Virtual Network Identifiers and Embedded Labels
when Imposing a Tunnel Encapsulation . . . . . . . . . . . . 29 when Imposing a Tunnel Encapsulation . . . . . . . . . . . . 29
8.1. Tunnel Types without a Virtual Network Identifier 8.1. Tunnel Types without a Virtual Network Identifier
Field . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Field . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.2. Tunnel Types with a Virtual Network Identifier Field . . 30 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 . . . . . . . . . . . . . . 31 8.2.2. Labeled Address Families . . . . . . . . . . . . . . 30
8.2.2.1. When a Valid VNI has been Signaled . . . . . . . 31 8.2.2.1. When a Valid VNI has been Signaled . . . . . . . 31
8.2.2.2. When a Valid VNI has not been Signaled . . . . . 31 8.2.2.2. When a Valid VNI has not been Signaled . . . . . 31
9. Applicability Restrictions . . . . . . . . . . . . . . . . . 32 9. Applicability Restrictions . . . . . . . . . . . . . . . . . 32
10. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 33 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 33
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
12.1. Subsequent Address Family Identifiers . . . . . . . . . 34 12.1. Subsequent Address Family Identifiers . . . . . . . . . 34
12.2. BGP Path Attributes . . . . . . . . . . . . . . . . . . 34 12.2. BGP Path Attributes . . . . . . . . . . . . . . . . . . 35
12.3. Extended Communities . . . . . . . . . . . . . . . . . . 34 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 13. Security Considerations . . . . . . . . . . . . . . . . . . . 36
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
15. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 37 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 . . . . . . . . . . . . . . . . . 38
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
skipping to change at page 6, line 6 skipping to change at page 6, line 6
has a two-octet length field. has a two-octet length field.
One of the sub-TLVs defined in [RFC5512] is the "Encapsulation sub- One of the sub-TLVs defined in [RFC5512] is the "Encapsulation sub-
TLV". For a given tunnel, the encapsulation sub-TLV specifies some TLV". For a given tunnel, the encapsulation sub-TLV specifies some
of the information needed to construct the encapsulation header used of the information needed to construct the encapsulation header used
when sending packets through that tunnel. This document defines when sending packets through that tunnel. This document defines
encapsulation sub-TLVs for a number of tunnel types not discussed in encapsulation sub-TLVs for a number of tunnel types not discussed in
[RFC5512]: VXLAN (Virtual Extensible Local Area Network, [RFC7348]), [RFC5512]: VXLAN (Virtual Extensible Local Area Network, [RFC7348]),
VXLAN-GPE (Generic Protocol Extension for VXLAN, [VXLAN-GPE]), NVGRE VXLAN-GPE (Generic Protocol Extension for VXLAN, [VXLAN-GPE]), NVGRE
(Network Virtualization Using Generic Routing Encapsulation (Network Virtualization Using Generic Routing Encapsulation
[RFC7637]), GTP, and MPLS-in-GRE (MPLS in Generic Routing [RFC7637]), and MPLS-in-GRE (MPLS in Generic Routing Encapsulation
Encapsulation [RFC2784], [RFC2890], [RFC4023]). MPLS-in-UDP [RFC2784], [RFC2890], [RFC4023]). MPLS-in-UDP [RFC7510] is also
[RFC7510] is also supported, but an Encapsulation sub-TLV for it is supported, but an Encapsulation sub-TLV for it is not needed.
not needed.
Some of the encapsulations mentioned in the previous paragraph need Some of the encapsulations mentioned in the previous paragraph need
to be further encapsulated inside UDP and/or IP. [RFC5512] provides to be further encapsulated inside UDP and/or IP. [RFC5512] provides
no way to specify that certain information is to appear in these no way to specify that certain information is to appear in these
outer IP and/or UDP encapsulations. This document provides a outer IP and/or UDP encapsulations. This document provides a
framework for including such information in the TLVs of the Tunnel framework for including such information in the TLVs of the Tunnel
Encapsulation attribute. Encapsulation attribute.
When the Tunnel Encapsulation attribute is attached to a BGP UPDATE When the Tunnel Encapsulation attribute is attached to a BGP UPDATE
whose AFI/SAFI identifies one of the labeled address families, it is whose AFI/SAFI identifies one of the labeled address families, it is
skipping to change at page 7, line 25 skipping to change at page 7, line 25
Figure 1: Tunnel Encapsulation TLV Value Field Figure 1: Tunnel Encapsulation TLV Value Field
o Tunnel Type (2 octets): identifies a type of tunnel. The field o Tunnel Type (2 octets): identifies a type of tunnel. The field
contains values from the IANA Registry "BGP Tunnel Encapsulation contains values from the IANA Registry "BGP Tunnel Encapsulation
Attribute Tunnel Types". Attribute Tunnel Types".
Note that for tunnel types whose names are of the form "X-in-Y", Note that for tunnel types whose names are of the form "X-in-Y",
e.g., "MPLS-in-GRE", only packets of the specified payload type e.g., "MPLS-in-GRE", only packets of the specified payload type
"X" are to be carried through the tunnel of type "Y". This is the "X" are to be carried through the tunnel of type "Y". This is the
equivalent of specifying a tunnel type "Y" and including in its equivalent of specifying a tunnel type "Y" and including in its
TLV a Protocol Type sub-TLV (see Section 3.4.1 specifying protocol TLV a Protocol Type sub-TLV (see Section 3.4.1) specifying
protocol "X". If the tunnel type is "X-in-Y", it is unnecessary,
though harmless, to include a Protocol Type sub-TLV specifying
"X". "X".
o Length (2 octets): the total number of octets of the value field. o Length (2 octets): the total number of octets of the value field.
o Value (variable): comprised of multiple sub-TLVs. o Value (variable): comprised of multiple sub-TLVs.
Each sub-TLV consists of three fields: a 1-octet type, 1-octet Each sub-TLV consists of three fields: a 1-octet type, a 1-octet or
length, and zero or more octets of value. A sub-TLV is structured as 2-octet length field (depending on the type), and zero or more octets
shown in Figure 2: of value. A sub-TLV is structured as shown in Figure 2:
+-----------------------------------+ +-----------------------------------+
| Sub-TLV Type (1 Octet) | | Sub-TLV Type (1 Octet) |
+-----------------------------------+ +-----------------------------------+
| Sub-TLV Length (1 or 2 Octets)| | Sub-TLV Length (1 or 2 Octets)|
+-----------------------------------+ +-----------------------------------+
| Sub-TLV Value (Variable) | | Sub-TLV Value (Variable) |
| | | |
+-----------------------------------+ +-----------------------------------+
skipping to change at page 8, line 49 skipping to change at page 9, line 4
Figure 3: Remote Endpoint Sub-TLV Value Field Figure 3: Remote Endpoint Sub-TLV Value Field
The Address Family subfield contains a value from IANA's "Address The Address Family subfield contains a value from IANA's "Address
Family Numbers" registry. In this document, we assume that the Family Numbers" registry. In this document, we assume that the
Address Family is either IPv4 or IPv6; use of other address families Address Family is either IPv4 or IPv6; use of other address families
is outside the scope of this document. is outside the scope of this document.
If the Address Family subfield contains the value for IPv4, the If the Address Family subfield contains the value for IPv4, the
address subfield must contain an IPv4 address (a /32 IPv4 prefix). address subfield must contain an IPv4 address (a /32 IPv4 prefix).
In this case, the length field of Remote Endpoint sub-TLV must In this case, the length field of Remote Endpoint sub-TLV must
contain the value 10 (0xa). IPv4 broadcast addresses are not valid contain the value 10 (0xa).
values of this field.
If the Address Family subfield contains the value for IPv6, the If the Address Family subfield contains the value for IPv6, the
address sub-field must contain an IPv6 address (a /128 IPv6 prefix). address sub-field must contain an IPv6 address (a /128 IPv6 prefix).
In this case, the length field of Remote Endpoint sub-TLV must In this case, the length field of Remote Endpoint sub-TLV must
contain the value 22 (0x16). IPv6 link local addresses are not valid contain the value 22 (0x16). IPv6 link local addresses are not valid
values of the IP address field. values of the IP address field.
In a given BGP UPDATE, the address family (IPv4 or IPv6) of a Remote In a given BGP UPDATE, the address family (IPv4 or IPv6) of a Remote
Endpoint sub-TLV is independent of the address family of the UPDATE Endpoint sub-TLV is independent of the address family of the UPDATE
itself. For example, an UPDATE whose NLRI is an IPv4 address may itself. For example, an UPDATE whose NLRI is an IPv4 address may
skipping to change at page 10, line 32 skipping to change at page 10, line 35
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 5. 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 ([VXLAN-GPE]), NVGRE tunnel types: VXLAN ([RFC7348]), VXLAN-GPE ([VXLAN-GPE]), NVGRE
([RFC7637]), GTP ([GTP-U]), MPLS-in-GRE ([RFC2784], [RFC2890], ([RFC7637]), MPLS-in-GRE ([RFC2784], [RFC2890], [RFC4023]), L2TPv3
[RFC4023]), L2TPv3 ([RFC3931]), and GRE ([RFC2784], [RFC2890], ([RFC3931]), and GRE ([RFC2784], [RFC2890], [RFC4023]).
[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 Section 8. For some tunnel types, the rules given TLV are given in Sections 5 and 8.
are obvious and not mentioned in this document. There are also
tunnel types for which it is not necessary to define an Encapsulation For some tunnel types, the rules are obvious and not mentioned in
sub-TLV. this document.
There are also tunnel types for which it is not necessary to define
an Encapsulation sub-TLV, because there are no fields in the
encapsulation header whose values need to be signaled from the remote
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:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 35 skipping to change at page 11, line 41
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]. section 5 of [RFC7348].
skipping to change at page 12, line 15 skipping to change at page 12, line 18
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.
o See Section 8 to see how the VNI field of the VXLAN encapsulation o See Section 8 to see how the VNI field of the VXLAN encapsulation
header is set. header is set.
Note that in order to send an IP packet or an MPLS packet through a
VXLAN tunnel, the packet must first be encapsulated in an ethernet
header, which becomes the "inner ethernet header" described in
[RFC7348]. The VXLAN Encapsulation sub-TLV may contain information
(e.g.,the MAC address) that is used to form this ethernet header.
3.2.2. VXLAN-GPE 3.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 12, line 37 skipping to change at page 12, line 46
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: VXLAN GPE Encapsulation Sub-TLV Figure 5: 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 SHOULD always be set to zero.
Version (Ver): Indicates VXLAN GPE protocol version. If the Version (Ver): Indicates VXLAN GPE protocol version. (See the
indicated version is not supported, the TLV that contains this "Version Bits" section of [VXLAN-GPE].) If the indicated version
Encapsulation sub-TLV MUST be treated as specifying an unsupported is not supported, the TLV that contains this Encapsulation sub-TLV
tunnel type. The value of this field will be copied into the MUST be treated as specifying an unsupported tunnel type. The
corresponding field of the VXLAN encapsulation header. value of this field will be copied into the corresponding field of
the VXLAN encapsulation header.
VN-ID: If the V bit is set, this field 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 SHOULD 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 [VXLAN-GPE]. of the VXLAN-GPE header are set as per [VXLAN-GPE].
skipping to change at page 15, line 5 skipping to change at page 15, line 11
Cookie: an optional, variable length (encoded in octets -- 0 to 8 Cookie: an optional, variable length (encoded in octets -- 0 to 8
octets) value used by L2TPv3 to check the association of a octets) value used by L2TPv3 to check the association of a
received data message with the session identified by the Session received data message with the session identified by the Session
ID. Generation and usage of the cookie value is as specified in ID. Generation and usage of the cookie value is as specified in
[RFC3931]. [RFC3931].
The length of the cookie is not encoded explicitly, but can be The length of the cookie is not encoded explicitly, but can be
calculated as (sub-TLV length - 4). calculated as (sub-TLV length - 4).
3.2.5. GTP 3.2.5. GRE
When the tunnel type is GTP [GTP-U], the Encapsulation sub-TLV
contains information needed to send data packets through a GTP
tunnel, and also contains information needed by the tunnel's remote
endpoint to create a "reverse" tunnel back to the transmitter. This
allows a bidirectional control connection to be created. The format
of the Encapsulation Sub-TLV is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TEID (4 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local TEID (4 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Endpoint Address (4/16 Octets (IPv4/IPv6)) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: GTP Encapsulation Sub-TLV
Remote TEID: Contains the 32-bit Tunnel Endpoint Identifier of the
GTP tunnel through which data packets are to be sent. When data
packets are sent through the tunnel, the Remote TEID is carried in
the GTP encapsulation header. The GTP header is itself
encapsulation within an IP header, whose IP destination address
field is set to the value of the Remote Endpoint sub-TLV.
Local TEID: Contains a 32-bit Tunnel Endpoint Identifier of a GTP
tunnel assigned by EPC ([vEPC]).
Local Endpoint Address: Contains an IPv4 or IPv6 anycast address.
This is used, along with the Local TEID, to set up a tunnel in the
reverse direction. See [vEPC] for details.
3.2.6. GRE
When the tunnel type of the TLV is GRE, the following is the When the tunnel type of the TLV is GRE, the following is the
structure of the value field of the encapsulation sub-TLV: structure of the value field of 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key (4 octets) | | GRE Key (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: GRE Encapsulation Sub-TLV Figure 8: GRE Encapsulation Sub-TLV
GRE Key: 4-octet field [RFC2890] that is generated by the GRE Key: 4-octet field [RFC2890] that is generated by the
advertising router. The actual method by which the key is advertising router. The actual method by which the key is
obtained is beyond the scope of this document. The key is obtained is beyond the scope of this document. The key is
inserted into the GRE encapsulation header of the payload packets inserted into the GRE encapsulation header of the payload packets
sent by ingress routers to the advertising router. It is intended sent by ingress routers to the advertising router. It is intended
to be used for identifying extra context information about the to be used for identifying extra context information about the
received payload. received payload.
Note that the key is optional. Unless a key value is being Note that the key is optional. Unless a key value is being
advertised, the GRE encapsulation sub-TLV MUST NOT be present. advertised, the GRE encapsulation sub-TLV MUST NOT be present.
3.2.7. MPLS-in-GRE 3.2.6. MPLS-in-GRE
When the tunnel type is MPLS-in-GRE, the following is the structure When the tunnel type is MPLS-in-GRE, the following is the structure
of the value field in an optional encapsulation sub-TLV: of the value field in an optional 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE-Key (4 Octets) | | GRE-Key (4 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: MPLS-in-GRE Encapsulation Sub-TLV Figure 9: MPLS-in-GRE Encapsulation Sub-TLV
GRE-Key: 4-octet field [RFC2890] that is generated by the GRE-Key: 4-octet field [RFC2890] that is generated by the
advertising router. The actual method by which the key is advertising router. The actual method by which the key is
obtained is beyond the scope of this document. The key is obtained is beyond the scope of this document. The key is
inserted into the GRE encapsulation header of the payload packets inserted into the GRE encapsulation header of the payload packets
sent by ingress routers to the advertising router. It is intended sent by ingress routers to the advertising router. It is intended
to be used for identifying extra context information about the to be used for identifying extra context information about the
received payload. Note that the key is optional. Unless a key received payload. Note that the key is optional. Unless a key
value is being advertised, the MPLS-in-GRE encapsulation sub-TLV value is being advertised, the MPLS-in-GRE encapsulation sub-TLV
MUST NOT be present. MUST NOT be present.
Note that the GRE tunnel type defined in Section 3.2.6 can be used Note that the GRE tunnel type defined in Section 3.2.5 can be used
instead of the MPLS-in-GRE tunnel type when it is necessary to instead of the MPLS-in-GRE tunnel type when it is necessary to
encapsulate MPLS in GRE. Including a TLV of the MPLS-in-GRE tunnel encapsulate MPLS in GRE. Including a TLV of the MPLS-in-GRE tunnel
type is equivalent to including a TLV of the GRE tunnel type that type is equivalent to including a TLV of the GRE tunnel type that
also includes a Protocol Type sub-TLV ([RFC5512]) specifying MPLS as also includes a Protocol Type sub-TLV (Section 3.4.1) specifying MPLS
the protocol to be encapsulated. That is, if a TLV specifies MPLS- as the protocol to be encapsulated. That is, if a TLV specifies
in-GRE or if it includes a Protocol Type sub-TLV specifying MPLS, the MPLS-in-GRE or if it includes a Protocol Type sub-TLV specifying
GRE tunnel advertised in that TLV MUST NOT be used for carrying IP MPLS, the GRE tunnel advertised in that TLV MUST NOT be used for
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.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
skipping to change at page 19, line 39 skipping to change at page 19, line 15
label stack is pushed onto a packet, this ordering MUST be preserved. label stack is pushed onto a packet, this ordering MUST be preserved.
Each label stack entry has the following format: Each label stack entry has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL | | Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: MPLS Label Stack Sub-TLV Figure 10: MPLS Label Stack Sub-TLV
If a packet is to be sent through the tunnel identified in a If a packet is to be sent through the tunnel identified in a
particular TLV, and if that TLV contains an MPLS Label Stack sub-TLV, particular TLV, and if that TLV contains an MPLS Label Stack sub-TLV,
then the label stack appearing in the sub-TLV MUST be pushed onto the then the label stack appearing in the sub-TLV MUST be pushed onto the
packet. This label stack MUST be pushed onto the packet before any packet. This label stack MUST be pushed onto the packet before any
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
skipping to change at page 23, line 45 skipping to change at page 23, line 20
Community with the following encoding: Community with the following encoding:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x03 | 0x0b | Reserved | | 0x03 | 0x0b | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color Value | | Color Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Color Extended Community Figure 11: Color Extended Community
For the use of this Extended Community please see Section 7. For the use of this Extended Community please see Section 7.
5. Semantics and Usage of the Tunnel Encapsulation attribute 5. 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.
skipping to change at page 24, line 48 skipping to change at page 24, line 20
Suppose that: Suppose that:
o a given packet P must be forwarded by router R; o a given packet P must be forwarded by router R;
o the path along which P is to be forwarded is determined by BGP o the path along which P is to be forwarded is determined by BGP
UPDATE U; UPDATE U;
o UPDATE U has a Tunnel Encapsulation attribute, containing at least o UPDATE U has a Tunnel Encapsulation attribute, containing at least
one TLV that identifies a "feasible tunnel" for packet P. A one TLV that identifies a "feasible tunnel" for packet P. A
tunnel is considered feasible if it has the following two tunnel is considered feasible if it has the following three
properties: properties:
* The tunnel type is supported (i.e., router R knows how to set * The tunnel type is supported (i.e., router R knows how to set
up tunnels of that type, how to create the encapsulation header up tunnels of that type, how to create the encapsulation header
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).
skipping to change at page 25, line 33 skipping to change at page 24, line 51
the Color sub-TLV(Section 3.4.2) and/or the Protocol Type sub-TLV the Color sub-TLV(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 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 Switched Path SHOULD NOT be used unless none of the TLVs specifies a
feasible tunnel. 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 this happens, router R SHOULD become feasible at a later time (when its endpoint becomes
reconsider its choice of tunnel to use, and MAY choose to now use the reachable). Router R SHOULD take note of this. If router R is
tunnel. already using a different tunnel, it MAY switch to the tunnel that
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
scope of this document.
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.
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.
If it is determined to send a packet through the tunnel specified in Once it is determined to send a packet through the tunnel specified
a particular TLV of a particular Tunnel Encapsulation attribute, then in a particular TLV of a particular Tunnel Encapsulation attribute,
the tunnel's remote endpoint address is the IP address contained in then the tunnel's remote endpoint address is the IP address contained
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
value field is all zeroes, then the tunnel's remote endpoint is the value field is all zeroes, then the tunnel's remote endpoint is the
IP address specified as the Next Hop of the BGP Update containing the IP address specified as the Next Hop of the BGP Update containing the
Tunnel Encapsulation attribute. Tunnel Encapsulation attribute. The address of the remote endpoint
generally appears in a "destination address" field of the
encapsulation.
The procedure for sending a packet through a particular tunnel type The full set of procedures for sending a packet through a particular
to a particular remote endpoint depends upon the tunnel type, and is tunnel type to a particular remote endpoint depends upon the tunnel
outside the scope of this document. The contents of the tunnel type, and is outside the scope of this document. Note that some
encapsulation header MAY be influenced by the Encapsulation sub-TLV. tunnel types may require the execution of an explicit tunnel setup
protocol before they can be used for carrying data. Other tunnel
types may not require any tunnel setup protocol.
Sending a packet through a tunnel always requires that the packet be
encapsulated, with an encapsulation header that is appropriate for
the tunnel type. The contents of the tunnel encapsulation header MAY
be influenced by the Encapsulation sub-TLV. If there is no
Encapsulation sub-TLV present, the router transmitting the packet
through the tunnel must have a priori knowledge (e.g., by
provisioning) of how to fill in the various fields in the
encapsulation header.
Note that some tunnel types may require the execution of an explicit
tunnel setup protocol before they can be used for carrying data.
Other tunnel types may not require any tunnel setup protocol.
Whenever a new Tunnel Type TLV is defined, the specification of that Whenever a new Tunnel Type TLV is defined, the specification of that
TLV must describe (or reference) the procedures for creating the TLV should describe (or reference) the procedures for creating the
encapsulation header used to forward packets through that tunnel encapsulation header used to forward packets through that tunnel
type. type. If a tunnel type codepoint is assigned in the IANA "BGP Tunnel
Encapsulation Tunnel Types" registry, but there is no corresponding
specification that defines an Encapsulation sub-TLV for that tunnel
type, the transmitting endpoint of such a tunnel is presumed to know
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 SHOULD be considered
non-functional. Other means of determining whether a given tunnel is non-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
skipping to change at page 28, line 18 skipping to change at page 28, line 8
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
or intentional. It could also happen if the Tunnel Encapsulation or intentional. It could also happen if the Tunnel Encapsulation
attribute were altered by a malicious agent. Implementations should attribute were altered by a malicious agent. Implementations should
be aware of this. be aware of this. This document does not specify a maximum number of
recursions; that is an implementation-specific matter.
Improper setting (or malicious altering) of the Tunnel Encapsulation Improper setting (or malicious altering) of the Tunnel Encapsulation
attribute could also cause data packets to loop. Suppose a BGP attribute could also cause data packets to loop. Suppose a BGP
UPDATE for address prefix X carries a Tunnel Encapsulation attribute UPDATE for address prefix X carries a Tunnel Encapsulation attribute
that specifies a remote tunnel endpoint of Y. Suppose router R that specifies a remote tunnel endpoint of Y. Suppose router R
receives and processes the update. When router R receives a packet receives and processes the update. When router R receives a packet
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. The control plane itself cannot detect
this situation, though a TTL field in the payload packets would
presumably prevent any given packet from looping infinitely.
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.
7. Recursive Next Hop Resolution 7. 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;
skipping to change at page 34, line 5 skipping to change at page 33, line 41
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 SHOULD 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 SHOULD
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 SHOULD remain in
the attribute. the attribute.
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
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 -- if a TLV This document specifies one exception to this rule -- if a TLV
contains a malformed Remote Endpoint sub-TLV (as defined in contains a malformed Remote Endpoint sub-TLV (as defined in
Section 3.1, the entire TLV MUST be ignored, and SHOULD be removed Section 3.1, the entire TLV MUST be ignored, and SHOULD be removed
from the Tunnel Encapsulation attribute before the route carrying from the Tunnel Encapsulation attribute before the route carrying
that attribute is redistributed. that attribute is redistributed.
A TLV that does not contain the Remote Endpoint sub-TLV MUST be A TLV that does not contain exactly one Remote Endpoint sub-TLV MUST
treated as if it contained a malformed Remote Endpoint sub-TLV. be treated as if it contained a malformed Remote Endpoint sub-TLV.
A TLV identifying a particular tunnel type may contain a sub-TLV that 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 SHOULD be treated as no-ops. That is, they SHOULD 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
than once in a given Tunnel TLV: Remote Endpoint (discussed above),
Encapsulation, IPv4 DS, UDP Destination Port, Embedded Label
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
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,
and all the sub-TLVs SHOULD be propagated if the route carrying the
Tunnel Encapsulation attribute is propagated.
The following sub-TLVs defined in this document may appear zero or
more times in a given Tunnel TLV: Protocol Type, Color. Each
occurrence of such sub-TLVs is meaningful. For example, the Color
sub-TLV may appear multiple times to assign multiple colors to a
tunnel.
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
skipping to change at page 35, line 39 skipping to change at page 36, line 5
experimental use; IANA shall not allocate values from this range. experimental use; IANA shall not allocate values from this range.
IANA is requested to assign a codepoint, from the range 1-63 of the IANA is requested to assign a codepoint, from the range 1-63 of the
"BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, for "Remote "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, for "Remote
Endpoint", with this document being the reference. Endpoint", with this document being the reference.
IANA is requested to assign a codepoint, from the range 1-63 of the IANA is requested to assign a codepoint, from the range 1-63 of the
"BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, for "IPv4 DS "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, for "IPv4 DS
Field", with this document being the reference. Field", with this document being the reference.
IANA is requested to assign a codepoint from the "BGP Tunnel IANA is requested to assign a codepoint, from the range 1-63 of the
Encapsulation Attribute Sub-TLVs" registry for "UDP Destination "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry for "UDP
Port", with this document being the reference. Destination Port", with this document being the reference.
IANA is requested to assign a codepoint, from the range 1-63 of the IANA is requested to assign a codepoint, from the range 1-63 of the
"BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, for "Embedded "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, for "Embedded
Label Handling", with this document being the reference. Label Handling", with this document being the reference.
IANA is requested to assign a codepoint, from the range 1-63 of the IANA is requested to assign a codepoint, from the range 1-63 of the
"BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, for "MPLS "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, for "MPLS
Label Stack", with this document being the reference. Label Stack", with this document being the reference.
IANA is requested to assign a codepoint, from the range 1-63 of the IANA is requested to assign a codepoint, from the range 1-63 of the
skipping to change at page 37, line 31 skipping to change at page 37, line 45
attribute may still be used. attribute may still be used.
14. Acknowledgments 14. Acknowledgments
This document contains text from RFC5512, co-authored by Pradosh This document contains text from RFC5512, co-authored by Pradosh
Mohapatra. The authors of the current document wish to thank Pradosh Mohapatra. The authors of the current document wish to thank Pradosh
for his contribution. RFC5512 itself built upon prior work by Gargi for his contribution. RFC5512 itself built upon prior work by Gargi
Nalawade, Ruchi Kapoor, Dan Tappan, David Ward, Scott Wainner, Simon Nalawade, Ruchi Kapoor, Dan Tappan, David Ward, Scott Wainner, Simon
Barber, and Chris Metz, whom we also thank for their contributions. Barber, and Chris Metz, whom we also thank for their contributions.
The authors wish to thank Lou Berger, Ron Bonica, John Drake, Satoru The authors wish to thank Lou Berger, Ron Bonica, Martin Djaernes,
Matsushima, Dhananjaya Rao, John Scudder, Ravi Singh, Thomas Morin, John Drake, Satoru Matsushima, Dhananjaya Rao, John Scudder, Ravi
Xiaohu Xu, and Zhaohui Zhang for their review, comments, and/or Singh, Thomas Morin, Xiaohu Xu, and Zhaohui Zhang for their review,
helpful discussions. comments, and/or helpful discussions.
15. Contributor Addresses 15. 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 39, line 11 skipping to change at page 39, line 16
"IANA Ethertype Registry", "IANA Ethertype Registry",
<http://www.iana.org/assignments/ieee-802-numbers/ <http://www.iana.org/assignments/ieee-802-numbers/
ieee-802-numbers.xhtml>. ieee-802-numbers.xhtml>.
[EVPN-Inter-Subnet] [EVPN-Inter-Subnet]
Sajassi, A., Salem, S., Thoria, S., Drake, J., Rabadan, Sajassi, A., Salem, S., Thoria, S., Drake, J., Rabadan,
J., and L. Yong, "Integrated Routing and Bridging in J., and L. Yong, "Integrated Routing and Bridging in
EVPN", internet-draft draft-ietf-bess-evpn-inter-subnet- EVPN", internet-draft draft-ietf-bess-evpn-inter-subnet-
forwarding-03, February 2017. forwarding-03, February 2017.
[GTP-U] 3GPP, "GPRS Tunneling Protocol User Plane, TS 29.281",
2014.
[Prefix-SID-Attribute] [Prefix-SID-Attribute]
Previdi, S., Filsfils, C., Lindem, A., Patel, K., Previdi, S., Filsfils, C., Lindem, A., Patel, K.,
Sreekantiah, A., Ray, S., and H. Gredler, "Segment Routing Sreekantiah, A., Ray, S., and H. Gredler, "Segment Routing
Prefix SID extensions for BGP", internet-draft draft-ietf- Prefix SID extensions for BGP", internet-draft draft-ietf-
idr-bgp-prefix-sid-05, April 2016. idr-bgp-prefix-sid-06, June 2017.
[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, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>. <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,
DOI 10.17487/RFC2784, March 2000, DOI 10.17487/RFC2784, March 2000,
skipping to change at page 40, line 41 skipping to change at page 40, line 45
[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,
<http://www.rfc-editor.org/info/rfc7510>. <http://www.rfc-editor.org/info/rfc7510>.
[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,
<http://www.rfc-editor.org/info/rfc7637>. <http://www.rfc-editor.org/info/rfc7637>.
[vEPC] Matsushima, S. and R. Wakikawa, "Stateless User-Plane
Architecture for Virtualized EPC", internet-draft draft-
matsushima-stateless-uplane-vepc-06, March 2016.
[VXLAN-GPE] [VXLAN-GPE]
Kreeger, L. and U. Elzur, "Generic Protocol Extension for Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
VXLAN", internet-draft draft-ietf-nvo3-vxlan-gpe, October Extension for VXLAN", internet-draft draft-ietf-nvo3-
2016. vxlan-gpe, April 2017.
Authors' Addresses Authors' Addresses
Eric C. Rosen (editor) Eric C. Rosen (editor)
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, Massachusetts 01886
United States United States
Email: erosen@juniper.net Email: erosen@juniper.net
 End of changes. 52 change blocks. 
136 lines changed or deleted 141 lines changed or added

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