draft-ietf-idr-tunnel-encaps-01.txt   draft-ietf-idr-tunnel-encaps-02.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 Cisco Systems Intended status: Standards Track Cisco Systems
Expires: June 23, 2016 G. Van de Velde Expires: December 2, 2016 G. Van de Velde
Alcatel-Lucent Nokia
December 21, 2015 May 31, 2016
The BGP Tunnel Encapsulation Attribute The BGP Tunnel Encapsulation Attribute
draft-ietf-idr-tunnel-encaps-01 draft-ietf-idr-tunnel-encaps-02
Abstract Abstract
RFC 5512 defines a BGP Path Attribute known as the "Tunnel RFC 5512 defines a BGP Path Attribute known as the "Tunnel
Encapsulation Attribute". This attribute allows one to specify a set Encapsulation Attribute". This attribute allows one to specify a set
of tunnels. For each such tunnel, the attribute can provide the of tunnels. For each such tunnel, the attribute can provide the
information needed to create the tunnel and the corresponding information needed to create the tunnel and the corresponding
encapsulation header. The attribute can also provide information encapsulation header. The attribute can also provide information
that aids in choosing whether a particular packet is to be sent that aids in choosing whether a particular packet is to be sent
through a particular tunnel. RFC 5512 states that the attribute is through a particular tunnel. RFC 5512 states that the attribute is
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 23, 2016. This Internet-Draft will expire on December 2, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
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 . . . . . . . . . . . . . . . . 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
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 . . . . . . . . . . . 7
3.1. The Remote Endpoint Sub-TLV . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.3. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.4. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.4. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.5. GTP . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.5. GTP . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.6. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.6. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.7. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 15 3.2.7. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 16
3.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 16 3.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . 21
4.2. Router's MAC Extended Community . . . . . . . . . . . . . 22 4.2. Router's MAC Extended Community . . . . . . . . . . . . . 22
4.3. Color Extended Community . . . . . . . . . . . . . . . . 22 4.3. Color Extended Community . . . . . . . . . . . . . . . . 22
5. Semantics and Usage of the Tunnel Encapsulation 5. Semantics and Usage of the Tunnel Encapsulation
attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 22 attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Routing Considerations . . . . . . . . . . . . . . . . . . . 26 6. Routing Considerations . . . . . . . . . . . . . . . . . . . 26
6.1. No Impact on BGP Decision Process . . . . . . . . . . . . 26 6.1. No Impact on BGP Decision Process . . . . . . . . . . . . 26
6.2. Looping, Infinite Stacking, Etc. . . . . . . . . . . . . 26 6.2. Looping, Infinite Stacking, Etc. . . . . . . . . . . . . 27
7. Recursive Next Hop Resolution . . . . . . . . . . . . . . . . 27 7. Recursive Next Hop Resolution . . . . . . . . . . . . . . . . 27
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 . . . . . . . . . . . . 28
8.1. Tunnel Types without a Virtual Network Identifier 8.1. Tunnel Types without a Virtual Network Identifier
Field . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Field . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.2. Tunnel Types with a Virtual Network Identifier Field . . 28 8.2. Tunnel Types with a Virtual Network Identifier Field . . 29
8.2.1. Unlabeled Address Families . . . . . . . . . . . . . 29 8.2.1. Unlabeled Address Families . . . . . . . . . . . . . 29
8.2.2. Labeled Address Families . . . . . . . . . . . . . . 29 8.2.2. Labeled Address Families . . . . . . . . . . . . . . 30
8.2.2.1. When a Valid VNI has been Signaled . . . . . . . 29 8.2.2.1. When a Valid VNI has been Signaled . . . . . . . 30
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 . . . . . 30
9. Applicability Restrictions . . . . . . . . . . . . . . . . . 30 9. Applicability Restrictions . . . . . . . . . . . . . . . . . 31
10. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 31 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 32
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
12.1. Subsequent Address Family Identifiers . . . . . . . . . 33 12.1. Subsequent Address Family Identifiers . . . . . . . . . 33
12.2. BGP Path Attributes . . . . . . . . . . . . . . . . . . 33 12.2. BGP Path Attributes . . . . . . . . . . . . . . . . . . 33
12.3. Extended Communities . . . . . . . . . . . . . . . . . . 33 12.3. Extended Communities . . . . . . . . . . . . . . . . . . 33
12.4. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 33 12.4. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 34
12.5. Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 34 12.5. Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 35
13. Security Considerations . . . . . . . . . . . . . . . . . . . 34 13. Security Considerations . . . . . . . . . . . . . . . . . . . 35
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
15. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 36 15. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 36
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
16.1. Normative References . . . . . . . . . . . . . . . . . . 36 16.1. Normative References . . . . . . . . . . . . . . . . . . 37
16.2. Informative References . . . . . . . . . . . . . . . . . 37 16.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
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.
skipping to change at page 5, line 19 skipping to change at page 5, line 19
o If the respective best paths to two different address prefixes o If the respective best paths to two different address prefixes
have the same next hop, [RFC5512] does not provide a have the same next hop, [RFC5512] does not provide a
straightforward method to associate each prefix with a different straightforward method to associate each prefix with a different
tunnel. tunnel.
o If a particular tunnel type requires an outer IP or UDP o If a particular tunnel type requires an outer IP or UDP
encapsulation, there is no way to signal the values of any of the encapsulation, there is no way to signal the values of any of the
fields of the outer encapsulation. fields of the outer encapsulation.
o In [RFC5512]'s specification of the sub-TLVs, each sub-TLV has
one-octet length field. In some cases, a two-octet length field
may be needed.
1.3. Brief Summary of Changes from RFC 5512 1.3. Brief Summary of Changes from RFC 5512
In this document we address these deficiencies by: In this document we address these deficiencies by:
o Deprecating the Encapsulation SAFI. o Deprecating the Encapsulation SAFI.
o Defining a new "Remote Endpoint Address sub-TLV" that can be o Defining a new "Remote Endpoint Address sub-TLV" that can be
included in any of the TLVs contained in the Tunnel Encapsulation included in any of the TLVs contained in the Tunnel Encapsulation
attribute. This sub-TLV can be used to specify the remote attribute. This sub-TLV can be used to specify the remote
endpoint address of a particular tunnel. endpoint address of a particular tunnel.
o Allowing the Tunnel Encapsulation attribute to be carried by BGP o Allowing the Tunnel Encapsulation attribute to be carried by BGP
UPDATEs of additional AFI/SAFIs. Appropriate semantics are UPDATEs of additional AFI/SAFIs. Appropriate semantics are
provided for this way of using the attribute. provided for this way of using the attribute.
o Defining a number of new sub-TLVs that provide additional o Defining a number of new sub-TLVs that provide additional
information that is useful when forming the encapsulation header information that is useful when forming the encapsulation header
used to send a packet through a particular tunnel. used to send a packet through a particular tunnel.
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,
but a sub-TLV whose type is in the range from 128 to 254 inclusive
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, VXLAN-GPE, NVGRE, GTP, and MPLS-in-GRE. MPLS-in-
UDP [RFC7510] is also supported, but an Encapsulation sub-TLV for it UDP [RFC7510] is also supported, but an Encapsulation sub-TLV for it
is not needed. is not needed.
Some of the encapsulations mentioned in the previous paragraph need Some of the encapsulations mentioned in the previous paragraph need
skipping to change at page 6, line 29 skipping to change at page 6, line 38
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.
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 follows: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Type (2 Octets) | Length (2 Octets) | | Tunnel Type (2 Octets) | Length (2 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Value | | Value |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 13 skipping to change at page 7, line 22
equivalent of specifying a tunnel type "Y" and including in its equivalent of specifying a tunnel type "Y" and including in its
TLV a Protocol Type sub-TLV (see Section 3.4.1 specifying protocol TLV a Protocol Type sub-TLV (see Section 3.4.1 specifying protocol
"X". "X".
o Length (2 octets): the total number of octets of the value field. o Length (2 octets): the total number of octets of the value field.
o Value (variable): comprised of multiple sub-TLVs. o Value (variable): comprised of multiple sub-TLVs.
Each sub-TLV consists of three fields: a 1-octet type, 1-octet Each sub-TLV consists of three fields: a 1-octet type, 1-octet
length, and zero or more octets of value. A sub-TLV is structured as length, and zero or more octets of value. A sub-TLV is structured as
follows: shown in Figure 2:
+-----------------------------------+ +-----------------------------------+
| Sub-TLV Type (1 Octet) | | Sub-TLV Type (1 Octet) |
+-----------------------------------+ +-----------------------------------+
| Sub-TLV Length (1 Octet) | | Sub-TLV Length (1 or 2 Octets)|
+-----------------------------------+ +-----------------------------------+
| Sub-TLV Value (Variable) | | Sub-TLV Value (Variable) |
| | | |
+-----------------------------------+ +-----------------------------------+
Figure 2: Tunnel Encapsulation Sub-TLV Format Figure 2: 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 octet): the total number of octets of the sub- o Sub-TLV Length (1 or 2 octets): the total number of octets of the
TLV value field. 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 1-127.
The Sub-TLV Length field contains two octets if the Sub-TLV Type
field contains a value in the range from 128-254.
o Sub-TLV Value (variable): encodings of the value field depend on o Sub-TLV Value (variable): encodings of the value field depend on
the sub-TLV type as enumerated above. The following sub-sections the sub-TLV type as enumerated above. The following sub-sections
define the encoding in detail. define the encoding in detail.
3. Tunnel Encapsulation Attribute Sub-TLVs 3. Tunnel Encapsulation Attribute Sub-TLVs
In this section, we specify a number of sub-TLVs. These sub-TLVs can In this section, we specify a number of sub-TLVs. These sub-TLVs can
be included in a TLV of the Tunnel Encapsulation attribute. be included in a TLV of the Tunnel Encapsulation attribute.
skipping to change at page 21, line 42 skipping to change at page 21, line 45
4. Extended Communities Related to the Tunnel Encapsulation Attribute 4. Extended Communities Related to the Tunnel Encapsulation Attribute
4.1. Encapsulation Extended Community 4.1. Encapsulation Extended Community
The Encapsulation Extended Community is a Transitive Opaque Extended The Encapsulation Extended Community is a Transitive Opaque Extended
Community. This Extended Community may be attached to a route of any Community. This Extended Community may be attached to a route of any
AFI/SAFI to which the Tunnel Encapsulation attribute may be attached. AFI/SAFI to which the Tunnel Encapsulation attribute may be attached.
Each such Extended Community identifies a particular tunnel type. If Each such Extended Community identifies a particular tunnel type. If
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 TLV that: Tunnel Encapsulation attribute Tunnel TLV for which the following
three conditions all hold:
o identifies the same tunnel type, and 1. it identifies the same tunnel type,
o has a Remote Endpoint sub-TLV whose IP address field contains the 2. it has a Remote Endpoint sub-TLV for which one of the following
address of the BGP next hop of the route to which it is attached, two conditions holds:
and
o has no other sub-TLVs. a. its "Address Family" subfield contains zero, or
b. its "Address" subfield contains the same IP address that
appears in the next hop field of the route to which the
Tunnel Encapsulation attribute is attached
3. it has no other sub-TLVs.
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].
It provides a small subset of the functionality of the Tunnel While it provides only a small subset of the functionality of the
Encapsulation attribute, and, strictly speaking, is no longer needed. Tunnel Encapsulation attribute, it is used in a number of deployed
However, it is included here for backwards compatibility. applications, and is still needed for backwards compatibility. To
ensure backwards compatibility, this specification establishes the
following rule:
A Tunnel Encapsulation attribute MUST NOT include a barebones
Tunnel TLV. Instead of placing such a TLV in the Tunnel
Encapsulation attribute attached to a particular route, the
corresponding Encapsulation Extended Community MUST be attached to
the route.
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 27 skipping to change at page 23, line 46
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.
The decision to attach a Tunnel Encapsulation attribute to a given The decision to attach a Tunnel Encapsulation attribute to a given
BGP UPDATE is determined by policy. The set of TLVs and sub-TLVs BGP UPDATE is determined by policy. The set of TLVs and sub-TLVs
contained in the attribute is also determined by policy. contained in the attribute is also determined by policy.
When the Tunnel Encapsulation attribute is carried in an UPDATE of When the Tunnel Encapsulation attribute is carried in an UPDATE of
one of the AFI/SAFIs specifies in the previous paragraph, each TLV one of the AFI/SAFIs specified in the previous paragraph, each TLV
MUST have a Remote Endpoint sub-TLV. If a TLV that does not have a MUST have a Remote Endpoint sub-TLV. If a TLV that does not have a
Remote Endpoint sub-TLV, that TLV should be treated as if it had a Remote Endpoint sub-TLV, that TLV should be treated as if it had a
malformed Remote Endpoint sub-TLV (see Section 3.1). malformed Remote Endpoint sub-TLV (see Section 3.1).
Suppose that: Suppose that:
o a given packet P must be forwarded by router R; o a given packet P must be forwarded by router R;
o the path along which P is to be forwarded is determined by BGP o the path along which P is to be forwarded is determined by BGP
UPDATE U; UPDATE U;
skipping to change at page 30, line 42 skipping to change at page 31, line 14
The embedded label (from the NLRI of the route that is carrying The embedded label (from the NLRI of the route that is carrying
the Tunnel Encapsulation attribute) appears at the top of the MPLS the Tunnel Encapsulation attribute) appears at the top of the MPLS
label stack in the encapsulation payload. label stack in the encapsulation payload.
o If the TLV does not contain an Embedded Label Handling sub-TLV, or o If the TLV does not contain an Embedded Label Handling sub-TLV, or
if it contains an Embedded Label Handling sub-TLV whose value is if it contains an Embedded Label Handling sub-TLV whose value is
2, the embedded label is copied into the virtual network 2, the embedded label is copied into the virtual network
identifier field of the encapsulation header. identifier field of the encapsulation header.
The embedded label does not appear in the MPLS label stack of the In this case, the payload may or may not contain an MPLS label
payload. stack, depending upon other factors. If the payload does contain
an MPLS lable stack, the embedded label does not appear in that
stack.
9. Applicability Restrictions 9. Applicability Restrictions
In a given UPDATE of a labeled address family, the label embedded in In a given UPDATE of a labeled address family, the label embedded in
the NLRI is generally a label that is meaningful only to the router the NLRI is generally a label that is meaningful only to the router
whose address appears as the next hop. Certain of the procedures of whose address appears as the next hop. Certain of the procedures of
Section 8.2.2.1 or Section 8.2.2.2 cause the embedded label to be Section 8.2.2.1 or Section 8.2.2.2 cause the embedded label to be
carried by a data packet to the router whose address appears in the carried by a data packet to the router whose address appears in the
Remote Endpoint sub-TLV. If the Remote Endpoint sub-TLV does not Remote Endpoint sub-TLV. If the Remote Endpoint sub-TLV does not
identify the same router that is the next hop, sending the packet identify the same router that is the next hop, sending the packet
skipping to change at page 33, line 37 skipping to change at page 34, line 9
12.3. Extended Communities 12.3. Extended Communities
IANA has assigned values from the "Transitive Opaque Extended IANA has assigned values from the "Transitive Opaque Extended
Community" type Registry to the "Color Extended Community" (sub-type Community" type Registry to the "Color Extended Community" (sub-type
0x0b), and to the "Encapsulation Extended Community"(0x030c). IANA 0x0b), and to the "Encapsulation Extended Community"(0x030c). IANA
is requested to add this document as a reference for both is requested to add this document as a reference for both
assignments. assignments.
12.4. BGP Tunnel Encapsulation Attribute Sub-TLVs 12.4. BGP Tunnel Encapsulation Attribute Sub-TLVs
IANA is requested to add the following note to the "BGP Tunnel
Encapsulation Attribute Sub-TLVs" registry:
If the Sub-TLV Type is in the range from 1 to 127 inclusive, the
Sub-TLV Length field contains one octet. If the Sub-TLV Type is
in the range from 128-254 inclusive, the Sub-TLV Length field
contains two octets.
IANA is requested to change the registration policy of the "BGP IANA is requested to change the registration policy of the "BGP
Tunnel Encapsulation Attribute Sub-TLVs" registry to the following: Tunnel Encapsulation Attribute Sub-TLVs" registry to the following:
o The values 0 and 255 are reserved. o The values 0 and 255 are reserved.
o The values in the range 1-127 are to be allocated using the o The values in the range 1-63 and 128-191 are to be allocated using
"Standards Action" registration procedure. the "Standards Action" registration procedure.
o The values in the range 128-251 are to be allocated using the o The values in the range 64-125 and 192-252 are to be allocated
"First Come, First Served" registration procedure. using the "First Come, First Served" registration procedure.
o The values in the range 252-254 are reserved for experimental use; o The values in the range 126-127 and 253-254 are reserved for
IANA shall not allocate values from this range. experimental use; IANA shall not allocate values from this range.
IANA is requested to assign a codepoint from the "BGP Tunnel IANA is requested to assign a codepoint, from the range 1-63 of the
Encapsulation Attribute Sub-TLVs" registry for "Remote Endpoint", "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, for "Remote
with this document being the reference. Endpoint", with this document being the reference.
IANA is requested to assign a codepoint from the "BGP Tunnel IANA is requested to assign a codepoint, from the range 1-63 of the
Encapsulation Attribute Sub-TLVs" registry for "IPv4 DS Field", with "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, for "IPv4 DS
this document being the reference. Field", with this document being the reference.
IANA is requested to assign a codepoint from the "BGP Tunnel IANA is requested to assign a codepoint from the "BGP Tunnel
Encapsulation Attribute Sub-TLVs" registry for "UDP Destination Encapsulation Attribute Sub-TLVs" registry for "UDP Destination
Port", with this document being the reference. Port", with this document being the reference.
IANA is requested to assign a codepoint from the "BGP Tunnel IANA is requested to assign a codepoint, from the range 1-63 of the
Encapsulation Attribute Sub-TLVs" registry for "Embedded Label "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, for "Embedded
Handling", with this document being the reference. Label Handling", with this document being the reference.
IANA is requested to assign a codepoint from the "BGP Tunnel IANA is requested to assign a codepoint, from the range 1-63 of the
Encapsulation Attribute Sub-TLVs" registry for "MPLS Label Stack", "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, for "MPLS
with this document being the reference. Label Stack", with this document being the reference.
IANA is requested to assign a codepoint from the "BGP Tunnel IANA is requested to assign a codepoint, from the range 1-63 of the
Encapsulation Attribute Sub-TLVs" registry for "Prefix SID", with "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, for "Prefix
this document being the reference. SID", with this document being the reference.
IANA has assigned codepoints from the "BGP Tunnel Encapsulation IANA has assigned codepoints from the "BGP Tunnel Encapsulation
Attribute Sub-TLVs" registry for "Encapsulation", "Protocol Type", Attribute Sub-TLVs" registry for "Encapsulation", "Protocol Type",
and "Color". IANA is requested to add this document as a reference. and "Color". IANA is requested to add this document as a reference.
12.5. Tunnel Types 12.5. Tunnel Types
IANA is requested to add this document as a reference for tunnel IANA is requested to add this document as a reference for tunnel
types 8 (VXLAN), 9 (NVGRE), 11 (MPLS-in-GRE), and 12 (VXLAN-GPE) in types 8 (VXLAN), 9 (NVGRE), 11 (MPLS-in-GRE), and 12 (VXLAN-GPE) in
the "BGP Tunnel Encapsulation Tunnel Types" registry. the "BGP Tunnel Encapsulation Tunnel Types" registry.
skipping to change at page 37, line 29 skipping to change at page 38, line 19
EVPN", internet-draft draft-ietf-bess-evpn-inter-subnet- EVPN", internet-draft draft-ietf-bess-evpn-inter-subnet-
forwarding, October 2015. forwarding, October 2015.
[GTP-U] 3GPP, "GPRS Tunneling Protocol User Plane, TS 29.281", [GTP-U] 3GPP, "GPRS Tunneling Protocol User Plane, TS 29.281",
2014. 2014.
[Prefix-SID-Attribute] [Prefix-SID-Attribute]
Previdi, S., Filsfils, C., Lindem, A., Patel, K., Previdi, S., Filsfils, C., Lindem, A., Patel, K.,
Sreekantiah, A., Ray, S., and H. Gredler, "Segment Routing Sreekantiah, A., Ray, S., and H. Gredler, "Segment Routing
Prefix SID extensions for BGP", internet-draft draft-ietf- Prefix SID extensions for BGP", internet-draft draft-ietf-
idr-bgp-prefix-sid-02, October 2015. idr-bgp-prefix-sid-02, December 2015.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>. <http://www.rfc-editor.org/info/rfc2474>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000, DOI 10.17487/RFC2784, March 2000,
skipping to change at page 38, line 43 skipping to change at page 39, line 34
DOI 10.17487/RFC7510, April 2015, DOI 10.17487/RFC7510, April 2015,
<http://www.rfc-editor.org/info/rfc7510>. <http://www.rfc-editor.org/info/rfc7510>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation", Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015, RFC 7637, DOI 10.17487/RFC7637, September 2015,
<http://www.rfc-editor.org/info/rfc7637>. <http://www.rfc-editor.org/info/rfc7637>.
[vEPC] Matsushima, S. and R. Wakikawa, "Stateless User-Plane [vEPC] Matsushima, S. and R. Wakikawa, "Stateless User-Plane
Architecture for Virtualized EPC", internet-draft draft- Architecture for Virtualized EPC", internet-draft draft-
matsushima-stateless-uplane-vepc-04, March 2015. matsushima-stateless-uplane-vepc-06, March 2016.
[VXLAN-GPE] [VXLAN-GPE]
Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., Kreeger, L. and U. Elzur, "Generic Protocol Extension for
Smith, M., Agarwal, P., Xu, X., Elzur, U., Garg, P.,
Melman, D., and R. Manur, "Generic Protocol Extension for
VXLAN", internet-draft draft-ietf-nvo3-vxlan-gpe, May VXLAN", internet-draft draft-ietf-nvo3-vxlan-gpe, May
2015. 2016.
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
skipping to change at page 39, line 14 skipping to change at page 40, line 4
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
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
United States United States
Email: keyupate@cisco.com Email: keyupate@cisco.com
Gunter Van de Velde Gunter Van de Velde
Alcatel-Lucent Nokia
Copernicuslaan 50 Copernicuslaan 50
Antwerpen 2018 Antwerpen 2018
Belgium Belgium
Email: gunter.van_de_velde@alcatel-lucent.com Email: gunter.van_de_velde@nokia.com
 End of changes. 44 change blocks. 
68 lines changed or deleted 103 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/