draft-ietf-idr-tunnel-encaps-10.txt   draft-ietf-idr-tunnel-encaps-11.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, Inc
Expires: February 21, 2019 G. Van de Velde Expires: August 26, 2019 G. Van de Velde
Nokia Nokia
August 20, 2018 February 22, 2019
The BGP Tunnel Encapsulation Attribute The BGP Tunnel Encapsulation Attribute
draft-ietf-idr-tunnel-encaps-10 draft-ietf-idr-tunnel-encaps-11
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 February 21, 2019. This Internet-Draft will expire on August 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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 . . . . . . . . . . . . . . . . 4 1.1. Brief Summary of RFC 5512 . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . . . . 11 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.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 . . . . . . . . . . . . . . . . 17 3.3.2. UDP Destination Port . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . 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 . . . . . . . . . . . . 21 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 . . 23
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. . . . . . . . . . . . . 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 8. Use of Virtual Network Identifiers and Embedded Labels when
when Imposing a Tunnel Encapsulation . . . . . . . . . . . . 29 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 . . 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
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
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 . . . . . . . . . . . . . . . . . . . . . 35 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
12.1. Subsequent Address Family Identifiers . . . . . . . . . 35 12.1. Subsequent Address Family Identifiers . . . . . . . . . 35
12.2. BGP Path Attributes . . . . . . . . . . . . . . . . . . 35 12.2. BGP Path Attributes . . . . . . . . . . . . . . . . . . 35
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 13. Security Considerations . . . . . . . . . . . . . . . . . . . 36
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
15. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 37 15. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 37
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
16.1. Normative References . . . . . . . . . . . . . . . . . . 38 16.1. Normative References . . . . . . . . . . . . . . . . . . 38
skipping to change at page 6, line 4 skipping to change at page 5, line 45
the range from 0 to 127 inclusive has a one-octet length field, the range from 0 to 127 inclusive has a one-octet length field,
but a sub-TLV whose type is in the range from 128 to 255 inclusive but a sub-TLV whose type is in the range from 128 to 255 inclusive
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,
(Network Virtualization Using Generic Routing Encapsulation [I-D.ietf-nvo3-vxlan-gpe]), NVGRE (Network Virtualization Using
[RFC7637]), and MPLS-in-GRE (MPLS in Generic Routing Encapsulation Generic Routing Encapsulation [RFC7637]), and MPLS-in-GRE (MPLS in
[RFC2784], [RFC2890], [RFC4023]). MPLS-in-UDP [RFC7510] is also Generic Routing Encapsulation [RFC2784], [RFC2890], [RFC4023]).
supported, but an Encapsulation sub-TLV for it is not needed. MPLS-in-UDP [RFC7510] is also supported, but an Encapsulation sub-TLV
for it is not needed.
Some of the encapsulations mentioned in the previous paragraph need 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 38 skipping to change at page 7, line 38
"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, a 1-octet or Each sub-TLV consists of three fields: a 1-octet type, a 1-octet or
2-octet length field (depending on the type), and zero or more octets 2-octet length field (depending on the type), and zero or more octets
of value. A sub-TLV is structured as 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) |
| | +--------------------------------+
+-----------------------------------+
Figure 2: Tunnel Encapsulation Sub-TLV Format Table 1: Tunnel Encapsulation Sub-TLV Format
o Sub-TLV Type (1 octet): each sub-TLV type defines a certain o Sub-TLV Type (1 octet): each sub-TLV type defines a certain
property about the tunnel TLV that contains this sub-TLV. property about the tunnel TLV that contains this sub-TLV.
o Sub-TLV Length (1 or 2 octets): the total number of octets of the o Sub-TLV Length (1 or 2 octets): the total number of octets of the
sub-TLV value field. The Sub-TLV Length field contains 1 octet if sub-TLV value field. The Sub-TLV Length field contains 1 octet if
the Sub-TLV Type field contains a value in the range from 0-127. the Sub-TLV Type field contains a value in the range from 0-127.
The Sub-TLV Length field contains two octets if the Sub-TLV Type The Sub-TLV Length field contains two octets if the Sub-TLV Type
field contains a value in the range from 128-255. field contains a value in the range from 128-255.
skipping to change at page 8, line 43 skipping to change at page 8, line 40
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Autonomous System Number | | Autonomous System Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Address ~ | Address Family | Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Remote Endpoint Sub-TLV Value Field Figure 2: 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
skipping to change at page 10, line 34 skipping to change at page 10, line 31
If the Remote Endpoint sub-TLV contains an IPv4 or IPv6 address that If the Remote Endpoint sub-TLV contains an IPv4 or IPv6 address that
is valid but not reachable, the sub-TLV is NOT considered to be is valid but not reachable, the sub-TLV is NOT considered to be
malformed, and the containing TLV SHOULD NOT be removed from the malformed, and the containing TLV SHOULD NOT be removed from the
attribute before redistribution. However, the tunnel identified by attribute before redistribution. However, the tunnel identified by
the TLV containing that sub-TLV cannot be used until such time as the the TLV containing that sub-TLV cannot be used until such time as the
address becomes reachable. See Section 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
([RFC7637]), MPLS-in-GRE ([RFC2784], [RFC2890], [RFC4023]), L2TPv3 ([I-D.ietf-nvo3-vxlan-gpe]), NVGRE ([RFC7637]), MPLS-in-GRE
([RFC3931]), and GRE ([RFC2784], [RFC2890], [RFC4023]). ([RFC2784], [RFC2890], [RFC4023]), L2TPv3 ([RFC3931]), and GRE
([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 For some tunnel types, the rules are obvious and not mentioned in
this document. 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
skipping to change at page 11, line 21 skipping to change at page 11, line 15
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|M|R|R|R|R|R|R| VN-ID (3 Octets) | |V|M|R|R|R|R|R|R| VN-ID (3 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (4 Octets) | | MAC Address (4 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (2 Octets) | Reserved | | MAC Address (2 Octets) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: 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 SHOULD always be set to 0.
skipping to change at page 12, line 38 skipping to change at page 12, line 30
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VN-ID | Reserved | | VN-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: 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 SHOULD always be set to zero.
Version (Ver): Indicates VXLAN GPE protocol version. (See the Version (Ver): Indicates VXLAN GPE protocol version. (See the
"Version Bits" section of [VXLAN-GPE].) If the indicated version "Version Bits" section of [I-D.ietf-nvo3-vxlan-gpe].) If the
is not supported, the TLV that contains this Encapsulation sub-TLV indicated version is not supported, the TLV that contains this
MUST be treated as specifying an unsupported tunnel type. The Encapsulation sub-TLV MUST be treated as specifying an unsupported
value of this field will be copied into the corresponding field of tunnel type. The value of this field will be copied into the
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 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 [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.
3.2.3. NVGRE 3.2.3. NVGRE
This document defines an encapsulation sub-TLV for NVGRE tunnels. This document defines an encapsulation sub-TLV for NVGRE tunnels.
When the tunnel type is NVGRE, the following is the structure of the When the tunnel type is NVGRE, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|M|R|R|R|R|R|R| VN-ID (3 Octets) | |V|M|R|R|R|R|R|R| VN-ID (3 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (4 Octets) | | MAC Address (4 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (2 Octets) | Reserved | | MAC Address (2 Octets) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: 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 SHOULD always be set to 0.
skipping to change at page 14, line 43 skipping to change at page 14, line 37
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID (4 octets) | | Session ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Cookie (Variable) | | Cookie (Variable) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: L2TPv3 Encapsulation Sub-TLV Figure 6: L2TPv3 Encapsulation Sub-TLV
Session ID: a non-zero 4-octet value locally assigned by the Session ID: a non-zero 4-octet value locally assigned by the
advertising router that serves as a lookup key in the incoming advertising router that serves as a lookup key in the incoming
packet's context. packet's context.
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].
skipping to change at page 15, line 22 skipping to change at page 15, line 16
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 8: GRE Encapsulation Sub-TLV Figure 7: 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
skipping to change at page 15, line 46 skipping to change at page 15, line 40
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 9: MPLS-in-GRE Encapsulation Sub-TLV Figure 8: 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.
skipping to change at page 19, line 26 skipping to change at page 19, line 18
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 10: MPLS Label Stack Sub-TLV Figure 9: 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 20, line 32 skipping to change at page 20, line 23
Note that this sub-TLV can be appear within a TLV identifying any Note that this sub-TLV can be appear within a TLV identifying any
type of tunnel, not just within a TLV identifying an MPLS tunnel. type 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
[Prefix-SID-Attribute] defines a BGP Path attribute known as the [I-D.ietf-idr-bgp-prefix-sid] defines a BGP Path attribute known as
"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-
Index" TLV, an "IPv6 SID (Segment Identifier)" TLV, or an "Originator Index" TLV, an "IPv6 SID (Segment Identifier)" TLV, or an "Originator
SRGB (Source Routing Global Block)" TLV. SRGB (Source Routing Global Block)" TLV.
In this document, we define a Prefix-SID sub-TLV. The value field of In this document, we define a Prefix-SID sub-TLV. The value field of
the Prefix-SID sub-TLV can be set to any valid value of the value the Prefix-SID sub-TLV can be set to any valid value of the value
field of a BGP Prefix-SID attribute, as defined in field of a BGP Prefix-SID attribute, as defined in
[Prefix-SID-Attribute]. [I-D.ietf-idr-bgp-prefix-sid].
The Prefix-SID sub-TLV can occur in a TLV identifying any type of The Prefix-SID sub-TLV can occur in a TLV identifying any type of
tunnel. If an Originator SRGB is specified in the sub-TLV, that SRGB tunnel. If an Originator SRGB is specified in the sub-TLV, that SRGB
MUST be interpreted to be the SRGB used by the tunnel's Remote MUST be interpreted to be the SRGB used by the tunnel's Remote
Endpoint. The Label-Index, if present, is the Segment Routing SID Endpoint. The Label-Index, if present, is the Segment Routing SID
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
skipping to change at page 22, line 5 skipping to change at page 21, line 43
the Encapsulation Extended Community identifies a particular tunnel the Encapsulation Extended Community identifies a particular tunnel
type, its semantics are exactly equivalent to the semantics of a type, its semantics are exactly equivalent to the semantics of a
Tunnel Encapsulation attribute Tunnel TLV for which the following Tunnel Encapsulation attribute Tunnel TLV for which the following
three conditions all hold: three conditions all hold:
1. it identifies the same tunnel type, 1. it identifies the same tunnel type,
2. it has a Remote Endpoint sub-TLV for which one of the following 2. it has a Remote Endpoint sub-TLV for which one of the following
two conditions holds: two conditions holds:
a. its "Address Family" subfield contains zero, or A. its "Address Family" subfield contains zero, or
b. its "Address" subfield contains the same IP address that B. its "Address" subfield contains the same IP address that
appears in the next hop field of the route to which the appears in the next hop field of the route to which the
Tunnel Encapsulation attribute is attached Tunnel Encapsulation attribute is attached
3. it has no other sub-TLVs. 3. it has no other sub-TLVs.
We will refer to such a Tunnel TLV as a "barebones" Tunnel TLV. We will refer to such a Tunnel TLV as a "barebones" Tunnel TLV.
The Encapsulation Extended Community was first defined in [RFC5512]. The Encapsulation Extended Community was first defined in [RFC5512].
While it provides only a small subset of the functionality of the While it provides only a small subset of the functionality of the
Tunnel Encapsulation attribute, it is used in a number of deployed Tunnel Encapsulation attribute, it is used in a number of deployed
skipping to change at page 23, line 10 skipping to change at page 22, line 49
type "Y". type "Y".
In the remainder of this specification, when we speak of a route as In the remainder of this specification, when we speak of a route as
containing a Tunnel Encapsulation attribute with a TLV identifying a containing a Tunnel Encapsulation attribute with a TLV identifying a
particular tunnel type, we are implicitly including the case where particular tunnel type, we are implicitly including the case where
the route contains a Tunnel Encapsulation Extended Community the route contains a Tunnel Encapsulation Extended Community
identifying that tunnel type. identifying that tunnel type.
4.2. Router's MAC Extended Community 4.2. Router's MAC Extended Community
[EVPN-Inter-Subnet] defines a Router's MAC Extended Community. This [I-D.ietf-bess-evpn-inter-subnet-forwarding] defines a Router's MAC
Extended Community provides information that may conflict with Extended Community. This Extended Community provides information
information in one or more of the Encapsulation Sub-TLVs of a Tunnel that may conflict with information in one or more of the
Encapsulation attribute. In case of such a conflict, the information Encapsulation Sub-TLVs of a Tunnel Encapsulation attribute. In case
in the Encapsulation Sub-TLV takes precedence. of such a conflict, the information in the Encapsulation Sub-TLV
takes precedence.
4.3. Color Extended Community 4.3. Color Extended Community
The Color Extended Community is a Transitive Opaque Extended The Color Extended Community is a Transitive Opaque Extended
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 11: Color Extended Community Figure 10: 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 39, line 5 skipping to change at page 39, line 5
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
16.2. Informative References 16.2. Informative References
[Ethertypes] [Ethertypes]
"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] [I-D.ietf-bess-evpn-inter-subnet-forwarding]
Sajassi, A., Salem, S., Thoria, S., Drake, J., and J. Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
Rabadan, "Integrated Routing and Bridging in EVPN", Rabadan, "Integrated Routing and Bridging in EVPN", draft-
internet-draft draft-ietf-bess-evpn-inter-subnet- ietf-bess-evpn-inter-subnet-forwarding-07 (work in
forwarding-05, July 2018. progress), February 2019.
[Prefix-SID-Attribute] [I-D.ietf-idr-bgp-prefix-sid]
Previdi, S., Filsfils, C., Lindem, A., Patel, K., Previdi, S., Filsfils, C., Lindem, A., Sreekantiah, A.,
Sreekantiah, A., and H. Gredler, "Segment Routing Prefix and H. Gredler, "Segment Routing Prefix SID extensions for
SID extensions for BGP", internet-draft draft-ietf-idr- BGP", draft-ietf-idr-bgp-prefix-sid-27 (work in progress),
bgp-prefix-sid-27, June 2018. June 2018.
[I-D.ietf-nvo3-vxlan-gpe]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work
in progress), April 2018.
[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,
<https://www.rfc-editor.org/info/rfc2474>. <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,
skipping to change at page 40, line 45 skipping to change at page 41, line 5
[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>.
[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>.
[VXLAN-GPE]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN", internet-draft draft-ietf-nvo3-
vxlan-gpe, April 2018.
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
Keyur Patel Keyur Patel
Arrcus Arrcus, Inc
2077 Gateway Pl
San Jose, CA 95110
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
 End of changes. 39 change blocks. 
80 lines changed or deleted 81 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/