draft-ietf-mpls-sr-over-ip-04.txt | draft-ietf-mpls-sr-over-ip-05.txt | |||
---|---|---|---|---|
Network Working Group X. Xu | Network Working Group X. Xu | |||
Internet-Draft Alibaba, Inc | Internet-Draft Alibaba, Inc | |||
Intended status: Standards Track S. Bryant | Intended status: Standards Track S. Bryant | |||
Expires: October 15, 2019 Huawei | Expires: November 11, 2019 Huawei | |||
A. Farrel | A. Farrel | |||
Old Dog Consulting | Old Dog Consulting | |||
S. Hassan | S. Hassan | |||
Cisco | Cisco | |||
W. Henderickx | W. Henderickx | |||
Nokia | Nokia | |||
Z. Li | Z. Li | |||
Huawei | Huawei | |||
April 13, 2019 | May 10, 2019 | |||
SR-MPLS over IP | SR-MPLS over IP | |||
draft-ietf-mpls-sr-over-ip-04 | draft-ietf-mpls-sr-over-ip-05 | |||
Abstract | Abstract | |||
MPLS Segment Routing (SR-MPLS) is an MPLS data plane-based source | MPLS Segment Routing (SR-MPLS) is an MPLS data plane-based source | |||
routing paradigm in which the sender of a packet is allowed to | routing paradigm in which the sender of a packet is allowed to | |||
partially or completely specify the route the packet takes through | partially or completely specify the route the packet takes through | |||
the network by imposing stacked MPLS labels on the packet. SR-MPLS | the network by imposing stacked MPLS labels on the packet. SR-MPLS | |||
can be leveraged to realize a source routing mechanism across MPLS, | can be leveraged to realize a source routing mechanism across MPLS, | |||
IPv4, and IPv6 data planes by using an MPLS label stack as a source | IPv4, and IPv6 data planes by using an MPLS label stack as a source | |||
routing instruction set while making no changes to SR-MPLS | routing instruction set while making no changes to SR-MPLS | |||
skipping to change at page 2, line 4 ¶ | skipping to change at page 2, line 4 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on October 15, 2019. | This Internet-Draft will expire on November 11, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 28 ¶ | skipping to change at page 2, line 28 ¶ | |||
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Procedures of SR-MPLS over IP . . . . . . . . . . . . . . . . 5 | 3. Procedures of SR-MPLS over IP . . . . . . . . . . . . . . . . 5 | |||
3.1. Forwarding Entry Construction . . . . . . . . . . . . . . 5 | 3.1. Forwarding Entry Construction . . . . . . . . . . . . . . 5 | |||
3.2. Packet Forwarding Procedures . . . . . . . . . . . . . . 7 | 3.1.1. FIB Construction Example . . . . . . . . . . . . . . 6 | |||
3.2. Packet Forwarding Procedures . . . . . . . . . . . . . . 8 | ||||
3.2.1. Packet Forwarding with Penultimate Hop Popping . . . 8 | 3.2.1. Packet Forwarding with Penultimate Hop Popping . . . 8 | |||
3.2.2. Packet Forwarding without Penultimate Hop Popping . . 9 | 3.2.2. Packet Forwarding without Penultimate Hop Popping . . 10 | |||
3.2.3. Additional Forwarding Procedures . . . . . . . . . . 10 | 3.2.3. Additional Forwarding Procedures . . . . . . . . . . 11 | |||
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | |||
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 | 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 14 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 15 | 8.2. Informative References . . . . . . . . . . . . . . . . . 16 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
1. Introduction | 1. Introduction | |||
MPLS Segment Routing (SR-MPLS) [I-D.ietf-spring-segment-routing-mpls] | MPLS Segment Routing (SR-MPLS) [I-D.ietf-spring-segment-routing-mpls] | |||
is an MPLS data plane-based source routing paradigm in which the | is an MPLS data plane-based source routing paradigm in which the | |||
sender of a packet is allowed to partially or completely specify the | sender of a packet is allowed to partially or completely specify the | |||
route the packet takes through the network by imposing stacked MPLS | route the packet takes through the network by imposing stacked MPLS | |||
labels on the packet. SR-MPLS uses an MPLS label stack to encode a | labels on the packet. SR-MPLS uses an MPLS label stack to encode a | |||
source routing instruction set. This can be used to realize a source | source routing instruction set. This can be used to realize a source | |||
routing mechanism that can operate across MPLS, IPv4, and IPv6 data | routing mechanism that can operate across MPLS, IPv4, and IPv6 data | |||
planes. This approach preserves makes no changes to SR-MPLS | planes. This approach makes no changes to SR-MPLS specifications and | |||
specifications and allows interworking with SR-MPLS implementations. | allows interworking with SR-MPLS implementations. More specifically, | |||
the source routing instruction set information contained in a source | ||||
More specifically, the source routing instruction set information | routed packet could be uniformly encoded as an MPLS label stack no | |||
contained in a source routed packet could be uniformly encoded as an | matter whether the underlay is IPv4, IPv6, or MPLS. | |||
MPLS label stack no matter whether the underlay is IPv4, IPv6, or | ||||
MPLS. | ||||
This document describes how SR-MPLS capable routers and IP-only | This document describes how SR-MPLS capable routers and IP-only | |||
routers can seamlessly co-exist and interoperate through the use of | routers can seamlessly co-exist and interoperate through the use of | |||
SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-in- | SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-in- | |||
UDP [RFC7510]. | UDP [RFC7510]. | |||
Section 2 describes various use cases for the tunneling SR-MPLS over | Section 2 describes various use cases for the tunneling SR-MPLS over | |||
IP. Section 3 describes a typical application scenario and how the | IP. Section 3 describes a typical application scenario and how the | |||
packet forwarding happens. | packet forwarding happens. | |||
skipping to change at page 3, line 33 ¶ | skipping to change at page 3, line 32 ¶ | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
2. Use Cases | 2. Use Cases | |||
Tunneling SR-MPLS using IPv4 and/or IPv6 tunnels is useful at least | Tunneling SR-MPLS using IPv4 and/or IPv6 tunnels is useful at least | |||
in the following use cases: | in the use cases listed below. In all cases, this can be enabled | |||
using an IP tunneling mechanism such as MPLS-in-UDP as described in | ||||
[RFC7510]. The tunnel selected MUST have its remote end point | ||||
(destination) address equal to the address of the next SR-MPLS | ||||
capable node identified as being on the SR path (i.e., the egress of | ||||
the active node segment). The local end point (source) address is | ||||
set to an address of the encapsulating node. [RFC7510] gives further | ||||
advice on how to set the source address if the UDP zero-checksum mode | ||||
is used with MPLS-in-UDP. | ||||
o Incremental deployment of the SR-MPLS technology may be | o Incremental deployment of the SR-MPLS technology may be | |||
facilitated by tunneling SR-MPLS packets across parts of a network | facilitated by tunneling SR-MPLS packets across parts of a network | |||
that are not SR-MPLS enabled using an IP tunneling mechanism such | that are not SR-MPLS as shown in Figure 1. This demonstrates how | |||
as MPLS-in-UDP [RFC7510]. The tunnel selected MUST have its | islands of SR-MPLS may be connected across a legacy network. It | |||
remote end point (destination) address equal to the address of the | may be particularly useful for joining sites (such as data | |||
next SR-MPLS capable node along the path (i.e., the egress of the | centers). | |||
active node segment). This is shown in Figure 1. | ||||
________________________ | ________________________ | |||
_______ ( ) _______ | _______ ( ) _______ | |||
( ) ( IP Network ) ( ) | ( ) ( IP Network ) ( ) | |||
( SR-MPLS ) ( ) ( SR-MPLS ) | ( SR-MPLS ) ( ) ( SR-MPLS ) | |||
( Network ) ( ) ( Network ) | ( Network ) ( ) ( Network ) | |||
( -------- -------- ) | ( -------- -------- ) | |||
( | Border | SR-in-UDP Tunnel | Border | ) | ( | Border | SR-in-UDP Tunnel | Border | ) | |||
( | Router |========================| Router | ) | ( | Router |========================| Router | ) | |||
( | R1 | | R2 | ) | ( | R1 | | R2 | ) | |||
skipping to change at page 4, line 32 ¶ | skipping to change at page 4, line 32 ¶ | |||
o If encoding of entropy ([RFC6790] is desired, IP tunneling | o If encoding of entropy ([RFC6790] is desired, IP tunneling | |||
mechanisms that allow encoding of entropy, such as MPLS-in-UDP | mechanisms that allow encoding of entropy, such as MPLS-in-UDP | |||
encapsulation [RFC7510] where the source port of the UDP header is | encapsulation [RFC7510] where the source port of the UDP header is | |||
used as an entropy field, may be used to maximize the utilization | used as an entropy field, may be used to maximize the utilization | |||
of ECMP and/or LAG, especially when it is difficult to make use of | of ECMP and/or LAG, especially when it is difficult to make use of | |||
the entropy label mechanism. This is to be contrasted with | the entropy label mechanism. This is to be contrasted with | |||
[RFC4023] where MPLS-in-IP does not provide for an entropy | [RFC4023] where MPLS-in-IP does not provide for an entropy | |||
mechanism. Refer to [I-D.ietf-mpls-spring-entropy-label]) for | mechanism. Refer to [I-D.ietf-mpls-spring-entropy-label]) for | |||
more discussion about using entropy labels in SR-MPLS. | more discussion about using entropy labels in SR-MPLS. | |||
o Tunneling MPLS into IP provides a technology that enables SR in an | o Tunneling MPLS over IP provides a technology that enables SR in an | |||
IPv4 and/or IPv6 network where the routers do not support SRv6 | IPv4 and/or IPv6 network where the routers do not support SRv6 | |||
capabilities [I-D.ietf-6man-segment-routing-header] and where MPLS | capabilities [I-D.ietf-6man-segment-routing-header] and where MPLS | |||
forwarding is not an option. This is shown in Figure 2. | forwarding is not an option. This is shown in Figure 2. | |||
__________________________________ | __________________________________ | |||
__( IP Network )__ | __( IP Network )__ | |||
__( )__ | __( )__ | |||
( -- -- -- ) | ( -- -- -- ) | |||
-------- -- -- |SR| -- |SR| -- |SR| -- -------- | -------- -- -- |SR| -- |SR| -- |SR| -- -------- | |||
| Ingress| |IR| |IR| | | |IR| | | |IR| | | |IR| | Egress | | | Ingress| |IR| |IR| | | |IR| | | |IR| | | |IR| | Egress | | |||
skipping to change at page 5, line 31 ¶ | skipping to change at page 5, line 31 ¶ | |||
== : SR-MPLS in UDP Tunnel | == : SR-MPLS in UDP Tunnel | |||
Figure 2: SR-MPLS Enabled Within an IP Network | Figure 2: SR-MPLS Enabled Within an IP Network | |||
3. Procedures of SR-MPLS over IP | 3. Procedures of SR-MPLS over IP | |||
This section describes the construction of forwarding information | This section describes the construction of forwarding information | |||
base (FIB) entries and the forwarding behavior that allow the | base (FIB) entries and the forwarding behavior that allow the | |||
deployment of SR-MPLS when some routers in the network are IP only | deployment of SR-MPLS when some routers in the network are IP only | |||
(i.e., do not support SR-MPLS). Note that the examples in | (i.e., do not support SR-MPLS). Note that the examples in | |||
Section 3.1 and Section 3.2 assume that OSPF or ISIS is enabled: in | Section 3.1.1 and Section 3.2 assume that OSPF or ISIS is enabled: in | |||
fact, other mechanisms of discovery and advertisement could be used | fact, other mechanisms of discovery and advertisement could be used | |||
including other routing protocols (such as BGP) or a central | including other routing protocols (such as BGP) or a central | |||
controller. | controller. | |||
3.1. Forwarding Entry Construction | 3.1. Forwarding Entry Construction | |||
This sub-section describes the how to construct the forwarding | This sub-section describes the how to construct the forwarding | |||
information base (FIB) entry on an SR-MPLS-capable router when some | information base (FIB) entry on an SR-MPLS-capable router when some | |||
or all of the next-hops along the shortest path towards a prefix | or all of the next-hops along the shortest path towards a prefix | |||
Segment Identifier (prefix-SID) are IP-only routers. | Segment Identifier (prefix-SID) are IP-only routers. Section 3.1.1 | |||
provides a concrete example of how the process applies when using | ||||
OSPF or ISIS. | ||||
Consider router A that receives a labeled packet with top label L(E) | Consider router A that receives a labeled packet with top label L(E) | |||
that corresponds to the prefix-SID SID(E) of prefix P(E) advertised | that corresponds to the prefix-SID SID(E) of prefix P(E) advertised | |||
by router E. Suppose the i-th next-hop router (termed NHi) along the | by router E. Suppose the i-th next-hop router (termed NHi) along the | |||
shortest path from router A toward SID(E) is not SR-MPLS capable | shortest path from router A toward SID(E) is not SR-MPLS capable | |||
while both routers A and E are SR-MPLS capable. The following | while both routers A and E are SR-MPLS capable. The following | |||
processing steps apply: | processing steps apply: | |||
o Router E is SR-MPLS capable, so it advertises a Segment Routing | o Router E is SR-MPLS capable, so it advertises a Segment Routing | |||
Global Block (SRGB) using the mechanisms described in | Global Block (SRGB). The SRGB is defined in [RFC8402]. There are | |||
[I-D.ietf-ospf-segment-routing-extensions] and | a number of ways that the advertisement can be achieved including | |||
[I-D.ietf-isis-segment-routing-extensions]. The SRGB is defined | IGPs, BGP, configuration/management protocols. For example, see | |||
in [RFC8402]. | [I-D.ietf-bess-datacenter-gateway]. | |||
o When Router E advertises the prefix-SID SID(E) of prefix P(E) it | o When Router E advertises the prefix-SID SID(E) of prefix P(E) it | |||
MUST also advertise the encapsulation endpoint and the tunnel type | MUST also advertise the encapsulation endpoint and the tunnel type | |||
of any tunnel used to reach E. It can do this using the | of any tunnel used to reach E. This information is flooded domain | |||
mechanisms described in [I-D.ietf-isis-encapsulation-cap] or | wide. | |||
[I-D.ietf-ospf-encapsulation-cap]. | ||||
o If A and E are in different IGP areas/levels, then: | o If A and E are in different IGP domains then the information MUST | |||
be flooded into both domains. How this is achieved depends on the | ||||
advertisement mechanism being used. The objective is that router | ||||
A knows the characteristics of router E that originated the | ||||
advertisement of SID(E). | ||||
o Router A programs the FIB entry for prefix P(E) corresponding to | ||||
the SID(E) according to whether a pop or swap action is advertised | ||||
for the prefix. The resulting action may be: | ||||
* pop the top label | ||||
* swap the top label to a value equal to SID(E) plus the lower | ||||
bound of the SRGB of E | ||||
Once constructed, the FIB can be used by a router to tell it how to | ||||
process packets. It encapsulates the packets according to the | ||||
appropriate encapsulation advertised for the segment and then it | ||||
sends the packets towards the next hop NHi. | ||||
3.1.1. FIB Construction Example | ||||
This section is non-normative and provides a worked example of how a | ||||
FIB might be constructed using OSPF and ISIS extensions. It is based | ||||
on the process described in Section 3.1. | ||||
o Router E is SR-MPLS capable, so it advertises a Segment Routing | ||||
Global Block (SRGB) using | ||||
[I-D.ietf-ospf-segment-routing-extensions] or | ||||
[I-D.ietf-isis-segment-routing-extensions]. | ||||
o When Router E advertises the prefix-SID SID(E) of prefix P(E) it | ||||
also advertises the encapsulation endpoint and the tunnel type of | ||||
any tunnel used to reach E using [I-D.ietf-isis-encapsulation-cap] | ||||
or [I-D.ietf-ospf-encapsulation-cap]. | ||||
o If A and E are in different domains then the information is | ||||
flooded into both domains and any intervening domains. | ||||
* The OSPF Tunnel Encapsulation TLV | * The OSPF Tunnel Encapsulation TLV | |||
[I-D.ietf-ospf-encapsulation-cap] or the ISIS Tunnel | [I-D.ietf-ospf-encapsulation-cap] or the ISIS Tunnel | |||
Encapsulation sub-TLV [I-D.ietf-isis-encapsulation-cap] is | Encapsulation sub-TLV [I-D.ietf-isis-encapsulation-cap] is | |||
flooded domain-wide. | flooded domain-wide. | |||
* The OSPF SID/label range TLV | * The OSPF SID/label range TLV | |||
[I-D.ietf-ospf-segment-routing-extensions] or the ISIS SR- | [I-D.ietf-ospf-segment-routing-extensions] or the ISIS SR- | |||
Capabilities Sub-TLV [I-D.ietf-isis-segment-routing-extensions] | Capabilities Sub-TLV [I-D.ietf-isis-segment-routing-extensions] | |||
is advertised domain-wide. This way router A knows the | is advertised domain-wide so that router A knows the | |||
characteristics of the router that originated the advertisement | characteristics of router E. | |||
of SID(E) (i.e., router E). | ||||
* When router E advertises the prefix P(E): | * When router E advertises the prefix P(E): | |||
+ If router E is running ISIS it uses the extended | + If router E is running ISIS it uses the extended | |||
reachability TLV (TLVs 135, 235, 236, 237) and associates | reachability TLV (TLVs 135, 235, 236, 237) and associates | |||
the IPv4/IPv6 or IPv4/IPv6 source router ID sub-TLV(s) | the IPv4/IPv6 or IPv4/IPv6 source router ID sub-TLV(s) | |||
[RFC7794]. | [RFC7794]. | |||
+ If router E is running OSPF it uses the OSPFv2 Extended | + If router E is running OSPF it uses the OSPFv2 Extended | |||
Prefix Opaque LSA [RFC7684] and sets the flooding scope to | Prefix Opaque LSA [RFC7684] and sets the flooding scope to | |||
AS-wide. | AS-wide. | |||
* If router E is running ISIS and advertises the ISIS capability | * If router E is running ISIS and advertises the ISIS capability | |||
TLV (TLV 242) [RFC7981], it MUST set the "router-ID" field to a | TLV (TLV 242) [RFC7981], it sets the "router-ID" field to a | |||
valid value or include an IPV6 TE router-ID sub-TLV (TLV 12), | valid value or includes an IPV6 TE router-ID sub-TLV (TLV 12), | |||
or do both. The "S" bit (flooding scope) of the ISIS | or does both. The "S" bit (flooding scope) of the ISIS | |||
capability TLV (TLV 242) MUST be set to "1" . | capability TLV (TLV 242) is set to "1" . | |||
o Router A programs the FIB entry for prefix P(E) corresponding to | o Router A programs the FIB entry for prefix P(E) corresponding to | |||
the SID(E) as follows: | the SID(E) according to whether a pop or swap action is advertised | |||
for the prefix as follows: | ||||
* If the NP flag in OSPF or the P flag in ISIS is clear: | * If the NP flag in OSPF or the P flag in ISIS is clear: | |||
pop the top label | pop the top label | |||
* If the NP flag in OSPF or the P flag in ISIS is set: | * If the NP flag in OSPF or the P flag in ISIS is set: | |||
swap the top label to a value equal to SID(E) plus the lower | swap the top label to a value equal to SID(E) plus the lower | |||
bound of the SRGB of E | bound of the SRGB of E | |||
Once constructed, the FIB can be used by a router to tell it how to | When forwarding the packet according to the constructed FIB entry the | |||
process packets. It encapsulates the packets according to the | router encapsulates the packet according to the encapsulation as | |||
appropriate encapsulation (for example, as advertised using the | advertised using the mechanisms described in | |||
mechanisms described in [I-D.ietf-isis-encapsulation-cap] or | [I-D.ietf-isis-encapsulation-cap] or | |||
[I-D.ietf-ospf-encapsulation-cap]. Then it sends the packets towards | ||||
the next hop NHi. | [I-D.ietf-ospf-encapsulation-cap]). It then sends the packets | |||
towards the next hop NHi. | ||||
3.2. Packet Forwarding Procedures | 3.2. Packet Forwarding Procedures | |||
[RFC7510] specifies an IP-based encapsulation for MPLS, i.e., MPLS- | [RFC7510] specifies an IP-based encapsulation for MPLS, i.e., MPLS- | |||
in-UDP. This approach is applicable where IP-based encapsulation for | in-UDP. This approach is applicable where IP-based encapsulation for | |||
MPLS is required and further fine-grained load balancing of MPLS | MPLS is required and further fine-grained load balancing of MPLS | |||
packets over IP networks over Equal-Cost Multipath (ECMP) and/or Link | packets over IP networks over Equal-Cost Multipath (ECMP) and/or Link | |||
Aggregation Groups (LAGs) is also required. This section provides | Aggregation Groups (LAGs) is also required. This section provides | |||
details about the forwarding procedure when UDP encapsulation is | details about the forwarding procedure when UDP encapsulation is | |||
adopted for SR-MPLS over IP. Other encapsulation and tunnelling | adopted for SR-MPLS over IP. Other encapsulation and tunnelling | |||
skipping to change at page 8, line 14 ¶ | skipping to change at page 8, line 50 ¶ | |||
o The penultimate SR-MPLS capable node on the path that processes | o The penultimate SR-MPLS capable node on the path that processes | |||
the last SID on the stack on behalf of the domain egress node. | the last SID on the stack on behalf of the domain egress node. | |||
o The domain egress node that forwards the payload packet for | o The domain egress node that forwards the payload packet for | |||
ultimate delivery. | ultimate delivery. | |||
3.2.1. Packet Forwarding with Penultimate Hop Popping | 3.2.1. Packet Forwarding with Penultimate Hop Popping | |||
The description in this section assumes that the label associated | The description in this section assumes that the label associated | |||
with each prefix-SID is advertised by the owner of the prefix-SID is | with each prefix-SID is advertised by the owner of the prefix-SID as | |||
a Penultimate Hop Popping (PHP) label. That is, the NP flag in OSPF | a Penultimate Hop Popping (PHP) label. That is, if one of the IGP | |||
or the P flag in ISIS associated with the prefix SID is not set. | flooding mechanisms is used, the NP flag in OSPF or the P flag in | |||
ISIS associated with the prefix-SID is not set. | ||||
+-----+ +-----+ +-----+ +-----+ +-----+ | +-----+ +-----+ +-----+ +-----+ +-----+ | |||
| A +-------+ B +-------+ C +-------+ D +-------+ H | | | A +-------+ B +-------+ C +-------+ D +-------+ H | | |||
+-----+ +--+--+ +--+--+ +--+--+ +-----+ | +-----+ +--+--+ +--+--+ +--+--+ +-----+ | |||
| | | | | | | | |||
| | | | | | | | |||
+--+--+ +--+--+ +--+--+ | +--+--+ +--+--+ +--+--+ | |||
| E +-------+ F +-------+ G | | | E +-------+ F +-------+ G | | |||
+-----+ +-----+ +-----+ | +-----+ +-----+ +-----+ | |||
skipping to change at page 9, line 49 ¶ | skipping to change at page 10, line 33 ¶ | |||
SR-MPLS label, it inserts an explicit null label [RFC3032] before | SR-MPLS label, it inserts an explicit null label [RFC3032] before | |||
encapsulating the packet in an MPLS-over-UDP tunnel toward router H | encapsulating the packet in an MPLS-over-UDP tunnel toward router H | |||
and sending it out. That is, router G pops the top label, discovers | and sending it out. That is, router G pops the top label, discovers | |||
it has reached the bottom of stack, pushes an explicit null label, | it has reached the bottom of stack, pushes an explicit null label, | |||
and then encapsulates the MPLS packet in a UDP tunnel to router H. | and then encapsulates the MPLS packet in a UDP tunnel to router H. | |||
3.2.2. Packet Forwarding without Penultimate Hop Popping | 3.2.2. Packet Forwarding without Penultimate Hop Popping | |||
Figure 4 demonstrates the packet walk in the case where the label | Figure 4 demonstrates the packet walk in the case where the label | |||
associated with each prefix-SID advertised by the owner of the | associated with each prefix-SID advertised by the owner of the | |||
prefix-SID is not a Penultimate Hop Popping (PHP) label (i.e., the | prefix-SID is not a Penultimate Hop Popping (PHP) label (e.g., the | |||
the NP flag in OSPF or the P flag in ISIS associated with the prefix | the NP flag in OSPF or the P flag in ISIS associated with the prefix- | |||
SID is set). Apart from the PHP function the roles of the routers is | SID is set). Apart from the PHP function the roles of the routers is | |||
unchanged from Section 3.2.1. | unchanged from Section 3.2.1. | |||
+-----+ +-----+ +-----+ +-----+ +-----+ | +-----+ +-----+ +-----+ +-----+ +-----+ | |||
| A +-------+ B +-------+ C +--------+ D +--------+ H | | | A +-------+ B +-------+ C +--------+ D +--------+ H | | |||
+-----+ +--+--+ +--+--+ +--+--+ +-----+ | +-----+ +--+--+ +--+--+ +--+--+ +-----+ | |||
| | | | | | | | |||
| | | | | | | | |||
+--+--+ +--+--+ +--+--+ | +--+--+ +--+--+ +--+--+ | |||
| E +-------+ F +--------+ G | | | E +-------+ F +--------+ G | | |||
skipping to change at page 12, line 17 ¶ | skipping to change at page 13, line 15 ¶ | |||
4. IANA Considerations | 4. IANA Considerations | |||
This document makes no requests for IANA action. | This document makes no requests for IANA action. | |||
5. Security Considerations | 5. Security Considerations | |||
The security consideration of [RFC8354] (which redirects the reader | The security consideration of [RFC8354] (which redirects the reader | |||
to [RFC5095]) and [RFC7510] apply. DTLS [RFC6347] SHOULD be used | to [RFC5095]) and [RFC7510] apply. DTLS [RFC6347] SHOULD be used | |||
where security is needed on an MPLS-SR-over-UDP segment including | where security is needed on an MPLS-SR-over-UDP segment including | |||
when the IP segment crosses the public Internet or some other | when the IP segment crosses the public Internet or some other | |||
untrusted environment. | untrusted environment. [RFC8402] provides security considerations | |||
for Segment Routing, and Section 8.1 of that document is particularly | ||||
applicable to SR-MPLS. | ||||
It is difficult for an attacker to pass a raw MPLS encoded packet | It is difficult for an attacker to pass a raw MPLS encoded packet | |||
into a network and operators have considerable experience at | into a network and operators have considerable experience at | |||
excluding such packets at the network boundaries, for example by | excluding such packets at the network boundaries, for example by | |||
excluding all MPLS packets that are revealed as payload of IP | excluding all packets that are revealed to be carrying an MPLS packet | |||
tunnels. Further discussion of MPLS security is found in [RFC5920]. | as the payload of IP tunnels. Further discussion of MPLS security is | |||
found in [RFC5920]. | ||||
It is easy for a network ingress node to detect any attempt to | It is easy for a network ingress node to detect any attempt to | |||
smuggle an IP packet into the network since it would see that the UDP | smuggle an IP packet into the network since it would see that the UDP | |||
destination port was set to MPLS, and such filtering SHOULD be | destination port was set to MPLS, and such filtering SHOULD be | |||
applied. SR packets not having a destination address terminating in | applied. SR packets not having a destination address terminating in | |||
the network would be transparently carried and would pose no | the network would be transparently carried and would pose no | |||
different security risk to the network under consideration than any | different security risk to the network under consideration than any | |||
other traffic. | other traffic. | |||
Where control plane techniques are used (as described in Section 3), | Where control plane techniques are used (as described in Section 3), | |||
skipping to change at page 13, line 5 ¶ | skipping to change at page 14, line 5 ¶ | |||
Email: abashandy.ietf@gmail.com | Email: abashandy.ietf@gmail.com | |||
Clarence Filsfils | Clarence Filsfils | |||
Cisco | Cisco | |||
Email: cfilsfil@cisco.com | Email: cfilsfil@cisco.com | |||
John Drake | John Drake | |||
Juniper | Juniper | |||
Email: jdrake@juniper.net | Email: jdrake@juniper.net | |||
Shaowen Ma | Shaowen Ma | |||
Juniper | Mellanox Technologies | |||
Email: mashao@juniper.net | Email: mashaowen@gmail.com | |||
Mach Chen | Mach Chen | |||
Huawei | Huawei | |||
Email: mach.chen@huawei.com | Email: mach.chen@huawei.com | |||
Hamid Assarpour | Hamid Assarpour | |||
Broadcom | Broadcom | |||
Email:hamid.assarpour@broadcom.com | Email:hamid.assarpour@broadcom.com | |||
Robert Raszuk | Robert Raszuk | |||
skipping to change at page 14, line 16 ¶ | skipping to change at page 15, line 16 ¶ | |||
Dawkins, Benjamin Kaduk, and Martin Vigoureux for careful reviews and | Dawkins, Benjamin Kaduk, and Martin Vigoureux for careful reviews and | |||
resulting comments. | resulting comments. | |||
8. References | 8. References | |||
8.1. Normative References | 8.1. Normative References | |||
[I-D.ietf-spring-segment-routing-mpls] | [I-D.ietf-spring-segment-routing-mpls] | |||
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., | Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., | |||
Litkowski, S., and R. Shakir, "Segment Routing with MPLS | Litkowski, S., and R. Shakir, "Segment Routing with MPLS | |||
data plane", draft-ietf-spring-segment-routing-mpls-19 | data plane", draft-ietf-spring-segment-routing-mpls-22 | |||
(work in progress), March 2019. | (work in progress), May 2019. | |||
[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>. | |||
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | |||
Label Switching Architecture", RFC 3031, | Label Switching Architecture", RFC 3031, | |||
DOI 10.17487/RFC3031, January 2001, | DOI 10.17487/RFC3031, January 2001, | |||
<https://www.rfc-editor.org/info/rfc3031>. | <https://www.rfc-editor.org/info/rfc3031>. | |||
skipping to change at page 15, line 37 ¶ | skipping to change at page 16, line 37 ¶ | |||
July 2018, <https://www.rfc-editor.org/info/rfc8402>. | July 2018, <https://www.rfc-editor.org/info/rfc8402>. | |||
8.2. Informative References | 8.2. Informative References | |||
[I-D.ietf-6man-segment-routing-header] | [I-D.ietf-6man-segment-routing-header] | |||
Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and | Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and | |||
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header | d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header | |||
(SRH)", draft-ietf-6man-segment-routing-header-18 (work in | (SRH)", draft-ietf-6man-segment-routing-header-18 (work in | |||
progress), April 2019. | progress), April 2019. | |||
[I-D.ietf-bess-datacenter-gateway] | ||||
Farrel, A., Drake, J., Rosen, E., Patel, K., and L. Jalil, | ||||
"Gateway Auto-Discovery and Route Advertisement for | ||||
Segment Routing Enabled Domain Interconnection", draft- | ||||
ietf-bess-datacenter-gateway-02 (work in progress), | ||||
February 2019. | ||||
[I-D.ietf-isis-encapsulation-cap] | [I-D.ietf-isis-encapsulation-cap] | |||
Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras, | Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras, | |||
L., and L. Jalil, "Advertising Tunnelling Capability in | L., and L. Jalil, "Advertising Tunnelling Capability in | |||
IS-IS", draft-ietf-isis-encapsulation-cap-01 (work in | IS-IS", draft-ietf-isis-encapsulation-cap-01 (work in | |||
progress), April 2017. | progress), April 2017. | |||
[I-D.ietf-isis-segment-routing-extensions] | [I-D.ietf-isis-segment-routing-extensions] | |||
Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., | Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., | |||
Gredler, H., and B. Decraene, "IS-IS Extensions for | Gredler, H., and B. Decraene, "IS-IS Extensions for | |||
Segment Routing", draft-ietf-isis-segment-routing- | Segment Routing", draft-ietf-isis-segment-routing- | |||
extensions-23 (work in progress), March 2019. | extensions-24 (work in progress), April 2019. | |||
[I-D.ietf-mpls-spring-entropy-label] | [I-D.ietf-mpls-spring-entropy-label] | |||
Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., | Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., | |||
Shakir, R., and J. Tantsura, "Entropy label for SPRING | Shakir, R., and J. Tantsura, "Entropy label for SPRING | |||
tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in | tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in | |||
progress), July 2018. | progress), July 2018. | |||
[I-D.ietf-ospf-encapsulation-cap] | [I-D.ietf-ospf-encapsulation-cap] | |||
Xu, X., Decraene, B., Raszuk, R., Contreras, L., and L. | Xu, X., Decraene, B., Raszuk, R., Contreras, L., and L. | |||
Jalil, "The Tunnel Encapsulations OSPF Router | Jalil, "The Tunnel Encapsulations OSPF Router | |||
skipping to change at page 16, line 42 ¶ | skipping to change at page 18, line 6 ¶ | |||
RFC 6790, DOI 10.17487/RFC6790, November 2012, | RFC 6790, DOI 10.17487/RFC6790, November 2012, | |||
<https://www.rfc-editor.org/info/rfc6790>. | <https://www.rfc-editor.org/info/rfc6790>. | |||
[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and | [RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and | |||
Authentication for Routing Protocols (KARP) Overview, | Authentication for Routing Protocols (KARP) Overview, | |||
Threats, and Requirements", RFC 6862, | Threats, and Requirements", RFC 6862, | |||
DOI 10.17487/RFC6862, March 2013, | DOI 10.17487/RFC6862, March 2013, | |||
<https://www.rfc-editor.org/info/rfc6862>. | <https://www.rfc-editor.org/info/rfc6862>. | |||
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage | [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage | |||
Guidelines", RFC 8085, DOI 10.17487/RFC8085, March 2017, | Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, | |||
<https://www.rfc-editor.org/info/rfc8085>. | March 2017, <https://www.rfc-editor.org/info/rfc8085>. | |||
[RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., | [RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., | |||
Ed., and M. Townsley, "Use Cases for IPv6 Source Packet | Ed., and M. Townsley, "Use Cases for IPv6 Source Packet | |||
Routing in Networking (SPRING)", RFC 8354, | Routing in Networking (SPRING)", RFC 8354, | |||
DOI 10.17487/RFC8354, March 2018, | DOI 10.17487/RFC8354, March 2018, | |||
<https://www.rfc-editor.org/info/rfc8354>. | <https://www.rfc-editor.org/info/rfc8354>. | |||
Authors' Addresses | Authors' Addresses | |||
Xiaohu Xu | Xiaohu Xu | |||
End of changes. 28 change blocks. | ||||
68 lines changed or deleted | 124 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |