draft-ietf-idr-tunnel-encaps-05.txt   draft-ietf-idr-tunnel-encaps-06.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: November 24, 2017 G. Van de Velde Expires: December 16, 2017 G. Van de Velde
Nokia Nokia
May 23, 2017 June 14, 2017
The BGP Tunnel Encapsulation Attribute The BGP Tunnel Encapsulation Attribute
draft-ietf-idr-tunnel-encaps-05 draft-ietf-idr-tunnel-encaps-06
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
only carried in BGP UPDATEs that have the "Encapsulation Subsequent only carried in BGP UPDATEs that have the "Encapsulation Subsequent
Address Family (Encapsulation SAFI)". This document deprecates the Address Family (Encapsulation SAFI)". This document deprecates the
Encapsulation SAFI (which has never been used), and specifies Encapsulation SAFI (which has never been used in production), and
semantics for the attribute when it is carried in UPDATEs of certain specifies semantics for the attribute when it is carried in UPDATEs
other SAFIs. This document adds support for additional tunnel types, of certain other SAFIs. This document adds support for additional
and allows a remote tunnel endpoint address to be specified for each tunnel types, and allows a remote tunnel endpoint address to be
tunnel. This document also provides support for specifying fields of specified for each tunnel. This document also provides support for
any inner or outer encapsulations that may be used by a particular specifying fields of any inner or outer encapsulations that may be
tunnel. used by a particular tunnel.
This document obsoletes RFC 5512. This document obsoletes RFC 5512.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 24, 2017. This Internet-Draft will expire on December 16, 2017.
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 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . 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
2. The Tunnel Encapsulation Attribute . . . . . . . . . . . . . 6 2. The Tunnel Encapsulation Attribute . . . . . . . . . . . . . 6
3. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 7 3. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 8
3.1. The Remote Endpoint Sub-TLV . . . . . . . . . . . . . . . 8 3.1. The Remote Endpoint Sub-TLV . . . . . . . . . . . . . . . 8
3.2. Encapsulation Sub-TLVs for Particular Tunnel Types . . . 10 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types . . . 10
3.2.1. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. VXLAN-GPE . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2. VXLAN-GPE . . . . . . . . . . . . . . . . . . . . . . 12
3.2.3. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.3. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.4. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.4. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.5. GTP . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.5. GTP . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.6. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.6. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.7. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . 18
3.5. Embedded Label Handling Sub-TLV . . . . . . . . . . . . . 18 3.5. Embedded Label Handling Sub-TLV . . . . . . . . . . . . . 18
3.6. MPLS Label Stack Sub-TLV . . . . . . . . . . . . . . . . 19 3.6. MPLS Label Stack Sub-TLV . . . . . . . . . . . . . . . . 19
3.7. Prefix-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 20 3.7. Prefix-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 20
4. Extended Communities Related to the Tunnel Encapsulation 4. Extended Communities Related to the Tunnel Encapsulation
Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Encapsulation Extended Community . . . . . . . . . . . . 21 4.1. Encapsulation Extended Community . . . . . . . . . . . . 22
4.2. Router's MAC Extended Community . . . . . . . . . . . . . 22 4.2. Router's MAC Extended Community . . . . . . . . . . . . . 23
4.3. Color Extended Community . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6. Routing Considerations . . . . . . . . . . . . . . . . . . . 26 6. Routing Considerations . . . . . . . . . . . . . . . . . . . 27
6.1. No Impact on BGP Decision Process . . . . . . . . . . . . 26 6.1. No Impact on BGP Decision Process . . . . . . . . . . . . 27
6.2. Looping, Infinite Stacking, Etc. . . . . . . . . . . . . 27 6.2. Looping, Infinite Stacking, Etc. . . . . . . . . . . . . 28
7. Recursive Next Hop Resolution . . . . . . . . . . . . . . . . 27 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 . . . . . . . . . . . . 28 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Field . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.2. Tunnel Types with a Virtual Network Identifier Field . . 29 8.2. Tunnel Types with a Virtual Network Identifier Field . . 30
8.2.1. Unlabeled Address Families . . . . . . . . . . . . . 29 8.2.1. Unlabeled Address Families . . . . . . . . . . . . . 30
8.2.2. Labeled Address Families . . . . . . . . . . . . . . 30 8.2.2. Labeled Address Families . . . . . . . . . . . . . . 31
8.2.2.1. When a Valid VNI has been Signaled . . . . . . . 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 . . . . . 30 8.2.2.2. When a Valid VNI has not been Signaled . . . . . 31
9. Applicability Restrictions . . . . . . . . . . . . . . . . . 31 9. Applicability Restrictions . . . . . . . . . . . . . . . . . 32
10. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 32 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 33
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
12.1. Subsequent Address Family Identifiers . . . . . . . . . 33 12.1. Subsequent Address Family Identifiers . . . . . . . . . 34
12.2. BGP Path Attributes . . . . . . . . . . . . . . . . . . 33 12.2. BGP Path Attributes . . . . . . . . . . . . . . . . . . 34
12.3. Extended Communities . . . . . . . . . . . . . . . . . . 33 12.3. Extended Communities . . . . . . . . . . . . . . . . . . 34
12.4. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 34 12.4. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 35
12.5. Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 35 12.5. Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 36
13. Security Considerations . . . . . . . . . . . . . . . . . . . 35 13. Security Considerations . . . . . . . . . . . . . . . . . . . 36
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
15. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 36 15. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 37
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
16.1. Normative References . . . . . . . . . . . . . . . . . . 37 16.1. Normative References . . . . . . . . . . . . . . . . . . 38
16.2. Informative References . . . . . . . . . . . . . . . . . 37 16.2. Informative References . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
This document obsoletes RFC 5512. The deficiencies of RFC 5512, and This document obsoletes RFC 5512. The deficiencies of RFC 5512, and
a summary of the changes made, are discussed in Sections 1.1-1.3. a summary of the changes made, are discussed in Sections 1.1-1.3.
The material from RFC 5512 that is retained has been incorporated The material from RFC 5512 that is retained has been incorporated
into this document. into this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
skipping to change at page 4, line 18 skipping to change at page 4, line 18
Encapsulation attribute. This attribute consists of one or more Encapsulation attribute. This attribute consists of one or more
TLVs. Each TLV identifies a particular type of tunnel. Each TLV TLVs. Each TLV identifies a particular type of tunnel. Each TLV
also contains one or more sub-TLVs. Some of the sub-TLVs, e.g., the also contains one or more sub-TLVs. Some of the sub-TLVs, e.g., the
"Encapsulation sub-TLV", contain information that may be used to form "Encapsulation sub-TLV", contain information that may be used to form
the encapsulation header for the specified tunnel type. Other sub- the encapsulation header for the specified tunnel type. Other sub-
TLVs, e.g., the "color sub-TLV" and the "protocol sub-TLV", contain TLVs, e.g., the "color sub-TLV" and the "protocol sub-TLV", contain
information that aids in determining whether particular packets information that aids in determining whether particular packets
should be sent through the tunnel that the TLV identifies. should be sent through the tunnel that the TLV identifies.
[RFC5512] only allows the Tunnel Encapsulation attribute to be [RFC5512] only allows the Tunnel Encapsulation attribute to be
attached to BGP UPDATE messages that have the "Encapsulation SAFI" attached to BGP UPDATE messages of the Encapsulation Address Family.
(i.e., UPDATE messages with AFI/SAFI 1/7 or 2/7). In an UPDATE of These UPDATE messages have an AFI (Address Family Identifier) of 1 or
the Encapsulation SAFI, the NLRI is an address of the BGP speaker 2, and a SAFI of 7. In an UPDATE of the Encapsulation SAFI, the NLRI
originating the UPDATE. Consider the following scenario: (Network Layer Reachability Information) is an address of the BGP
speaker originating the UPDATE. Consider the following scenario:
o BGP speaker R1 has received and installed UPDATE U; o BGP speaker R1 has received and installed UPDATE U;
o UPDATE U's SAFI is the Encapsulation SAFI; o UPDATE U's SAFI is the Encapsulation SAFI;
o UPDATE U has the address R2 as its NLRI; o UPDATE U has the address R2 as its NLRI;
o UPDATE U has a Tunnel Encapsulation attribute. o UPDATE U has a Tunnel Encapsulation attribute.
o R1 has a packet, P, to transmit to destination D; o R1 has a packet, P, to transmit to destination D;
skipping to change at page 5, line 52 skipping to change at page 5, line 52
o Defining the sub-TLV type field so that a sub-TLV whose type is in o Defining the sub-TLV type field so that a sub-TLV whose type is in
the range from 1 to 127 inclusive has a one-octet length field, the range from 1 to 127 inclusive has a one-octet length field,
but a sub-TLV whose type is in the range from 128 to 254 inclusive but a sub-TLV whose type is in the range from 128 to 254 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, VXLAN-GPE, NVGRE, GTP, and MPLS-in-GRE. MPLS-in- [RFC5512]: VXLAN (Virtual Extensible Local Area Network, [RFC7348]),
UDP [RFC7510] is also supported, but an Encapsulation sub-TLV for it VXLAN-GPE (Generic Protocol Extension for VXLAN, [VXLAN-GPE]), NVGRE
is not needed. (Network Virtualization Using Generic Routing Encapsulation
[RFC7637]), GTP, and MPLS-in-GRE (MPLS in Generic Routing
Encapsulation [RFC2784], [RFC2890], [RFC4023]). 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 6, line 32 skipping to change at page 6, line 36
using sub-TLVs of the Tunnel Encapsulation attribute) how one wants using sub-TLVs of the Tunnel Encapsulation attribute) how one wants
to use the embedded label when the tunnel encapsulation has its own to use the embedded label when the tunnel encapsulation has its own
virtual network identifier field. virtual network identifier field.
[RFC5512] defines a Tunnel Encapsulation Extended Community, that can [RFC5512] defines a Tunnel Encapsulation Extended Community, that can
be used instead of the Tunnel Encapsulation attribute under certain be used instead of the Tunnel Encapsulation attribute under certain
circumstances. This document addresses the issue of how to handle a circumstances. This document addresses the issue of how to handle a
BGP UPDATE that carries both a Tunnel Encapsulation attribute and one BGP UPDATE that carries both a Tunnel Encapsulation attribute and one
or more Tunnel Encapsulation Extended Communities. or more Tunnel Encapsulation Extended Communities.
1.4. Impact on RFC 5566
[RFC5566] uses the mechanisms defined in [RFC5512]. While this
document obsoletes [RFC5512], it does not address the issue of how to
use the mechanisms of [RFC5566] without also using the Encapsulation
SAFI. Those issues are considered to be outside the scope of this
document.
2. The Tunnel Encapsulation Attribute 2. The Tunnel Encapsulation Attribute
The Tunnel Encapsulation attribute is an optional transitive BGP Path The Tunnel Encapsulation attribute is an optional transitive BGP Path
attribute. IANA has assigned the value 23 as the type code of the attribute. IANA has assigned the value 23 as the type code of the
attribute. The attribute is composed of a set of Type-Length-Value attribute. The attribute is composed of a set of Type-Length-Value
(TLV) encodings. Each TLV contains information corresponding to a (TLV) encodings. Each TLV contains information corresponding to a
particular tunnel type. A TLV is structured as shown in Figure 1: particular tunnel type. A TLV is structured as shown in Figure 1:
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 10, line 49 skipping to change at page 11, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 4: VXLAN 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 (Virtual
present in the encapsulation sub-TLV. Please see Section 8. Network Identifier) is 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.
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.
skipping to change at page 14, line 5 skipping to change at page 14, line 19
If the M bit is not set, and the payload being sent through the If the M bit is not set, and the payload being sent through the
NVGRE tunnel is an ethernet frame, the Destination MAC Address NVGRE tunnel is an ethernet frame, the Destination MAC Address
field of the Inner Ethernet Header is just the Destination MAC field of the Inner Ethernet Header is just the Destination MAC
Address field of the payload's ethernet header. Address field of the payload's ethernet header.
If the M bit is not set, and the payload being sent through the If the M bit is not set, and the payload being sent through the
NVGRE tunnel is an IP or MPLS packet, the Inner Destination MAC NVGRE tunnel is an IP or MPLS packet, the Inner Destination MAC
address field is set to a configured value; if there is no address field is set to a configured value; if there is no
configured value, the NVGRE tunnel cannot be used. configured value, the NVGRE tunnel cannot be used.
o See Section 8 to see how the VSID field of the NVGRE encapsulation o See Section 8 to see how the VSID (Virtual Subnet Identifier)
header is set. field of the NVGRE encapsulation header is set.
3.2.4. L2TPv3 3.2.4. L2TPv3
When the tunnel type of the TLV is L2TPv3 over IP, the following is When the tunnel type of the TLV is L2TPv3 over IP, the following is
the structure of the value field of the encapsulation sub-TLV: the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID (4 octets) | | Session ID (4 octets) |
skipping to change at page 17, line 16 skipping to change at page 17, line 25
sub-TLVs must be used. This document defines two such sub-TLVs. sub-TLVs must be used. This document defines two such sub-TLVs.
If an outer encapsulation sub-TLV occurs in a TLV for a tunnel type If an outer encapsulation sub-TLV occurs in a TLV for a tunnel type
that does not use the corresponding outer encapsulation, the sub-TLV that does not use the corresponding outer encapsulation, the sub-TLV
is treated as if it were an unknown type of sub-TLV. is treated as if it were an unknown type of sub-TLV.
3.3.1. IPv4 DS Field 3.3.1. IPv4 DS Field
Most of the tunnel types that can be specified in the Tunnel Most of the tunnel types that can be specified in the Tunnel
Encapsulation attribute require an outer IP encapsulation. The IPv4 Encapsulation attribute require an outer IP encapsulation. The IPv4
DS Field sub-TLV can be carried in the TLV of any such tunnel type. Differentiated Services (DS) Field sub-TLV can be carried in the TLV
It specifies the setting of one-octet Differentiated Services field of any such tunnel type. It specifies the setting of the one-octet
in the outer IP encapsulation (see [RFC2474]). The value field is Differentiated Services field in the outer IP encapsulation (see
always a single octet. [RFC2474]). The value field is always a single octet.
3.3.2. UDP Destination Port 3.3.2. UDP Destination Port
Some of the tunnel types that can be specified in the Tunnel Some of the tunnel types that can be specified in the Tunnel
Encapsulation attribute require an outer UDP encapsulation. Encapsulation attribute require an outer UDP encapsulation.
Generally there is a standard UDP Destination Port value for a Generally there is a standard UDP Destination Port value for a
particular tunnel type. However, sometimes it is useful to be able particular tunnel type. However, sometimes it is useful to be able
to use a non-standard UDP destination port. If a particular tunnel to use a non-standard UDP destination port. If a particular tunnel
type requires an outer UDP encapsulation, and it is desired to use a type requires an outer UDP encapsulation, and it is desired to use a
UDP destination port other than the standard one, the port to be used UDP destination port other than the standard one, the port to be used
skipping to change at page 20, line 13 skipping to change at page 20, line 21
from the sub-TLV length field. Thus it is not necessary to set the S from the sub-TLV length field. Thus it is not necessary to set the S
bit in any of the label stack entries of the sub-TLV, and the setting bit in any of the label stack entries of the sub-TLV, and the setting
of the S bit is ignored when parsing the sub-TLV. When the label of the S bit is ignored when parsing the sub-TLV. When the label
stack entries are pushed onto a packet that already has a label stack entries are pushed onto a packet that already has a label
stack, the S bits of all the entries MUST be cleared. When the label stack, the S bits of all the entries MUST be cleared. When the label
stack entries are pushed onto a packet that does not already have a stack entries are pushed onto a packet that does not already have a
label stack, the S bit of the bottommost label stack entry MUST be label stack, the S bit of the bottommost label stack entry MUST be
set, and the S bit of all the other label stack entries MUST be set, and the S bit of all the other label stack entries MUST be
cleared.. cleared..
By default, the TC field ([RFC3032], [RFC5462]) of each label stack By default, the TC (Traffic Class) field ([RFC3032], [RFC5462]) of
entry is set to 0. This may of course be changed by policy at the each label stack entry is set to 0. This may of course be changed by
originator of the sub-TLV. When pushing the label stack onto a policy at the originator of the sub-TLV. When pushing the label
packet, the TC of the label stack entries is preserved by default. stack onto a packet, the TC of the label stack entries is preserved
However, local policy at the router that is pushing on the stack MAY by default. However, local policy at the router that is pushing on
cause modification of the TC values. the stack MAY cause modification of the TC values.
By default, the TTL field of each label stack entry is set to 255. By default, the TTL (Time to Live) field of each label stack entry is
This may be changed by policy at the originator of the sub-TLV. When set to 255. This may be changed by policy at the originator of the
pushing the label stack onto a packet, the TTL of the label stack sub-TLV. When pushing the label stack onto a packet, the TTL of the
entries is preserved by default. However, local policy at the router label stack entries is preserved by default. However, local policy
that is pushing on the stack MAY cause modification of the TTL at the router that is pushing on the stack MAY cause modification of
values. If any label stack entry in the sub-TLV has a TTL value of the TTL values. If any label stack entry in the sub-TLV has a TTL
zero, the router that is pushing the stack on a packet MUST change value of zero, the router that is pushing the stack on a packet MUST
the value to a non-zero value. change the value to a non-zero value.
Note that this sub-TLV can be appear within a TLV identifying any Note that this sub-TLV can 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 [Prefix-SID-Attribute] defines a BGP Path attribute known as the
"Prefix-SID Attribute". This attribute is defined to contain a "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" TLV, or an "Originator SRGB" TLV. Index" TLV, an "IPv6 SID (Segment Identifier)" TLV, or an "Originator
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]. [Prefix-SID-Attribute].
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, the 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
packet is sent through the tunnel identified by the TLV, the packet is sent through the tunnel identified by the TLV, the
corresponding MPLS label MUST be pushed on the packet's label stack. corresponding MPLS label MUST be pushed on the packet's label stack.
If the Originator SRGB is present, the corresponding MPLS label is The corresponding MPLS label is computed from the Label-Index value
computed from the combination of the Label-Index and the Originator and the SRGB of the route's originator.
SRGB (see [Prefix-SID-Attribute]). If the Originator SRGB is not
present, the corresponding MPLS label is just the Label-Index value If the Originator SRGB is not present,it is assumed that the
itself. The corresponding MPLS label is pushed on after the originator's SRGB is known by other means. Such "other means" are
processing of the MPLS Label Stack sub-TLV, if present, as specified outside the scope of this document.
in Section 3.6. It is pushed on before any other labels (e.g., a
label embedded in UPDATE's NLRI, or a label determined by the The corresponding MPLS label is pushed on after the processing of the
procedures of Section 8 are pushed on the stack. MPLS Label Stack sub-TLV, if present, as specified in Section 3.6.
It is pushed on before any other labels (e.g., a label embedded in
UPDATE's NLRI, or a label determined by the procedures of Section 8
are pushed on the stack.
The Prefix-SID sub-TLV has slightly different semantics than the The Prefix-SID sub-TLV has slightly different semantics than the
Prefix-SID attribute. When the Prefix-SID attribute is attached to a Prefix-SID attribute. When the Prefix-SID attribute is attached to a
given route, the BGP speaker that originally attached the attribute given route, the BGP speaker that originally attached the attribute
is expected to be in the same Segment Routing domain as the BGP is expected to be in the same Segment Routing domain as the BGP
speakers who receive the route with the attached attribute. The speakers who receive the route with the attached attribute. The
Label-Index tells the receiving BGP speakers that the prefix-SID is Label-Index tells the receiving BGP speakers that the prefix-SID is
for the advertised prefix in that Segment Routing domain. When the for the advertised prefix in that Segment Routing domain. When the
Prefix-SID sub-TLV is used, the BGP speaker at the head end of the Prefix-SID sub-TLV is used, the BGP speaker at the head end of the
tunnel need even not be in the same Segment Routing Domain as the tunnel need even not be in the same Segment Routing Domain as the
skipping to change at page 22, line 20 skipping to change at page 22, line 35
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
applications, and is still needed for backwards compatibility. To applications, and is still needed for backwards compatibility. To
ensure backwards compatibility, this specification establishes the ensure backwards compatibility, this specification establishes the
following rule: following rules:
A Tunnel Encapsulation attribute MUST NOT include a barebones 1. If the Tunnel Encapsulation attribute of a given route contains a
Tunnel TLV. Instead of placing such a TLV in the Tunnel barebones Tunnel TLV identifying a particular tunnel type, an
Encapsulation attribute attached to a particular route, the Encapsulation Extended Community identifying the same tunnel type
corresponding Encapsulation Extended Community MUST be attached to SHOULD be attached to the route.
the route.
2. If the Encapsulation Extended Community identifying a particular
tunnel type is attached to a given route, the corresponding
barebones Tunnel TLV MAY be omitted from the Tunnel Encapsulation
attribute.
3. Suppose a particular route has both (a) an Encapsulation Extended
Community specifying a particular tunnel type, and (b) a Tunnel
Encapsulation attribute with a barebones Tunnel TLV specifying
that same tunnel type. Both (a) and (b) MUST be interpreted as
denoting the same tunnel.
In short, in situations where one could use either the Encapsulation
Extended Community or a barebones Tunnel TLV, one may use either or
both. However, to ensure backwards compatibility with applications
that do not support the Tunnel Encapsulation attribute, it is
preferable to use the Encapsulation Extended Community. If the
Extended Community (identifying a particular tunnel type) is present,
the corresponding Tunnel TLV is optional.
Note that for tunnel types of the form "X-in-Y", e.g., MPLS-in-GRE, Note that for tunnel types of the form "X-in-Y", e.g., MPLS-in-GRE,
the Encapsulation Extended Community implies that only packets of the the Encapsulation Extended Community implies that only packets of the
specified payload type "X" are to be carried through the tunnel of specified payload type "X" are to be carried through the tunnel of
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
skipping to change at page 23, line 28 skipping to change at page 24, line 16
[RFC5512] specifies the use of the Tunnel Encapsulation attribute in [RFC5512] specifies the use of the Tunnel Encapsulation attribute in
BGP UPDATE messages of AFI/SAFI 1/7 and 2/7. That document restricts BGP UPDATE messages of AFI/SAFI 1/7 and 2/7. That document restricts
the use of this attribute to UPDATE messsages of those SAFIs. This the use of this attribute to UPDATE messsages of those SAFIs. This
document removes that restriction. document removes that restriction.
The BGP Tunnel Encapsulation attribute MAY be carried in any BGP The BGP Tunnel Encapsulation attribute MAY be carried in any BGP
UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6 UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6
Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast), Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast),
1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast),
or 25/70 (EVPN). Use of the Tunnel Encapsulation attribute in BGP or 25/70 (Ethernet VPN, usually known as EVPN)). Use of the Tunnel
UPDATE messages of other AFI/SAFIs is outside the scope of this Encapsulation attribute in BGP UPDATE messages of other AFI/SAFIs is
document. outside the scope of this document.
It has been suggested that it may sometimes be useful to attach a It has been suggested that it may sometimes be useful to attach a
Tunnel Encapsulation attribute to a BGP UPDATE message that is also Tunnel Encapsulation attribute to a BGP UPDATE message that is also
carrying a PMSI (Provider Multicast Service Interface) Tunnel carrying a PMSI (Provider Multicast Service Interface) Tunnel
attribute [RFC6514]. If the PMSI Tunnel attribute specifies an IP attribute [RFC6514]. If the PMSI Tunnel attribute specifies an IP
tunnel, the Tunnel Encapsulation attribute could be used to provide tunnel, the Tunnel Encapsulation attribute could be used to provide
additional information about the IP tunnel. The usage of the Tunnel additional information about the IP tunnel. The usage of the Tunnel
Encapsulation attribute in combination with the PMSI Tunnel attribute Encapsulation attribute in combination with the PMSI Tunnel attribute
is outside the scope of this document. is outside the scope of this document.
skipping to change at page 29, line 13 skipping to change at page 30, line 10
in one of the attribute's TLVs, and that tunnel type does not contain in one of the attribute's TLVs, and that tunnel type does not contain
a virtual network identifier field, the label or labels from the NLRI a virtual network identifier field, the label or labels from the NLRI
are pushed on the packet's label stack. The resulting MPLS packet is are pushed on the packet's label stack. The resulting MPLS packet is
then further encapsulated, as specified by the TLV. then further encapsulated, as specified by the TLV.
8.2. Tunnel Types with a Virtual Network Identifier Field 8.2. Tunnel Types with a Virtual Network Identifier Field
Three of the tunnel types that can be specified in a Tunnel Three of the tunnel types that can be specified in a Tunnel
Encapsulation TLV have virtual network identifier fields in their Encapsulation TLV have virtual network identifier fields in their
encapsulation headers. In the VXLAN and VXLAN-GPE encapsulations, encapsulation headers. In the VXLAN and VXLAN-GPE encapsulations,
this field is called the VNI field; in the NVGRE encapsulation, this this field is called the VNI (Virtual Network Identifier) field; in
field is called the VSID field. the NVGRE encapsulation, this field is called the VSID (Virtual
Subnet Identifier) field.
When one of these tunnel encapsulations is imposed on a packet, the When one of these tunnel encapsulations is imposed on a packet, the
setting of the virtual network identifier field in the encapsulation setting of the virtual network identifier field in the encapsulation
header depends upon the contents of the Encapsulation sub-TLV (if one header depends upon the contents of the Encapsulation sub-TLV (if one
is present). When the Tunnel Encapsulation attribute is being is present). When the Tunnel Encapsulation attribute is being
carried on a BGP UPDATE of a labeled address family, the setting of carried on a BGP UPDATE of a labeled address family, the setting of
the virtual network identifier field also depends upon the contents the virtual network identifier field also depends upon the contents
of the Embedded Label Handling sub-TLV (if present). of the Embedded Label Handling sub-TLV (if present).
This section specifies the procedures for choosing the value to set This section specifies the procedures for choosing the value to set
skipping to change at page 36, line 31 skipping to change at page 37, line 31
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 think Ron Bonica, John Drake, Satoru Matsushima, The authors wish to thank Lou Berger, Ron Bonica, John Drake, Satoru
Dhananjaya Rao, John Scudder, Ravi Singh, Thomas Morin, Xiaohu Xu, Matsushima, Dhananjaya Rao, John Scudder, Ravi Singh, Thomas Morin,
and Zhaohui Zhang for their review, comments, and/or helpful Xiaohu Xu, and Zhaohui Zhang for their review, comments, and/or
discussions. 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 10 skipping to change at page 40, line 10
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>. 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <http://www.rfc-editor.org/info/rfc5462>. 2009, <http://www.rfc-editor.org/info/rfc5462>.
[RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel
Encapsulation Attribute", RFC 5566, DOI 10.17487/RFC5566,
June 2009, <http://www.rfc-editor.org/info/rfc5566>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>. <http://www.rfc-editor.org/info/rfc6514>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811, Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013, DOI 10.17487/RFC6811, January 2013,
<http://www.rfc-editor.org/info/rfc6811>. <http://www.rfc-editor.org/info/rfc6811>.
 End of changes. 31 change blocks. 
103 lines changed or deleted 144 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/