draft-ietf-idr-tunnel-encaps-17.txt   draft-ietf-idr-tunnel-encaps-18.txt 
IDR Working Group K. Patel IDR Working Group K. Patel
Internet-Draft Arrcus, Inc Internet-Draft Arrcus, Inc
Obsoletes: 5512, 5566, 5640 (if G. Van de Velde Obsoletes: 5512, 5566, 5640 (if G. Van de Velde
approved) Nokia approved) Nokia
Intended status: Standards Track S. Sangli Intended status: Standards Track S. Sangli
Expires: January 18, 2021 J. Scudder Expires: March 15, 2021 J. Scudder
Juniper Networks Juniper Networks
July 17, 2020 September 11, 2020
The BGP Tunnel Encapsulation Attribute The BGP Tunnel Encapsulation Attribute
draft-ietf-idr-tunnel-encaps-17 draft-ietf-idr-tunnel-encaps-18
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 7 skipping to change at page 2, line 7
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 January 18, 2021. This Internet-Draft will expire on March 15, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
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. Use Case for The Tunnel Encapsulation Attribute . . . . . 5
1.4. Use Case for The Tunnel Encapsulation Attribute . . . . . 6 1.4. Brief Summary of Changes from RFC 5512 . . . . . . . . . 6
2. The Tunnel Encapsulation Attribute . . . . . . . . . . . . . 7 2. The Tunnel Encapsulation Attribute . . . . . . . . . . . . . 7
3. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 9 3. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 9
3.1. The Tunnel Egress Endpoint Sub-TLV . . . . . . . . . . . 9 3.1. The Tunnel Egress Endpoint Sub-TLV . . . . . . . . . . . 9
3.1.1. Validating the Address Field . . . . . . . . . . . . 11 3.1.1. Validating the Address Field . . . . . . . . . . . . 11
3.2. Encapsulation Sub-TLVs for Particular Tunnel Types . . . 12 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types . . . 12
3.2.1. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.1. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2. VXLAN GPE . . . . . . . . . . . . . . . . . . . . . . 14 3.2.2. VXLAN GPE . . . . . . . . . . . . . . . . . . . . . . 14
3.2.3. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.3. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.4. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.4. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.5. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.5. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 17
skipping to change at page 3, line 8 skipping to change at page 3, line 8
3.4.1. Protocol Type Sub-TLV . . . . . . . . . . . . . . . . 19 3.4.1. Protocol Type Sub-TLV . . . . . . . . . . . . . . . . 19
3.4.2. Color Sub-TLV . . . . . . . . . . . . . . . . . . . . 19 3.4.2. Color Sub-TLV . . . . . . . . . . . . . . . . . . . . 19
3.5. Embedded Label Handling Sub-TLV . . . . . . . . . . . . . 20 3.5. Embedded Label Handling Sub-TLV . . . . . . . . . . . . . 20
3.6. MPLS Label Stack Sub-TLV . . . . . . . . . . . . . . . . 21 3.6. MPLS Label Stack Sub-TLV . . . . . . . . . . . . . . . . 21
3.7. Prefix-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 22 3.7. Prefix-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 22
4. Extended Communities Related to the Tunnel Encapsulation 4. Extended Communities Related to the Tunnel Encapsulation
Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Encapsulation Extended Community . . . . . . . . . . . . 23 4.1. Encapsulation Extended Community . . . . . . . . . . . . 23
4.2. Router's MAC Extended Community . . . . . . . . . . . . . 25 4.2. Router's MAC Extended Community . . . . . . . . . . . . . 25
4.3. Color Extended Community . . . . . . . . . . . . . . . . 25 4.3. Color Extended Community . . . . . . . . . . . . . . . . 25
5. Special Considerations for IP-in-IP Tunnels . . . . . . . . 26 5. Special Considerations for IP-in-IP Tunnels . . . . . . . . . 26
6. Semantics and Usage of the Tunnel Encapsulation attribute . . 26 6. Semantics and Usage of the Tunnel Encapsulation attribute . . 26
7. Routing Considerations . . . . . . . . . . . . . . . . . . . 29 7. Routing Considerations . . . . . . . . . . . . . . . . . . . 28
7.1. Impact on the BGP Decision Process . . . . . . . . . . . 29 7.1. Impact on the BGP Decision Process . . . . . . . . . . . 28
7.2. Looping, Mutual Recursion, Etc. . . . . . . . . . . . . . 29 7.2. Looping, Mutual Recursion, Etc. . . . . . . . . . . . . . 29
8. Recursive Next Hop Resolution . . . . . . . . . . . . . . . . 30 8. Recursive Next Hop Resolution . . . . . . . . . . . . . . . . 29
9. Use of Virtual Network Identifiers and Embedded Labels when 9. Use of Virtual Network Identifiers and Embedded Labels when
Imposing a Tunnel Encapsulation . . . . . . . . . . . . . . . 30 Imposing a Tunnel Encapsulation . . . . . . . . . . . . . . . 30
9.1. Tunnel Types without a Virtual Network Identifier Field . 31 9.1. Tunnel Types without a Virtual Network Identifier Field . 30
9.2. Tunnel Types with a Virtual Network Identifier Field . . 31 9.2. Tunnel Types with a Virtual Network Identifier Field . . 31
9.2.1. Unlabeled Address Families . . . . . . . . . . . . . 31 9.2.1. Unlabeled Address Families . . . . . . . . . . . . . 31
9.2.2. Labeled Address Families . . . . . . . . . . . . . . 32 9.2.2. Labeled Address Families . . . . . . . . . . . . . . 32
10. Applicability Restrictions . . . . . . . . . . . . . . . . . 33 10. Applicability Restrictions . . . . . . . . . . . . . . . . . 33
11. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 11. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
12. Validation and Error Handling . . . . . . . . . . . . . . . . 34 12. Validation and Error Handling . . . . . . . . . . . . . . . . 34
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
13.1. BGP Tunnel Encapsulation Parameters Grouping . . . . . . 36 13.1. Obsoleting Code Points Assigned by RFCs 5566 and 5640 . 36
13.2. Subsequent Address Family Identifiers . . . . . . . . . 36 13.2. BGP Tunnel Encapsulation Parameters Grouping . . . . . . 36
13.3. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 36 13.3. Subsequent Address Family Identifiers . . . . . . . . . 36
13.4. Flags Field of VXLAN Encapsulation sub-TLV . . . . . . . 37 13.4. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 36
13.5. Flags Field of VXLAN GPE Encapsulation sub-TLV . . . . . 37 13.5. Flags Field of VXLAN Encapsulation sub-TLV . . . . . . . 37
13.6. Flags Field of NVGRE Encapsulation sub-TLV . . . . . . . 37 13.6. Flags Field of VXLAN GPE Encapsulation sub-TLV . . . . . 38
13.7. Embedded Label Handling sub-TLV . . . . . . . . . . . . 38 13.7. Flags Field of NVGRE Encapsulation sub-TLV . . . . . . . 38
13.8. Color Extended Community . . . . . . . . . . . . . . . . 38 13.8. Embedded Label Handling sub-TLV . . . . . . . . . . . . 38
13.9. Color Extended Community Flags . . . . . . . . . . . . . 38 13.9. Color Extended Community Flags . . . . . . . . . . . . . 39
14. Security Considerations . . . . . . . . . . . . . . . . . . . 38 14. Security Considerations . . . . . . . . . . . . . . . . . . . 39
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40
16. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 40 16. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 40
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
17.1. Normative References . . . . . . . . . . . . . . . . . . 40 17.1. Normative References . . . . . . . . . . . . . . . . . . 41
17.2. Informative References . . . . . . . . . . . . . . . . . 42 17.2. Informative References . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
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. Since [RFC5566] and [RFC5640] rely on RFC 5512, into this document. Since [RFC5566] and [RFC5640] rely on RFC 5512,
they are likewise obsoleted. they are likewise obsoleted.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 5, line 13 skipping to change at page 5, line 13
carry tunnel encapsulation information needs to be reconfigured to carry tunnel encapsulation information needs to be reconfigured to
support the Encapsulation SAFI. The Encapsulation SAFI has never support the Encapsulation SAFI. The Encapsulation SAFI has never
been used, and this requirement has served only to discourage the been used, and this requirement has served only to discourage the
use of the Tunnel Encapsulation attribute. use of the Tunnel Encapsulation attribute.
o There is no way to use the Tunnel Encapsulation attribute to o There is no way to use the Tunnel Encapsulation attribute to
specify the tunnel egress endpoint address of a given tunnel; specify the tunnel egress endpoint address of a given tunnel;
[RFC5512] assumes that the tunnel egress endpoint of each tunnel [RFC5512] assumes that the tunnel egress endpoint of each tunnel
is specified as the NLRI of an UPDATE of the Encapsulation SAFI. is specified as the NLRI of an UPDATE of the Encapsulation SAFI.
o If the respective best paths to two different address prefixes o If the respective best routes 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 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 one-octet length field. In some cases, a two-octet length field
may be needed. may be needed.
1.3. Brief Summary of Changes from RFC 5512 1.3. Use Case for The Tunnel Encapsulation Attribute
Consider the case of a router R1 forwarding an IP packet P. Let D be
P's IP destination address. R1 must look up D in its forwarding
table. Suppose that the "best match" route for D is route Q, where Q
is a BGP-distributed route whose "BGP next hop" is router R2. And
suppose further that the routers along the path from R1 to R2 have
entries for R2 in their forwarding tables, but do NOT have entries
for D in their forwarding tables. For example, the path from R1 to
R2 may be part of a "BGP-free core", where there are no BGP-
distributed routes at all in the core. Or, as in [RFC5565], D may be
an IPv4 address while the intermediate routers along the path from R1
to R2 may support only IPv6.
In cases such as this, in order for R1 to properly forward packet P,
it must encapsulate P and send P "through a tunnel" to R2. For
example, R1 may encapsulate P using GRE, L2TPv3, IP in IP, etc.,
where the destination IP address of the encapsulation header is the
address of R2.
In order for R1 to encapsulate P for transport to R2, R1 must know
what encapsulation protocol to use for transporting different sorts
of packets to R2. R1 must also know how to fill in the various
fields of the encapsulation header. With certain encapsulation
types, this knowledge may be acquired by default or through manual
configuration. Other encapsulation protocols have fields such as
session id, key, or cookie that must be filled in. It would not be
desirable to require every BGP speaker to be manually configured with
the encapsulation information for every one of its BGP next hops.
This document specifies a way in which BGP itself can be used by a
given BGP speaker to tell other BGP speakers, "if you need to
encapsulate packets to be sent to me, here's the information you need
to properly form the encapsulation header". A BGP speaker signals
this information to other BGP speakers by using a new BGP attribute
type value, the BGP Tunnel Encapsulation Attribute. This attribute
specifies the encapsulation protocols that may be used as well as
whatever additional information (if any) is needed in order to
properly use those protocols. Other attributes, e.g., communities or
extended communities, may also be included.
1.4. Brief Summary of Changes from RFC 5512
This document addresses these deficiencies by: This document addresses these deficiencies by:
o Deprecating the Encapsulation SAFI. o Deprecating the Encapsulation SAFI.
o Defining a new "Tunnel Egress Endpoint sub-TLV" (Section 3.1) that o Defining a new "Tunnel Egress Endpoint sub-TLV" (Section 3.1) that
can be included in any of the TLVs contained in the Tunnel can be included in any of the TLVs contained in the Tunnel
Encapsulation attribute. This sub-TLV can be used to specify the Encapsulation attribute. This sub-TLV can be used to specify the
remote endpoint address of a particular tunnel. remote endpoint address of a particular tunnel.
skipping to change at page 5, line 51 skipping to change at page 6, line 44
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 o Defining the sub-TLV type field so that a sub-TLV whose type is in
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 (Generic Protocol Extension for VXLAN,
[I-D.ietf-nvo3-vxlan-gpe]), NVGRE (Network Virtualization Using [I-D.ietf-nvo3-vxlan-gpe]), NVGRE (Network Virtualization Using
Generic Routing Encapsulation [RFC7637]), and MPLS-in-GRE (MPLS in Generic Routing Encapsulation [RFC7637]), and MPLS-in-GRE (MPLS in
Generic Routing Encapsulation [RFC4023]). MPLS-in-UDP [RFC7510] is Generic Routing Encapsulation [RFC4023]). MPLS-in-UDP [RFC7510] is
also supported, but an Encapsulation sub-TLV for it is not needed. 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
skipping to change at page 6, line 41 skipping to change at page 7, line 34
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 describes (Section 4.1) how the Tunnel circumstances. This document describes (Section 4.1) how the Tunnel
Encapsulation Extended Community can be used in a backwards- Encapsulation Extended Community can be used in a backwards-
compatible fashion. It is possible to combine Tunnel Encapsulation compatible fashion. It is possible to combine Tunnel Encapsulation
Extended Communities and Tunnel Encapsulation attributes in the same Extended Communities and Tunnel Encapsulation attributes in the same
BGP UPDATE in this manner. BGP UPDATE in this manner.
1.4. Use Case for The Tunnel Encapsulation Attribute
Consider the case of a router R1 forwarding an IP packet P. Let D be
P's IP destination address. R1 must look up D in its forwarding
table. Suppose that the "best match" route for D is route Q, where Q
is a BGP-distributed route whose "BGP next hop" is router R2. And
suppose further that the routers along the path from R1 to R2 have
entries for R2 in their forwarding tables, but do NOT have entries
for D in their forwarding tables. For example, the path from R1 to
R2 may be part of a "BGP-free core", where there are no BGP-
distributed routes at all in the core. Or, as in [RFC5565], D may be
an IPv4 address while the intermediate routers along the path from R1
to R2 may support only IPv6.
In cases such as this, in order for R1 to properly forward packet P,
it must encapsulate P and send P "through a tunnel" to R2. For
example, R1 may encapsulate P using GRE, L2TPv3, IP in IP, etc.,
where the destination IP address of the encapsulation header is the
address of R2.
In order for R1 to encapsulate P for transport to R2, R1 must know
what encapsulation protocol to use for transporting different sorts
of packets to R2. R1 must also know how to fill in the various
fields of the encapsulation header. With certain encapsulation
types, this knowledge may be acquired by default or through manual
configuration. Other encapsulation protocols have fields such as
session id, key, or cookie that must be filled in. It would not be
desirable to require every BGP speaker to be manually configured with
the encapsulation information for every one of its BGP next hops.
This document specifies a way in which BGP itself can be used by a
given BGP speaker to tell other BGP speakers, "if you need to
encapsulate packets to be sent to me, here's the information you need
to properly form the encapsulation header". A BGP speaker signals
this information to other BGP speakers by using a new BGP attribute
type value, the BGP Tunnel Encapsulation Attribute. The Tunnel
Encapsulation attribute MAY be used in any BGP UPDATE message whose
AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6 Unicast), 1/4 (IPv4 Labeled
Unicast), 2/4 (IPv6 Labeled Unicast), 1/128 (VPN-IPv4 Labeled
Unicast), 2/128 (VPN-IPv6 Labeled Unicast), or 25/70 (Ethernet VPN,
usually known as EVPN)).
In a given BGP update, the encapsulation information is specified in
the BGP Tunnel Encapsulation Attribute. This attribute specifies the
encapsulation protocols that may be used as well as whatever
additional information (if any) is needed in order to properly use
those protocols. Other attributes, e.g., communities or extended
communities, may also be included.
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 Tunnel Encapsulation TLV, also known as particular Tunnel Type. A Tunnel Encapsulation TLV, also known as
Tunnel TLV, is structured as shown in Figure 1: Tunnel TLV, is structured as shown in Figure 1:
0 1 2 3 0 1 2 3
skipping to change at page 9, line 16 skipping to change at page 9, line 16
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
This section specifies a number of sub-TLVs. These sub-TLVs can be This section specifies a number of sub-TLVs. These sub-TLVs can be
included in a TLV of the Tunnel Encapsulation attribute. included in a TLV of the Tunnel Encapsulation attribute.
3.1. The Tunnel Egress Endpoint Sub-TLV 3.1. The Tunnel Egress Endpoint Sub-TLV
The Tunnel Egress Endpoint sub-TLV specifies the address of the The Tunnel Egress Endpoint sub-TLV, whose value is 6, specifies the
egress endpoint of the tunnel, that is, the address of the router address of the egress endpoint of the tunnel, that is, the address of
that will decapsulate the payload. Its value field contains three the router that will decapsulate the payload. Its value field
subfields: contains three subfields:
1. a reserved subfield 1. a reserved subfield
2. a two-octet Address Family subfield 2. a two-octet Address Family subfield
3. an Address subfield, whose length depends upon the Address 3. an Address subfield, whose length depends upon the Address
Family. Family.
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 43 skipping to change at page 10, line 43
o The length of the sub-TLV's Value field is other than 6 plus the o The length of the sub-TLV's Value field is other than 6 plus the
defined length for the address family given in its Address Family defined length for the address family given in its Address Family
subfield. Therefore, for address family behaviors defined in this subfield. Therefore, for address family behaviors defined in this
document, the permitted values are: document, the permitted values are:
* 10, if the Address Family subfield contains the value for IPv4. * 10, if the Address Family subfield contains the value for IPv4.
* 22, if the Address Family subfield contains the value for IPv6. * 22, if the Address Family subfield contains the value for IPv6.
* 0, if the Address Family subfield contains the value zero. * 6, if the Address Family subfield contains the value zero.
o The IP address in the sub-TLV's address subfield is listed in the o The IP address in the sub-TLV's address subfield lies within a
relevant Special-Purpose IP Address Registry [RFC6890] as either block listed in the relevant Special-Purpose IP Address Registry
not a valid destination, or not forwardable. [RFC6890] with either a "destination" attribute value or a
"forwardable" attribute value of "false". (Such routes are
sometimes colloquially known as "Martians".)
o It can be determined according to the procedures below o It can be determined according to the procedures below
(Section 3.1.1) that the IP address in the sub-TLV's address (Section 3.1.1) that the IP address in the sub-TLV's address
subfield does not belong to the Autonomous System (AS) that subfield does not belong to the Autonomous System (AS) that
originated the route that contains the attribute. originated the route that contains the attribute.
If the Tunnel Egress Endpoint sub-TLV is malformed, the TLV
containing it is also considered to be malformed. However, the
Tunnel Encapsulation attribute MUST NOT be considered to be malformed
in this case; other TLVs in the attribute MUST be processed (if they
can be parsed correctly).
Error Handling is detailed in Section 12. Error Handling is detailed in Section 12.
If the Tunnel Egress Endpoint sub-TLV contains an IPv4 or IPv6 If the Tunnel Egress Endpoint sub-TLV contains an IPv4 or IPv6
address that is valid but not reachable, the sub-TLV is NOT address that is valid but not reachable, the sub-TLV is not
considered to be malformed. considered to be malformed.
3.1.1. Validating the Address Field 3.1.1. Validating the Address Field
This section details a procedure that MAY be applied to validate that This section details a procedure that MAY be applied to validate that
when traffic is sent to the IP address depicted in the Address Field, the IP address in the sub-TLV's address subfield belongs to the AS
it will go to the same AS as it would go to if the Tunnel that originated the route that contains the attribute. (The notion
Encapsulation Attribute were not present. See Section 13 for of "belonging to" an AS is expanded on below.) Doing this is thought
to increase confidence that when traffic is sent to the IP address
depicted in the Address Field, it will go to the same AS as it would
go to if the Tunnel Encapsulation Attribute were not present,
although of course it cannot guarantee it. See Section 14 for
discussion of the limitations of this procedure. discussion of the limitations of this procedure.
The Route Origin ASN (Autonomous System Number) of a BGP route that The Route Origin ASN (Autonomous System Number) of a BGP route that
includes a Tunnel Encapsulation Attribute can be determined by includes a Tunnel Encapsulation Attribute can be determined by
inspection of the AS_PATH attribute, according to the procedure inspection of the AS_PATH attribute, according to the procedure
specified in [RFC6811] section 2. Call this value Route_AS. specified in [RFC6811] Section 2. Call this value Route_AS.
In order to determine the Route Origin ASN of the address depicted in In order to determine the Route Origin ASN of the address depicted in
the Address Field of the Tunnel Egress Endpoint sub-TLV, it is the Address Field of the Tunnel Egress Endpoint sub-TLV, it is
necessary to determine the forwarding route, that is, the route necessary to consider the forwarding route, that is, the route that
installed in the Forwarding Information Base that will be used to will be used to forward traffic toward that address. This route is
forward traffic toward that address. The Address Field's Route determined by a recursive route lookup operation for that address, as
Origin ASN is the Route Origin ASN of that route, or the discussed in [RFC4271] Section 5.1.3. The relevant AS Path to
distinguished value "NONE2" if the forwarding route has no AS Path, consider is the last one encountered while performing the recursive
for example if that route's source is a protocol other than BGP. lookup; the procedures of RFC6811 Section 2 are applied to that AS
(Note that this is a distinct case from a route that has an empty AS Path to determine the Route Origin ASN. If no AS Path is encountered
Path.) Call this value Egress_AS. at all, for example if that route's source is a protocol other than
BGP, the Route Origin ASN is the BGP speaker's own AS number. Call
this value Egress_AS.
If Route_AS does not equal Egress_AS, then the Tunnel Egress Endpoint If Route_AS does not equal Egress_AS, then the Tunnel Egress Endpoint
sub-TLV is considered not to be valid. In some cases a network sub-TLV is considered not to be valid. In some cases a network
operator who controls a set of Autonomous Systems might wish to allow operator who controls a set of Autonomous Systems might wish to allow
a Tunnel Egress Endpoint to reside in an AS other than Route_AS; a Tunnel Egress Endpoint to reside in an AS other than Route_AS;
configuration MAY allow for such a case, in which case the check configuration MAY allow for such a case, in which case the check
becomes, if Egress_AS is not within the configured set of permitted becomes, if Egress_AS is not within the configured set of permitted
AS numbers, then the Tunnel Egress Endpoint sub-TLV is considered not AS numbers, then the Tunnel Egress Endpoint sub-TLV is considered to
to be valid. be "malformed".
Note that if the forwarding route changes, this procedure MUST be Note that if the forwarding route changes, this procedure MUST be
reapplied. As a result, a sub-TLV that was formerly considered valid reapplied. As a result, a sub-TLV that was formerly considered valid
might become not valid, or vice-versa. might become not valid, or vice-versa.
3.2. Encapsulation Sub-TLVs for Particular Tunnel Types 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types
This section defines Encapsulation sub-TLVs for the following tunnel This section defines Encapsulation sub-TLVs for the following tunnel
types: VXLAN ([RFC7348]), VXLAN GPE ([I-D.ietf-nvo3-vxlan-gpe]), types: VXLAN ([RFC7348]), VXLAN GPE ([I-D.ietf-nvo3-vxlan-gpe]),
NVGRE ([RFC7637]), MPLS-in-GRE ([RFC4023]), L2TPv3 ([RFC3931]), and NVGRE ([RFC7637]), MPLS-in-GRE ([RFC4023]), L2TPv3 ([RFC3931]), and
skipping to change at page 12, line 45 skipping to change at page 12, line 49
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 VN-ID (Virtual Network V: This bit is set to 1 to indicate that a VN-ID (Virtual Network
Identifier) is present in the Encapsulation sub-TLV. If set to 0, Identifier) is present in the Encapsulation sub-TLV. If set to 0,
the VN-ID field is disregarded. Please see Section 8. the VN-ID field is disregarded. Please see Section 9.
M: This bit is set to 1 to indicate that a MAC Address is present M: This bit is set to 1 to indicate that a MAC Address is present
in the Encapsulation sub-TLV. If set to 0, the MAC Address field in the Encapsulation sub-TLV. If set to 0, the MAC Address field
is disregarded. is disregarded.
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 MUST always be set to 0 by the originator of further use. They MUST always be set to 0 by the originator of
the sub-TLV. Intermediate routers MUST propagate them without the sub-TLV. Intermediate routers MUST propagate them without
modification. Any receiving routers MUST ignore these bits upon a modification. Any receiving routers MUST ignore these bits upon a
receipt of the sub-TLV. receipt of the sub-TLV.
skipping to change at page 13, line 43 skipping to change at page 13, line 50
If the M bit is not set, and the payload being sent through the If the M bit is not set, and the payload being sent through the
VXLAN tunnel is an IP or MPLS packet, the Inner Destination MAC VXLAN tunnel is an IP or MPLS packet, the Inner Destination MAC
address field is set to a configured value; if there is no address field is set to a configured value; if there is no
configured value, the VXLAN tunnel cannot be used. configured value, the VXLAN tunnel cannot be used.
o If the V bit is not set, and the BGP UPDATE message has AFI/SAFI o If the V bit is not set, and the BGP UPDATE message has AFI/SAFI
other than Ethernet VPNs (EVPN) then the VXLAN tunnel cannot be other than Ethernet VPNs (EVPN) then the VXLAN tunnel cannot be
used. used.
o Section 8 describes how the VNI field of the VXLAN encapsulation o Section 9 describes how the VNI field of the VXLAN encapsulation
header is set. header is set.
Note that in order to send an IP packet or an MPLS packet through a Note that in order to send an IP packet or an MPLS packet through a
VXLAN tunnel, the packet must first be encapsulated in an Ethernet VXLAN tunnel, the packet must first be encapsulated in an Ethernet
header, which becomes the "inner Ethernet header" described in header, which becomes the "inner Ethernet header" described in
[RFC7348]. The VXLAN Encapsulation sub-TLV may contain information [RFC7348]. The VXLAN Encapsulation sub-TLV may contain information
(e.g.,the MAC address) that is used to form this Ethernet header. (e.g.,the MAC address) that is used to form this Ethernet header.
3.2.2. VXLAN GPE 3.2.2. VXLAN GPE
skipping to change at page 14, line 31 skipping to change at page 14, line 37
Version (Ver): Indicates VXLAN GPE protocol version. (See the Version (Ver): Indicates VXLAN GPE protocol version. (See the
"Version Bits" section of [I-D.ietf-nvo3-vxlan-gpe].) If the "Version Bits" section of [I-D.ietf-nvo3-vxlan-gpe].) If the
indicated version is not supported, the TLV that contains this indicated version is not supported, the TLV that contains this
Encapsulation sub-TLV MUST be treated as specifying an unsupported Encapsulation sub-TLV MUST be treated as specifying an unsupported
Tunnel Type. The value of this field will be copied into the Tunnel Type. The value of this field will be copied into the
corresponding field of the VXLAN encapsulation header. corresponding field of the VXLAN encapsulation header.
V: This bit is set to 1 to indicate that a VN-ID is present in the V: This bit is set to 1 to indicate that a VN-ID is present in the
Encapsulation sub-TLV. If set to 0, the VN-ID field is Encapsulation sub-TLV. If set to 0, the VN-ID field is
disregarded. Please see Section 8. disregarded. Please see Section 9.
R: The bits designated "R" above are reserved for future use. R: The bits designated "R" above are reserved for future use.
They MUST always be set to 0 by the originator of the sub-TLV. They MUST always be set to 0 by the originator of the sub-TLV.
Intermediate routers MUST propagate them without modification. Intermediate routers MUST propagate them without modification.
Any receiving routers MUST ignore these bits upon a receipt. Any receiving routers MUST ignore these bits upon a receipt.
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 MUST be set to zero on value. If the V bit is not set, this field MUST be set to zero on
transmission and disregarded on receipt. transmission and disregarded on receipt.
Reserved (two fields): MUST be set to zero on transmission and Reserved (two fields): MUST be set to zero on transmission and
disregarded on receipt. disregarded on receipt.
When forming the VXLAN GPE encapsulation header: When forming the VXLAN GPE encapsulation header:
o The values of the V and R bits are NOT copied into the flags field o The values of the V and R bits are NOT copied into the flags field
of the VXLAN GPE header. However, the values of the Ver bits are of the VXLAN GPE header. However, the values of the Ver bits are
copied into the VXLAN GPE header. Other bits in the flags field copied into the VXLAN GPE header. Other bits in the flags field
of the VXLAN GPE header are set as per [I-D.ietf-nvo3-vxlan-gpe]. of the VXLAN GPE header are set as per [I-D.ietf-nvo3-vxlan-gpe].
o Section 8 describes how the VNI field of the VXLAN GPE o Section 9 describes 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 (value 9), the length of the sub-TLV is When the Tunnel Type is NVGRE (value 9), the length of the sub-TLV is
12 octets. The following is the structure of the value field in the 12 octets. The following is the structure of the value field in the
Encapsulation sub-TLV: Encapsulation sub-TLV:
0 1 2 3 0 1 2 3
skipping to change at page 15, line 29 skipping to change at page 15, line 34
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 6: NVGRE Encapsulation Sub-TLV
V: This bit is set to 1 to indicate that a VN-ID is present in the V: This bit is set to 1 to indicate that a VN-ID is present in the
Encapsulation sub-TLV. If set to 0, the VN-ID field is Encapsulation sub-TLV. If set to 0, the VN-ID field is
disregarded. Please see Section 8. disregarded. Please see Section 9.
M: This bit is set to 1 to indicate that a MAC Address is present M: This bit is set to 1 to indicate that a MAC Address is present
in the Encapsulation sub-TLV. If set to 0, the MAC Address field in the Encapsulation sub-TLV. If set to 0, the MAC Address field
is disregarded. is disregarded.
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 MUST always be set to 0 by the originator of further use. They MUST always be set to 0 by the originator of
the sub-TLV. Intermediate routers MUST propagate them without the sub-TLV. Intermediate routers MUST propagate them without
modification. Any receiving routers MUST ignore these bits upon modification. Any receiving routers MUST ignore these bits upon
receipt. receipt.
skipping to change at page 16, line 27 skipping to change at page 16, line 32
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 If the V bit is not set, and the BGP UPDATE message has AFI/SAFI o If the V bit is not set, and the BGP UPDATE message has AFI/SAFI
other than Ethernet VPNs (EVPN) then the NVGRE tunnel cannot be other than Ethernet VPNs (EVPN) then the NVGRE tunnel cannot be
used. used.
o Section 8 describes how the VSID (Virtual Subnet Identifier) field o Section 9 describes how the VSID (Virtual Subnet Identifier) field
of the NVGRE encapsulation header is set. 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 (value 1), the When the Tunnel Type of the TLV is L2TPv3 over IP (value 1), the
length of the sub-TLV is between 4 and 12 octets, depending on the length of the sub-TLV is between 4 and 12 octets, depending on the
length of the cookie. The following is the structure of the value length of the cookie. The following is the structure of the value
field of the Encapsulation sub-TLV: field of the Encapsulation sub-TLV:
0 1 2 3 0 1 2 3
skipping to change at page 19, line 48 skipping to change at page 19, line 50
for "X-in-Y" type tunnels, a Protocol Type sub-TLV specifying for "X-in-Y" type tunnels, a Protocol Type sub-TLV specifying
anything other than "X" MUST be ignored; this is discussed further in anything other than "X" MUST be ignored; this is discussed further in
Section 12. Section 12.
3.4.2. Color Sub-TLV 3.4.2. Color Sub-TLV
The Color sub-TLV, whose type code is 4, MAY be used as a way to The Color sub-TLV, whose type code is 4, MAY be used as a way to
"color" the corresponding Tunnel TLV. The value field of the sub-TLV "color" the corresponding Tunnel TLV. The value field of the sub-TLV
is eight octets long, and consists of a Color Extended Community, as is eight octets long, and consists of a Color Extended Community, as
defined in Section 4.3. For the use of this sub-TLV and Extended defined in Section 4.3. For the use of this sub-TLV and Extended
Community, please see Section 7. Community, please see Section 8.
If the Length field of a Color sub-TLV has a value other than 8, or If the Length field of a Color sub-TLV has a value other than 8, or
the first two octets of its value field are not 0x030b, the sub-TLV the first two octets of its value field are not 0x030b, the sub-TLV
should be treated as if it were an unrecognized sub-TLV (see MUST be treated as if it were an unrecognized sub-TLV (see
Section 12). Section 12).
3.5. Embedded Label Handling Sub-TLV 3.5. Embedded Label Handling Sub-TLV
Certain BGP address families (corresponding to particular AFI/SAFI Certain BGP address families (corresponding to particular AFI/SAFI
pairs, e.g., 1/4, 2/4, 1/128, 2/128) have MPLS labels embedded in pairs, e.g., 1/4, 2/4, 1/128, 2/128) have MPLS labels embedded in
their NLRIs. The term "embedded label" is used to refer to the MPLS their NLRIs. The term "embedded label" is used to refer to the MPLS
label that is embedded in an NLRI, and the term "labeled address label that is embedded in an NLRI, and the term "labeled address
family" to refer to any AFI/SAFI that has embedded labels. family" to refer to any AFI/SAFI that has embedded labels.
skipping to change at page 20, line 37 skipping to change at page 20, line 40
and/or the virtual network identifier. The Embedded Label Handling and/or the virtual network identifier. The Embedded Label Handling
sub-TLV can be used to control the placement of the embedded label sub-TLV can be used to control the placement of the embedded label
and/or the virtual network identifier in the encapsulation. and/or the virtual network identifier in the encapsulation.
The Embedded Label Handling sub-TLV, whose type code is 9, may be The Embedded Label Handling sub-TLV, whose type code is 9, may be
included in any TLV of the Tunnel Encapsulation attribute. If the included in any TLV of the Tunnel Encapsulation attribute. If the
Tunnel Encapsulation attribute is attached to an UPDATE of a non- Tunnel Encapsulation attribute is attached to an UPDATE of a non-
labeled address family, then the sub-TLV MUST be disregarded. If the labeled address family, then the sub-TLV MUST be disregarded. If the
sub-TLV is contained in a TLV whose Tunnel Type does not have a sub-TLV is contained in a TLV whose Tunnel Type does not have a
virtual network identifier in its encapsulation header, the sub-TLV virtual network identifier in its encapsulation header, the sub-TLV
MUST be disregared. In those cases where the sub-TLV is ignored, it MUST be disregarded. In those cases where the sub-TLV is ignored, it
SHOULD NOT be stripped from the TLV before the route is propagated. SHOULD NOT be stripped from the TLV before the route is propagated.
The sub-TLV's Length field always contains the value 1, and its value The sub-TLV's Length field always contains the value 1, and its value
field consists of a single octet. The following values are defined: field consists of a single octet. The following values are defined:
1: The payload will be an MPLS packet with the embedded label at 1: The payload will be an MPLS packet with the embedded label at
the top of its label stack. the top of its label stack.
2: The embedded label is not carried in the payload, but is carried 2: The embedded label is not carried in the payload, but is carried
either in the virtual network identifier field of the either in the virtual network identifier field of the
encapsulation header, or else is ignored entirely. encapsulation header, or else is ignored entirely.
Please see Section 8 for the details of how this sub-TLV is used when Please see Section 9 for the details of how this sub-TLV is used when
it is carried by an UPDATE of a labeled address family. it is carried by an UPDATE of a labeled address family.
3.6. MPLS Label Stack Sub-TLV 3.6. MPLS Label Stack Sub-TLV
This sub-TLV, whose type code is 10, allows an MPLS label stack This sub-TLV, whose type code is 10, allows an MPLS label stack
([RFC3032]) to be associated with a particular tunnel. ([RFC3032]) to be associated with a particular tunnel.
The length of the sub-TLV is a multiple of 4 octets and the value The length of the sub-TLV is a multiple of 4 octets and the value
field of this sub-TLV is a sequence of MPLS label stack entries. The field of this sub-TLV is a sequence of MPLS label stack entries. The
first entry in the sequence is the "topmost" label, the final entry first entry in the sequence is the "topmost" label, the final entry
skipping to change at page 21, line 39 skipping to change at page 21, line 42
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 before any other labels are pushed onto the packet. packet before any other labels are pushed onto the packet.
In particular, if the Tunnel Encapsulation attribute is attached to a In particular, if the Tunnel Encapsulation attribute is attached to a
BGP UPDATE of a labeled address family, the contents of the MPLS BGP UPDATE of a labeled address family, the contents of the MPLS
Label Stack sub-TLV MUST be pushed onto the packet before the label Label Stack sub-TLV MUST be pushed onto the packet before the label
embedded in the NLRI is pushed onto the packet. embedded in the NLRI is pushed onto the packet.
If the MPLS Label Stack sub-TLV is included in a TLV identifying a If the MPLS Label Stack sub-TLV is included in a TLV identifying a
Tunnel Type that uses virtual network identifiers (see Section 8), Tunnel Type that uses virtual network identifiers (see Section 9),
the contents of the MPLS Label Stack sub-TLV MUST be pushed onto the the contents of the MPLS Label Stack sub-TLV MUST be pushed onto the
packet before the procedures of Section 8 are applied. packet before the procedures of Section 9 are applied.
The number of label stack entries in the sub-TLV MUST be determined The number of label stack entries in the sub-TLV MUST be determined
from the sub-TLV length field. Thus it is not necessary to set the S from the sub-TLV length field. Thus it is not necessary to set the S
bit in any of the label stack entries of the sub-TLV, and the setting bit in any of the label stack entries of the sub-TLV, and the setting
of the S bit is ignored when parsing the sub-TLV. When the label of the S bit is ignored when parsing the sub-TLV. When the label
stack entries are pushed onto a packet that already has a label stack entries are pushed onto a packet that already has a label
stack, the S bits of all the entries being pushed MUST be cleared. stack, the S bits of all the entries being pushed MUST be cleared.
When the label stack entries are pushed onto a packet that does not When the label stack entries are pushed onto a packet that does not
already have a label stack, the S bit of the bottommost label stack already have a 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 entry MUST be set, and the S bit of all the other label stack entries
skipping to change at page 22, line 42 skipping to change at page 22, line 45
or more TLVs, where each TLV is either a "Label-Index" TLV, or an or more TLVs, where each TLV is either a "Label-Index" TLV, or an
"Originator SRGB (Source Routing Global Block)" TLV. "Originator SRGB (Source Routing Global Block)" TLV.
This document defines a Prefix-SID sub-TLV, whose type code is 11. This document defines a Prefix-SID sub-TLV, whose type code is 11.
The value field of the Prefix-SID sub-TLV can be set to any permitted The value field of the Prefix-SID sub-TLV can be set to any permitted
value of the value field of a BGP Prefix-SID attribute [RFC8669]. value of the value field of a BGP Prefix-SID attribute [RFC8669].
[RFC8669] only defines behavior when the Prefix-SID Attribute is [RFC8669] only defines behavior when the Prefix-SID Attribute is
attached to routes of type IPv4/IPv6 Labeled Unicast ([RFC4760], attached to routes of type IPv4/IPv6 Labeled Unicast ([RFC4760],
[RFC8277]), and it only defines values of the Prefix-SID Attribute [RFC8277]), and it only defines values of the Prefix-SID Attribute
when attached to routes of those types. Therefore, similar for those cases. Therefore, similar limitations exist for the
limitations exist for the Prefix-SID sub-TLV: although it MAY be Prefix-SID sub-TLV: it SHOULD only be included in a BGP UPDATE
encoded in any BGP UPDATE message where the Tunnel Encapsulation message for one of the address families defined in [RFC8669]. If
attribute is allowed (see Section 5), the encoded information MUST be included in a BGP UPDATE for any other address family then it MUST be
ignored just as the base specification that defines the encoding ignored.
requires. So, in the case of the values specified in [RFC8669], they
MUST be ignored if received with routes of type other than IPv4/IPv6
Labeled Unicast.
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 egress MUST be interpreted to be the SRGB used by the tunnel's egress
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 egress endpoint uses to represent the prefix that the tunnel's egress endpoint uses to represent the prefix
appearing in the NLRI field of the BGP UPDATE to which the Tunnel appearing in the NLRI field of the BGP UPDATE to which the Tunnel
Encapsulation attribute is attached. Encapsulation attribute is attached.
If a Label-Index is present in the Prefix-SID sub-TLV, then when a If a Label-Index is present in the Prefix-SID sub-TLV, then when a
packet is sent through the tunnel identified by the TLV, the packet is sent through the tunnel identified by the TLV, the
corresponding MPLS label MUST be pushed on the packet's label stack. corresponding MPLS label MUST be pushed on the packet's label stack.
The corresponding MPLS label is computed from the Label-Index value The corresponding MPLS label is computed from the Label-Index value
and the SRGB of the route's originator, as specified in section 4.1 and the SRGB of the route's originator, as specified in section 4.1
of [RFC8669]. of [RFC8669].
The corresponding MPLS label is pushed on after the processing of the The corresponding MPLS label is pushed on after the processing of the
MPLS Label Stack sub-TLV, if present, as specified in Section 3.6. MPLS Label Stack sub-TLV, if present, as specified in Section 3.6.
It is pushed on before any other labels (e.g., a label embedded in It is pushed on before any other labels (e.g., a label embedded in
UPDATE's NLRI, or a label determined by the procedures of Section 8, UPDATE's NLRI, or a label determined by the procedures of Section 9,
are pushed on the stack. are pushed on the stack.
The Prefix-SID sub-TLV has slightly different semantics than the The Prefix-SID sub-TLV has slightly different semantics than the
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 what the prefix-SID is Label-Index tells the receiving BGP speakers what 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 receiving BGP speaker need not even Prefix-SID sub-TLV is used, the receiving BGP speaker need not even
skipping to change at page 25, line 22 skipping to change at page 25, line 22
4.2. Router's MAC Extended Community 4.2. Router's MAC Extended Community
[I-D.ietf-bess-evpn-inter-subnet-forwarding] defines a Router's MAC [I-D.ietf-bess-evpn-inter-subnet-forwarding] defines a Router's MAC
Extended Community. This Extended Community, as its name implies, Extended Community. This Extended Community, as its name implies,
carries the MAC address of the advertising router. Since the VXLAN carries the MAC address of the advertising router. Since the VXLAN
and NVGRE Encapsulation Sub-TLVs can also optionally carry a router's and NVGRE Encapsulation Sub-TLVs can also optionally carry a router's
MAC, a conflict can arise if both the Router's MAC Extended Community MAC, a conflict can arise if both the Router's MAC Extended Community
and such an Encapsulation Sub-TLV are present at the same time but and such an Encapsulation Sub-TLV are present at the same time but
have different values. In case of such a conflict, the information have different values. In case of such a conflict, the information
in the Encapsulation Sub-TLV MUST be used. in the Router's MAC Extended Community MUST be used.
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 | Flags | | 0x03 | 0x0b | Flags |
skipping to change at page 25, line 48 skipping to change at page 25, line 48
The value of the high-order octet of the extended type field is 0x03, The value of the high-order octet of the extended type field is 0x03,
which indicates it is transitive. The value of the low-order octet which indicates it is transitive. The value of the low-order octet
of the extended type field for this community is 0x0b. The color of the extended type field for this community is 0x0b. The color
value is user defined and configured locally. No flags are defined value is user defined and configured locally. No flags are defined
in this document; this field MUST be set to zero by the originator in this document; this field MUST be set to zero by the originator
and ignored by the receiver; the value MUST NOT be changed when and ignored by the receiver; the value MUST NOT be changed when
propagating this Extended Community. The Color Value field is propagating this Extended Community. The Color Value field is
encoded as 4 octet value by the administrator and is outside the encoded as 4 octet value by the administrator and is outside the
scope of this document. For the use of this Extended Community scope of this document. For the use of this Extended Community
please see Section 7. please see Section 8.
5. Special Considerations for IP-in-IP Tunnels 5. Special Considerations for IP-in-IP Tunnels
In certain situations with an IP fabric underlay, one could have a In certain situations with an IP fabric underlay, one could have a
tunnel overlay with the tunnel type IP-in-IP. The egress BGP speaker tunnel overlay with the tunnel type IP-in-IP. The egress BGP speaker
can advertise the IP-in-IP tunnel endpoint address in the Tunnel can advertise the IP-in-IP tunnel endpoint address in the Tunnel
Egress Endpoint sub-TLV. When the Tunnel type of the TLV is IP-in- Egress Endpoint sub-TLV. When the Tunnel type of the TLV is IP-in-
IP, it will not have a Virtual Network Identifier. However, the IP, it will not have a Virtual Network Identifier. However, the
tunnel egress endpoint address can be used in identifying the tunnel egress endpoint address can be used in identifying the
forwarding table to use for making the forwarding decisions to forwarding table to use for making the forwarding decisions to
forward the payload. See the second bullet point of Section 9.1 for forward the payload.
further discussion.
6. Semantics and Usage of the Tunnel Encapsulation attribute 6. 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 messages of those SAFIs. This the use of this attribute to UPDATE messages 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 (Ethernet VPN, usually known as EVPN)). Use of the Tunnel or 25/70 (Ethernet VPN, usually known as EVPN)). Use of the Tunnel
Encapsulation attribute in BGP UPDATE messages of other AFI/SAFIs is Encapsulation attribute in BGP UPDATE messages of other AFI/SAFIs is
outside the scope of this document. outside the scope of this document.
There is no significance to the order in which the TLVs occur within There is no significance to the order in which the TLVs occur within
the Tunnel Encapsulation attribute. Multiple TLVs may occur for a the Tunnel Encapsulation attribute. Multiple TLVs may occur for a
given Tunnel Type; each such TLV is regarded as describing a given Tunnel Type; each such TLV is regarded as describing a
different tunnel. different tunnel. (This also applies if the Tunnel Encapsulation
Extended Community encoding is used.)
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.
Suppose that: Suppose that:
o a given packet P must be forwarded by router R; o a given packet P must be forwarded by router R;
o the path along which P is to be forwarded is determined by BGP o the path along which P is to be forwarded is determined by BGP
UPDATE U; UPDATE U;
o UPDATE U has a Tunnel Encapsulation attribute, containing at least o UPDATE U has a Tunnel Encapsulation attribute, containing at least
one TLV that identifies a "feasible tunnel" for packet P. A one TLV that identifies a "feasible tunnel" for packet P. A
tunnel is considered feasible if it has the following three tunnel is considered feasible if it has the following four
properties: properties:
* The Tunnel Type is supported (i.e., router R knows how to set * The Tunnel Type is supported (i.e., router R knows how to set
up tunnels of that type, how to create the encapsulation header up tunnels of that type, how to create the encapsulation header
for tunnels of that type, etc.) for tunnels of that type, etc.)
* The tunnel is of a type that can be used to carry packet P * The tunnel is of a type that can be used to carry packet P
(e.g., an MPLS-in-UDP tunnel would not be a feasible tunnel for (e.g., an MPLS-in-UDP tunnel would not be a feasible tunnel for
carrying an IP packet, UNLESS the IP packet can first be carrying an IP packet, unless the IP packet can first be
encapsulated in a MPLS packet). encapsulated in a MPLS packet).
* The tunnel is specified in a TLV whose Tunnel Egress Endpoint * The tunnel is specified in a TLV whose Tunnel Egress Endpoint
sub-TLV identifies an IP address that is reachable. This IP sub-TLV identifies an IP address that is reachable. This IP
address may be reachable via one or more forwarding tables. address may be reachable via one or more forwarding tables.
Local policy may determine these forwarding tables and is Local policy may determine these forwarding tables and is
outside the scope of this document. The reachability condition outside the scope of this document. The reachability condition
is evaluated as per [RFC4271]. is evaluated as per [RFC4271], but the essence is that if the
router could forward a packet addressed to the IP address, the
IP address is "reachable".
* There is no local policy that prevents the use of the tunnel.
Then router R MUST send packet P through one of the feasible tunnels Then router R MUST send packet P through one of the feasible tunnels
identified in the Tunnel Encapsulation attribute of UPDATE U. identified in the Tunnel Encapsulation attribute of UPDATE U.
If the Tunnel Encapsulation attribute contains several TLVs (i.e., if If the Tunnel Encapsulation attribute contains several TLVs (i.e., if
it specifies several feasibile tunnels), router R may choose any one it specifies several feasible tunnels), router R may choose any one
of those tunnels, based upon local policy. If any Tunnel TLV of those tunnels, based upon local policy. If any Tunnel TLV
contains one or more Color sub-TLVs (Section 3.4.2) and/or the contains one or more Color sub-TLVs (Section 3.4.2) and/or the
Protocol Type sub-TLV (Section 3.4.1), the choice of tunnel may be Protocol Type sub-TLV (Section 3.4.1), the choice of tunnel may be
influenced by these sub-TLVs. influenced by these sub-TLVs.
The reachability to the address of the egress endpoint of the tunnel The reachability to the address of the egress endpoint of the tunnel
may change over time, directly impacting the feasibility of the may change over time, directly impacting the feasibility of the
tunnel. A tunnel that is not feasible at some moment, may become tunnel. A tunnel that is not feasible at some moment, may become
feasible at a later time when its egress endpoint address is feasible at a later time when its egress endpoint address is
reachable. The router MAY start using the newly feasible tunnel reachable. The router may start using the newly feasible tunnel
instead of an existing one. How this decision is made is outside the instead of an existing one. How this decision is made is outside the
scope of this document. scope of this document.
Once it is determined to send a packet through the tunnel specified Once it is determined to send a packet through the tunnel specified
in a particular Tunnel TLV of a particular Tunnel Encapsulation in a particular Tunnel TLV of a particular Tunnel Encapsulation
attribute, then the tunnel's egress endpoint address is the IP attribute, then the tunnel's egress endpoint address is the IP
address contained in the sub-TLV. If the Tunnel TLV contains a address contained in the sub-TLV. If the Tunnel TLV contains a
Tunnel Egress Endpoint sub-TLV whose value field is all zeroes, then Tunnel Egress Endpoint sub-TLV whose value field is all zeroes, then
the tunnel's egress endpoint is the address of the Next Hop of the the tunnel's egress endpoint is the address of the Next Hop of the
BGP Update containing the Tunnel Encapsulation attribute. The BGP Update containing the Tunnel Encapsulation attribute. The
skipping to change at page 28, line 16 skipping to change at page 28, line 21
Sending a packet through a tunnel always requires that the packet be Sending a packet through a tunnel always requires that the packet be
encapsulated, with an encapsulation header that is appropriate for encapsulated, with an encapsulation header that is appropriate for
the Tunnel Type. The contents of the tunnel encapsulation header may the Tunnel Type. The contents of the tunnel encapsulation header may
be influenced by the Encapsulation sub-TLV. If there is no be influenced by the Encapsulation sub-TLV. If there is no
Encapsulation sub-TLV present, the router transmitting the packet Encapsulation sub-TLV present, the router transmitting the packet
through the tunnel must have a priori knowledge (e.g., by through the tunnel must have a priori knowledge (e.g., by
provisioning) of how to fill in the various fields in the provisioning) of how to fill in the various fields in the
encapsulation header. encapsulation header.
If a Tunnel Encapsulation attribute specifies several tunnels, the
way in which a router chooses which one to use is a matter of policy,
In addition to the reachability to the address of the egress endpoint
of the tunnel, other policy factors MAY be used to determine the
feasibility of the tunnel. The policy factors are beyond the scope
of this document.
A Tunnel Encapsulation attribute may contain several TLVs that all A Tunnel Encapsulation attribute may contain several TLVs that all
specify the same Tunnel Type. Each TLV should be considered as specify the same Tunnel Type. Each TLV should be considered as
specifying a different tunnel. Two tunnels of the same type may have specifying a different tunnel. Two tunnels of the same type may have
different Tunnel Egress Endpoint sub-TLVs, different Encapsulation different Tunnel Egress Endpoint sub-TLVs, different Encapsulation
sub-TLVs, etc. Choosing between two such tunnels is a matter of sub-TLVs, etc. Choosing between two such tunnels is a matter of
local policy. local policy.
Once router R has decided to send packet P through a particular Once router R has decided to send packet P through a particular
tunnel, it encapsulates packet P appropriately and then forwards it tunnel, it encapsulates packet P appropriately and then forwards it
according to the route that leads to the tunnel's egress endpoint. according to the route that leads to the tunnel's egress endpoint.
skipping to change at page 30, line 10 skipping to change at page 30, line 4
operators are encouraged to avoid mutually recursive route and/or operators are encouraged to avoid mutually recursive route and/or
tunnel dependencies. There is greater potential for such scenarios tunnel dependencies. There is greater potential for such scenarios
to arise when the tunnel egress endpoint for a given prefix differs to arise when the tunnel egress endpoint for a given prefix differs
from the address of the next hop for that prefix. from the address of the next hop for that prefix.
8. Recursive Next Hop Resolution 8. Recursive Next Hop Resolution
Suppose that: Suppose that:
o a given packet P must be forwarded by router R1; o a given packet P must be forwarded by router R1;
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 U1; UPDATE U1;
o UPDATE U1 does not have a Tunnel Encapsulation attribute; o UPDATE U1 does not have a Tunnel Encapsulation attribute;
o the address of the next hop of UPDATE U1 is router R2; o the address of the next hop of UPDATE U1 is router R2;
o the best path to router R2 is a BGP route that was advertised in o the best route to router R2 is a BGP route that was advertised in
UPDATE U2; UPDATE U2;
o UPDATE U2 has a Tunnel Encapsulation attribute. o UPDATE U2 has a Tunnel Encapsulation attribute.
Then packet P MUST be sent through one of the tunnels identified in Then packet P MUST be sent through one of the tunnels identified in
the Tunnel Encapsulation attribute of UPDATE U2. See Section 6 for the Tunnel Encapsulation attribute of UPDATE U2. See Section 6 for
further details. further details.
However, suppose that one of the TLVs in U2's Tunnel Encapsulation However, suppose that one of the TLVs in U2's Tunnel Encapsulation
attribute contains the Color Sub-TLV. In that case, packet P MUST attribute contains the Color Sub-TLV. In that case, packet P MUST
skipping to change at page 31, line 9 skipping to change at page 30, line 47
If the TLV specifying a tunnel contains a Prefix-SID sub-TLV, the If the TLV specifying a tunnel contains a Prefix-SID sub-TLV, the
procedures of Section 3.7 are applied before the procedures of this procedures of Section 3.7 are applied before the procedures of this
section. If the TLV also contains an MPLS Label Stack sub-TLV, the section. If the TLV also contains an MPLS Label Stack sub-TLV, the
procedures of Section 3.6 are applied before the procedures of procedures of Section 3.6 are applied before the procedures of
Section 3.7. Section 3.7.
9.1. Tunnel Types without a Virtual Network Identifier Field 9.1. Tunnel Types without a Virtual Network Identifier Field
If a Tunnel Encapsulation attribute is attached to an UPDATE of a If a Tunnel Encapsulation attribute is attached to an UPDATE of a
labeled address family, there will be one or more labels specified in labeled address family, there will be one or more labels specified in
the UPDATE's NLRI. the UPDATE's NLRI. When a packet is sent through a tunnel specified
in one of the attribute's TLVs, and that tunnel type does not contain
o If the TLV contains an Embedded Label Handling sub-TLV whose value a virtual network identifier field, the label or labels from the NLRI
is 1, the label or labels from the NLRI are pushed on the packet's are pushed on the packet's label stack. The resulting MPLS packet is
label stack. then further encapsulated, as specified by the TLV.
o If the TLV does not contain an Embedded Label Handling sub-TLV, or
if it contains an Embedded Label Handling sub-TLV whose value is
2, the embedded label is ignored completely. In this case the
tunnel encapsulation is presumed to provide complete information
regarding the forwarding context required.
The resulting MPLS packet is then further encapsulated, as specified
by the TLV.
9.2. Tunnel Types with a Virtual Network Identifier Field 9.2. Tunnel Types with a Virtual Network Identifier Field
Three of the tunnel types that can be specified in a Tunnel Three of the tunnel types that can be specified in a Tunnel
Encapsulation TLV have virtual network identifier fields in their Encapsulation TLV have virtual network identifier fields in their
encapsulation headers. In the VXLAN and VXLAN GPE encapsulations, encapsulation headers. In the VXLAN and VXLAN GPE encapsulations,
this field is called the VNI (Virtual Network Identifier) field; in this field is called the VNI (Virtual Network Identifier) field; in
the NVGRE encapsulation, this field is called the VSID (Virtual the NVGRE encapsulation, this field is called the VSID (Virtual
Subnet Identifier) field. Subnet Identifier) field.
skipping to change at page 34, line 31 skipping to change at page 34, line 15
granularities (for example, per route and/or per attribute TLV) MAY granularities (for example, per route and/or per attribute TLV) MAY
be supported. For each external BGP (EBGP) session, filtering of the be supported. For each external BGP (EBGP) session, filtering of the
attribute on incoming UPDATEs MUST be enabled by default. attribute on incoming UPDATEs MUST be enabled by default.
In addition, any BGP speaker that understands the attribute MUST be In addition, any BGP speaker that understands the attribute MUST be
able to filter the attribute from outgoing BGP UPDATE messages. This able to filter the attribute from outgoing BGP UPDATE messages. This
filtering SHOULD be possible on a per-BGP-session basis. For each filtering SHOULD be possible on a per-BGP-session basis. For each
EBGP session, filtering of the attribute on outgoing UPDATEs MUST be EBGP session, filtering of the attribute on outgoing UPDATEs MUST be
enabled by default. enabled by default.
Since the Tunnel Encapsulation Extended Community provides a subset
of the functionality of the Tunnel Encapsulation attribute, these
considerations apply equally in its case: any BGP speaker that
understands it MUST be able to filter it from incoming BGP UPDATE
messages, it MUST be possible to filter the Tunnel Encapsulation
Extended Community from outgoing messages, and in both cases this
filtering MUST be enabled by default for EBGP sessions.
12. Validation and Error Handling 12. Validation and Error Handling
The Tunnel Encapsulation attribute is a sequence of TLVs, each of The Tunnel Encapsulation attribute is a sequence of TLVs, each of
which is a sequence of sub-TLVs. The final octet of a TLV is which is a sequence of sub-TLVs. The final octet of a TLV is
determined by its length field. Similarly, the final octet of a sub- determined by its length field. Similarly, the final octet of a sub-
TLV is determined by its length field. The final octet of a TLV MUST TLV is determined by its length field. The final octet of a TLV MUST
also be the final octet of its final sub-TLV. If this is not the also be the final octet of its final sub-TLV. If this is not the
case, the TLV MUST be considered to be malformed, and the "Treat-as- case, the TLV MUST be considered to be malformed, and the "Treat-as-
withdraw" procedure of [RFC7606] is applied. withdraw" procedure of [RFC7606] is applied.
skipping to change at page 36, line 10 skipping to change at page 36, line 4
However, the sub-TLV MUST NOT be considered to be malformed, and MUST However, the sub-TLV MUST NOT be considered to be malformed, and MUST
NOT be removed from the TLV before the route carrying the Tunnel NOT be removed from the TLV before the route carrying the Tunnel
Encapsulation attribute is distributed. An implementation MAY log a Encapsulation attribute is distributed. An implementation MAY log a
message when it encounters such a sub-TLV. message when it encounters such a sub-TLV.
13. IANA Considerations 13. IANA Considerations
This document makes the following requests of IANA. (All This document makes the following requests of IANA. (All
registration procedures listed below are per their definitions in registration procedures listed below are per their definitions in
[RFC8126].) [RFC8126].)
Because this document obsoletes RFC 5512, change all registration
information that references [RFC5512] to instead reference this
document.
13.1. BGP Tunnel Encapsulation Parameters Grouping 13.1. Obsoleting Code Points Assigned by RFCs 5566 and 5640
Since this document obsoletes RFCs 5566 and 5640, the code points
assigned by those RFCs are similarly obsoleted. Specifically, the
following code points should be marked as deprecated.
In the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry:
+-------+---------------------------------------------+
| Value | Name |
+-------+---------------------------------------------+
| 3 | Transmit tunnel endpoint |
| 4 | IPsec in Tunnel-mode |
| 5 | IP in IP tunnel with IPsec Transport Mode |
| 6 | MPLS-in-IP tunnel with IPsec Transport Mode |
+-------+---------------------------------------------+
And in the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry:
+-------+----------------------------+
| Value | Name |
+-------+----------------------------+
| 3 | IPsec Tunnel Authenticator |
| 5 | Load-Balancing Block |
+-------+----------------------------+
13.2. BGP Tunnel Encapsulation Parameters Grouping
Create a new registry grouping, to be named "BGP Tunnel Encapsulation Create a new registry grouping, to be named "BGP Tunnel Encapsulation
Parameters". Parameters".
13.2. Subsequent Address Family Identifiers 13.3. Subsequent Address Family Identifiers
Modify the "Subsequent Address Family Identifiers" registry to Modify the "Subsequent Address Family Identifiers" registry to
indicate that the Encapsulation SAFI (value 7) is obsoleted. This indicate that the Encapsulation SAFI (value 7) is obsoleted. This
document should be the reference. document should be the reference.
Because this document obsoletes RFC 5512, change all registration 13.4. BGP Tunnel Encapsulation Attribute Sub-TLVs
information that references [RFC5512] to instead reference this
document.
13.3. BGP Tunnel Encapsulation Attribute Sub-TLVs
Relocate the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry Relocate the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry
to be under the "BGP Tunnel Encapsulation Parameters" grouping. to be under the "BGP Tunnel Encapsulation Parameters" grouping.
Add the following note to the registry: Add the following note to the registry:
If the Sub-TLV Type is in the range from 0 to 127 inclusive, the If the Sub-TLV Type is in the range from 0 to 127 inclusive, the
Sub-TLV Length field contains one octet. If the Sub-TLV Type is Sub-TLV Length field contains one octet. If the Sub-TLV Type is
in the range from 128-255 inclusive, the Sub-TLV Length field in the range from 128-255 inclusive, the Sub-TLV Length field
contains two octets. contains two octets.
skipping to change at page 37, line 14 skipping to change at page 37, line 34
Rename the following entries within the registry: Rename the following entries within the registry:
+-------+-----------------+------------------------+ +-------+-----------------+------------------------+
| Value | Old Name | New Name | | Value | Old Name | New Name |
+-------+-----------------+------------------------+ +-------+-----------------+------------------------+
| 6 | Remote Endpoint | Tunnel Egress Endpoint | | 6 | Remote Endpoint | Tunnel Egress Endpoint |
| 7 | IPv4 DS Field | DS Field | | 7 | IPv4 DS Field | DS Field |
+-------+-----------------+------------------------+ +-------+-----------------+------------------------+
13.4. Flags Field of VXLAN Encapsulation sub-TLV 13.5. Flags Field of VXLAN Encapsulation sub-TLV
Create a registry named "Flags Field of VXLAN Encapsulation sub-TLV" Create a registry named "Flags Field of VXLAN Encapsulation sub-TLV"
under the "BGP Tunnel Encapsulation Parameters" grouping. The under the "BGP Tunnel Encapsulation Parameters" grouping. The
registration policy for this registry is "Standards Action". registration policy for this registry is "Standards Action".
The initial values for this new registry are indicated below. The initial values for this new registry are indicated below.
+--------------+--------------------------------+-----------------+ +--------------+--------------------------------+-----------------+
| Bit Position | Description | Reference | | Bit Position | Description | Reference |
+--------------+--------------------------------+-----------------+ +--------------+--------------------------------+-----------------+
| 0 | V (Virtual Network Identifier) | (this document) | | 0 | V (Virtual Network Identifier) | (this document) |
| 1 | M (MAC Address) | (this document) | | 1 | M (MAC Address) | (this document) |
+--------------+--------------------------------+-----------------+ +--------------+--------------------------------+-----------------+
13.5. Flags Field of VXLAN GPE Encapsulation sub-TLV 13.6. Flags Field of VXLAN GPE Encapsulation sub-TLV
Create a registry named "Flags Field of VXLAN GPE Encapsulation sub- Create a registry named "Flags Field of VXLAN GPE Encapsulation sub-
TLV" under the "BGP Tunnel Encapsulation Parameters" grouping. The TLV" under the "BGP Tunnel Encapsulation Parameters" grouping. The
registration policy for this registry is "Standards Action". registration policy for this registry is "Standards Action".
The initial value for this new registry is indicated below. The initial value for this new registry is indicated below.
+--------------+-------------+-----------------+ +--------------+-------------+-----------------+
| Bit Position | Description | Reference | | Bit Position | Description | Reference |
+--------------+-------------+-----------------+ +--------------+-------------+-----------------+
| 0 | V (VN-ID) | (this document) | | 0 | V (VN-ID) | (this document) |
+--------------+-------------+-----------------+ +--------------+-------------+-----------------+
13.6. Flags Field of NVGRE Encapsulation sub-TLV 13.7. Flags Field of NVGRE Encapsulation sub-TLV
Create a registry named "Flags Field of NVGRE Encapsulation sub-TLV" Create a registry named "Flags Field of NVGRE Encapsulation sub-TLV"
under the "BGP Tunnel Encapsulation Parameters" grouping. The under the "BGP Tunnel Encapsulation Parameters" grouping. The
registration policy for this registry is "Standards Action". registration policy for this registry is "Standards Action".
The initial values for this new registry are indicated below. The initial values for this new registry are indicated below.
+--------------+-----------------+-----------------+ +--------------+-----------------+-----------------+
| Bit Position | Description | Reference | | Bit Position | Description | Reference |
+--------------+-----------------+-----------------+ +--------------+-----------------+-----------------+
| 0 | V (VN-ID) | (this document) | | 0 | V (VN-ID) | (this document) |
| 1 | M (MAC Address) | (this document) | | 1 | M (MAC Address) | (this document) |
+--------------+-----------------+-----------------+ +--------------+-----------------+-----------------+
13.7. Embedded Label Handling sub-TLV 13.8. Embedded Label Handling sub-TLV
Create a registry named "Embedded Label Handling sub-TLV" under the Create a registry named "Embedded Label Handling sub-TLV" under the
"BGP Tunnel Encapsulation Parameters" grouping. The registration "BGP Tunnel Encapsulation Parameters" grouping. The registration
policy for this registry is "Standards Action". policy for this registry is "Standards Action".
The initial values for this new registry are indicated below. The initial values for this new registry are indicated below.
+-------+-------------------------------------+-----------------+ +-------+-------------------------------------+-----------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-------------------------------------+-----------------+ +-------+-------------------------------------+-----------------+
| 1 | Payload of MPLS with embedded label | (this document) | | 1 | Payload of MPLS with embedded label | (this document) |
| 2 | no embedded label in payload | (this document) | | 2 | no embedded label in payload | (this document) |
+-------+-------------------------------------+-----------------+ +-------+-------------------------------------+-----------------+
13.8. Color Extended Community
Add this document as a reference for the "Color Extended Community"
entry in the Transitive Opaque Extended Community Sub-Types registry.
13.9. Color Extended Community Flags 13.9. Color Extended Community Flags
Create a registry named "Color Extended Community Flags" under the Create a registry named "Color Extended Community Flags" under the
"BGP Tunnel Encapsulation Parameters" grouping. The registration "BGP Tunnel Encapsulation Parameters" grouping. The registration
policy for this registry is "Standards Action". policy for this registry is "Standards Action".
No initial values are to be registered. The format of the registry No initial values are to be registered. The format of the registry
is shown below. is shown below.
+--------------+-------------+-----------+ +--------------+-------------+-----------+
skipping to change at page 40, line 28 skipping to change at page 41, line 4
Bloomberg LP Bloomberg LP
731 Lexington Ave 731 Lexington Ave
New York City, NY 10022 New York City, NY 10022
United States United States
Email: robert@raszuk.net Email: robert@raszuk.net
Eric C. Rosen Eric C. Rosen
17. References 17. References
17.1. Normative References 17.1. Normative References
[I-D.ietf-nvo3-vxlan-gpe] [I-D.ietf-nvo3-vxlan-gpe]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-09 (work Extension for VXLAN (VXLAN-GPE)", draft-ietf-nvo3-vxlan-
in progress), December 2019. gpe-10 (work in progress), July 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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,
skipping to change at page 41, line 44 skipping to change at page 42, line 19
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007, DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>. <https://www.rfc-editor.org/info/rfc4760>.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
2008, <https://www.rfc-editor.org/info/rfc5129>. 2008, <https://www.rfc-editor.org/info/rfc5129>.
[RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-
Balancing for Mesh Softwires", RFC 5640,
DOI 10.17487/RFC5640, August 2009,
<https://www.rfc-editor.org/info/rfc5640>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153, "Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013, RFC 6890, DOI 10.17487/RFC6890, April 2013,
<https://www.rfc-editor.org/info/rfc6890>. <https://www.rfc-editor.org/info/rfc6890>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
skipping to change at page 42, line 47 skipping to change at page 43, line 21
17.2. Informative References 17.2. Informative References
[Ethertypes] [Ethertypes]
"IANA Ethertype Registry", "IANA Ethertype Registry",
<http://www.iana.org/assignments/ieee-802-numbers/ieee- <http://www.iana.org/assignments/ieee-802-numbers/ieee-
802-numbers.xhtml>. 802-numbers.xhtml>.
[I-D.ietf-bess-evpn-inter-subnet-forwarding] [I-D.ietf-bess-evpn-inter-subnet-forwarding]
Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
Rabadan, "Integrated Routing and Bridging in EVPN", draft- Rabadan, "Integrated Routing and Bridging in EVPN", draft-
ietf-bess-evpn-inter-subnet-forwarding-09 (work in ietf-bess-evpn-inter-subnet-forwarding-10 (work in
progress), June 2020. progress), September 2020.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006, RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>. <https://www.rfc-editor.org/info/rfc4272>.
[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, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
skipping to change at page 43, line 28 skipping to change at page 44, line 5
<https://www.rfc-editor.org/info/rfc5512>. <https://www.rfc-editor.org/info/rfc5512>.
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009,
<https://www.rfc-editor.org/info/rfc5565>. <https://www.rfc-editor.org/info/rfc5565>.
[RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel [RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel
Encapsulation Attribute", RFC 5566, DOI 10.17487/RFC5566, Encapsulation Attribute", RFC 5566, DOI 10.17487/RFC5566,
June 2009, <https://www.rfc-editor.org/info/rfc5566>. June 2009, <https://www.rfc-editor.org/info/rfc5566>.
[RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-
Balancing for Mesh Softwires", RFC 5640,
DOI 10.17487/RFC5640, August 2009,
<https://www.rfc-editor.org/info/rfc5640>.
[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,
<https://www.rfc-editor.org/info/rfc6811>. <https://www.rfc-editor.org/info/rfc6811>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510, "Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015, DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/info/rfc7510>. <https://www.rfc-editor.org/info/rfc7510>.
 End of changes. 68 change blocks. 
189 lines changed or deleted 194 lines changed or added

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