draft-ietf-mpls-sr-over-ip-00.txt | draft-ietf-mpls-sr-over-ip-01.txt | |||
---|---|---|---|---|
Network Working Group X. Xu | Network Working Group X. Xu | |||
Internet-Draft Alibaba | Internet-Draft Alibaba Inc. | |||
Intended status: Standards Track S. Bryant | Intended status: Standards Track S. Bryant | |||
Expires: February 2, 2019 Huawei | Expires: April 21, 2019 Huawei | |||
A. Farrel | A. Farrel | |||
Juniper | Old Dog Consulting | |||
S. Hassan | S. Hassan | |||
Cisco | Cisco | |||
W. Henderickx | W. Henderickx | |||
Nokia | Nokia | |||
Z. Li | Z. Li | |||
Huawei | Huawei | |||
August 01, 2018 | October 18, 2018 | |||
SR-MPLS over IP | SR-MPLS over IP | |||
draft-ietf-mpls-sr-over-ip-00 | draft-ietf-mpls-sr-over-ip-01 | |||
Abstract | Abstract | |||
MPLS Segment Routing (SR-MPLS in short) is an MPLS data plane-based | MPLS Segment Routing (SR-MPLS) is an MPLS data plane-based source | |||
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 | |||
could be leveraged to realize a source routing mechanism across MPLS, | could 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 preserving backward compatibility with | routing instruction set while preserving backward compatibility with | |||
SR-MPLS. | SR-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- | |||
skipping to change at page 2, line 4 ¶ | skipping to change at page 2, line 4 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on February 2, 2019. | This Internet-Draft will expire on April 21, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
4. Procedures of SR-MPLS over IP . . . . . . . . . . . . . . . . 5 | 3. Procedures of SR-MPLS over IP . . . . . . . . . . . . . . . . 5 | |||
4.1. Forwarding Entry Construction . . . . . . . . . . . . . . 5 | 3.1. Forwarding Entry Construction . . . . . . . . . . . . . . 5 | |||
4.2. Packet Forwarding Procedures . . . . . . . . . . . . . . 7 | 3.2. Packet Forwarding Procedures . . . . . . . . . . . . . . 7 | |||
4.2.1. Packet Forwarding with Penultimate Hop Popping . . . 8 | 3.2.1. Packet Forwarding with Penultimate Hop Popping . . . 8 | |||
4.2.2. Packet Forwarding without Penultimate Hop Popping . . 9 | 3.2.2. Packet Forwarding without Penultimate Hop Popping . . 9 | |||
4.2.3. Additional Forwarding Procedures . . . . . . . . . . 10 | 3.2.3. Additional Forwarding Procedures . . . . . . . . . . 10 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 | 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 15 | 8.2. Informative References . . . . . . . . . . . . . . . . . 14 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
1. Introduction | 1. Introduction | |||
MPLS Segment Routing (SR-MPLS in short) | MPLS Segment Routing (SR-MPLS) [I-D.ietf-spring-segment-routing-mpls] | |||
[I-D.ietf-spring-segment-routing-mpls] is an MPLS data plane-based | is an MPLS data plane-based source routing paradigm in which the | |||
source routing paradigm in which the sender of a packet is allowed to | sender of a packet is allowed to partially or completely specify the | |||
partially or completely specify the route the packet takes through | route the packet takes through the network by imposing stacked MPLS | |||
the network by imposing stacked MPLS labels on the packet. SR-MPLS | labels on the packet. SR-MPLS could be leveraged to realize a source | |||
could be leveraged to realize a source routing mechanism across MPLS, | routing mechanism across MPLS, IPv4, and IPv6 data planes by using an | |||
IPv4, and IPv6 data planes by using an MPLS label stack as a source | MPLS label stack as a source routing instruction set while preserving | |||
routing instruction set while preserving backward compatibility with | backward compatibility with SR-MPLS. More specifically, the source | |||
SR-MPLS. More specifically, the source routing instruction set | routing instruction set information contained in a source routed | |||
information contained in a source routed packet could be uniformly | packet could be uniformly encoded as an MPLS label stack no matter | |||
encoded as an MPLS label stack no matter whether the underlay is | whether the underlay is IPv4, IPv6, or MPLS. | |||
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]. | |||
Although the source routing instructions are encoded as MPLS labels, | Section 2 describes various use cases for the tunneling SR-MPLS over | |||
this is a hardware convenience rather than an indication that the | IP. Section 3 describes a typical application scenario and how the | |||
whole MPLS protocol stack needs to be deployed. In particular, the | ||||
MPLS control protocols are not used in this or any other form of SR- | ||||
MPLS. | ||||
Section 3 describes various use cases for the tunneling SR-MPLS over | ||||
IP. Section 4 describes a typical application scenario and how the | ||||
packet forwarding happens. | packet forwarding happens. | |||
2. Terminology | 1.1. Terminology | |||
This memo makes use of the terms defined in [RFC3031] and | This memo makes use of the terms defined in [RFC3031] and | |||
[I-D.ietf-spring-segment-routing-mpls]. | [I-D.ietf-spring-segment-routing-mpls]. | |||
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. | |||
3. 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 following use cases: | |||
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 enabled using an IP tunneling mechanism such | |||
as MPLS-in-UDP [RFC7510]. The tunnel destination address is the | as MPLS-in-UDP [RFC7510]. The tunnel destination address is the | |||
address of the next SR-MPLS-capable node along the path (i.e., the | address of the next SR-MPLS capable node along the path (i.e., the | |||
egress of the active node segment). This is shown in Figure 1. | egress of the 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 | ) | |||
skipping to change at page 4, line 26 ¶ | skipping to change at page 4, line 26 ¶ | |||
( ) ( ) ( ) | ( ) ( ) ( ) | |||
(_______) ( ) (_______) | (_______) ( ) (_______) | |||
(________________________) | (________________________) | |||
Figure 1: SR-MPLS in UDP to Tunnel Between SR-MPLS Sites | Figure 1: SR-MPLS in UDP to Tunnel Between SR-MPLS Sites | |||
o If encoding of entropy is desired, IP tunneling mechanisms that | o If encoding of entropy is desired, IP tunneling mechanisms that | |||
allow encoding of entropy, such as MPLS-in-UDP encapsulation | allow encoding of entropy, such as MPLS-in-UDP encapsulation | |||
[RFC7510] where the source port of the UDP header is used as an | [RFC7510] where the source port of the UDP header is used as an | |||
entropy field, may be used to maximize the utilization of ECMP | entropy field, may be used to maximize the utilization of ECMP | |||
and/or UCMP, specially when it is difficult to make use of entropy | and/or LAG, especially when it is difficult to make use of entropy | |||
label mechanism. Refer to [I-D.ietf-mpls-spring-entropy-label]) | label mechanism. Refer to [I-D.ietf-mpls-spring-entropy-label]) | |||
for more discussion about using entropy label in SR-MPLS. | for more discussion about using entropy label in SR-MPLS. | |||
o Tunneling MPLS into IP provides a technology that enables SR in an | o Tunneling MPLS into 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 Figure 2. | forwarding is not an option. This is shown in Figure Figure 2. | |||
__________________________________ | __________________________________ | |||
__( IP Network )__ | __( IP Network )__ | |||
skipping to change at page 5, line 25 ¶ | skipping to change at page 5, line 25 ¶ | |||
(__ __) | (__ __) | |||
(__________________________________) | (__________________________________) | |||
Key: | Key: | |||
IR : IP-only Router | IR : IP-only Router | |||
SR : SR-MPLS-capable Router | SR : SR-MPLS-capable Router | |||
== : 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 | |||
4. 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 described in | (i.e., do not support SR-MPLS). Note that the examples in | |||
Section 4.1 and Section 4.2 assume that OSPF or ISIS is enabled: in | Section 3.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. | |||
4.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-SID | or all of the next-hops along the shortest path towards a prefix | |||
are IP-only routers. | Segment Identifier (prefix-SID) are IP-only routers. | |||
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 ith 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 the SR-Capabilities | o Router E is SR-MPLS capable so it advertises the SRGB as described | |||
sub-TLV including the SRGB as described in | in [I-D.ietf-ospf-segment-routing-extensions] and | |||
[I-D.ietf-ospf-segment-routing-extensions] and | ||||
[I-D.ietf-isis-segment-routing-extensions]. | [I-D.ietf-isis-segment-routing-extensions]. | |||
o Router E advertises the prefix-SID SID(E) of prefix P(E) so MUST | o When Router E advertises the prefix-SID SID(E) of prefix P(E) it | |||
also advertise the encapsulation endpoint and the tunnel type of | MUST also advertise the encapsulation endpoint and the tunnel type | |||
any tunnel used to reach E. It does this using the mechanisms | of any tunnel used to reach E. It does this using the mechanisms | |||
described in [I-D.ietf-isis-encapsulation-cap] or | described in [I-D.ietf-isis-encapsulation-cap] or | |||
[I-D.ietf-ospf-encapsulation-cap]. | [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 areas/levels, then: | |||
* 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. | |||
skipping to change at page 7, line 16 ¶ | skipping to change at page 7, line 16 ¶ | |||
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 | |||
* Encapsulate the packet according to the encapsulation | * Encapsulate the packet according to the encapsulation | |||
advertised in [I-D.ietf-isis-encapsulation-cap] or | advertised in [I-D.ietf-isis-encapsulation-cap] or | |||
[I-D.ietf-ospf-encapsulation-cap] | [I-D.ietf-ospf-encapsulation-cap] | |||
* Send the packet towards the next hop NHi. | * Send the packet towards the next hop NHi. | |||
4.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, which is applicable in some circumstances where IP-based | in-UDP, which is applicable in some circumstances where IP-based | |||
encapsulation for MPLS is required and further fine-grained load | encapsulation for MPLS is required and further fine-grained load | |||
balancing of MPLS packets over IP networks over Equal-Cost Multipath | balancing of MPLS packets over IP networks over Equal-Cost Multipath | |||
(ECMP) and/or Link Aggregation Groups (LAGs) is required as well. | (ECMP) and/or Link Aggregation Groups (LAGs) is required as well. | |||
This section provides details about the forwarding procedure when | This section provides details about the forwarding procedure when | |||
when UDP encapsulation is adopted for SR-MPLS over IP. | when UDP encapsulation is adopted for SR-MPLS over IP. | |||
Nodes that are SR-MPLS capable can process SR-MPLS packets. Not all | Nodes that are SR-MPLS capable can process SR-MPLS packets. Not all | |||
of the nodes in an SR-MPLS domain are SR-MPLS capable. Some nodes | of the nodes in an SR-MPLS domain are SR-MPLS capable. Some nodes | |||
may be "legacy routers" that cannot handle SR-MPLS packets but can | may be "legacy routers" that cannot handle SR-MPLS packets but can | |||
forward IP packets. An SR-MPLS-capable node may advertise its | forward IP packets. An SR-MPLS-capable node may advertise its | |||
capabilities using the IGP as described in Section 4. There are six | capabilities using the IGP as described in Section 3. There are six | |||
types of node in an SR-MPLS domain: | types of node in an SR-MPLS domain: | |||
o Domain ingress nodes that receive packets and encapsulate them for | o Domain ingress nodes that receive packets and encapsulate them for | |||
transmission across the domain. Those packets may be any payload | transmission across the domain. Those packets may be any payload | |||
protocol including native IP packets or packets that are already | protocol including native IP packets or packets that are already | |||
MPLS encapsulated. | MPLS encapsulated. | |||
o Legacy transit nodes that are IP routers but that are not SR-MPLS | o Legacy transit nodes that are IP routers but that are not SR-MPLS | |||
capable (i.e., are not able to perform segment routing). | capable (i.e., are not able to perform segment routing). | |||
skipping to change at page 8, line 5 ¶ | skipping to change at page 8, line 5 ¶ | |||
o Transit nodes that are SR-MPLS capable and need to perform SR-MPLS | o Transit nodes that are SR-MPLS capable and need to perform SR-MPLS | |||
routing because they are identified by a SID in the SID stack. | routing because they are identified by a SID in the SID stack. | |||
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. | |||
4.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 is | |||
a Penultimate Hop Popping (PHP) label. That is, the NP flag in OSPF | a Penultimate Hop Popping (PHP) label. That is, the NP flag in OSPF | |||
or the P flag in ISIS associated with the prefix SID is not set. | or the P flag in ISIS associated with the prefix SID is not set. | |||
+-----+ +-----+ +-----+ +-----+ +-----+ | +-----+ +-----+ +-----+ +-----+ +-----+ | |||
| A +-------+ B +-------+ C +--------+ D +--------+ H | | | A +-------+ B +-------+ C +--------+ D +--------+ H | | |||
+-----+ +--+--+ +--+--+ +--+--+ +-----+ | +-----+ +--+--+ +--+--+ +--+--+ +-----+ | |||
| | | | | | | | |||
skipping to change at page 9, line 37 ¶ | skipping to change at page 9, line 37 ¶ | |||
protocol. That is, the final SR-MPLS has been popped exposing the | protocol. That is, the final SR-MPLS has been popped exposing the | |||
payload packet. | payload packet. | |||
To handle this, when a router (here it is router G) pops the final | To handle this, when a router (here it is router G) pops the final | |||
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. | |||
4.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 (i.e., 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 4.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 10, line 34 ¶ | skipping to change at page 10, line 34 ¶ | |||
+--------+ +--------+ +--------+ | +--------+ +--------+ +--------+ | |||
| Packet | ---> | Packet | ---> | Packet | | | Packet | ---> | Packet | ---> | Packet | | |||
+--------+ +--------+ +--------+ | +--------+ +--------+ +--------+ | |||
Figure 4: Packet Forwarding Example without PHP | Figure 4: Packet Forwarding Example without PHP | |||
As can be seen from the figure, the SR-MPLS label for each segment is | As can be seen from the figure, the SR-MPLS label for each segment is | |||
left in place until the end of the segment where it is popped and the | left in place until the end of the segment where it is popped and the | |||
next instruction is processed. | next instruction is processed. | |||
4.2.3. Additional Forwarding Procedures | 3.2.3. Additional Forwarding Procedures | |||
Non-MPLS Interfaces: Although the description in the previous two | Non-MPLS Interfaces: Although the description in the previous two | |||
sections is based on the use of prefix-SIDs, tunneling SR-MPLS | sections is based on the use of prefix-SIDs, tunneling SR-MPLS | |||
packets is useful when the top label of a received SR-MPLS packet | packets is useful when the top label of a received SR-MPLS packet | |||
indicates an adjacency-SID and the corresponding adjacent node to | indicates an adjacency-SID and the corresponding adjacent node to | |||
that adjacency-SID is not capable of MPLS forwarding but can still | that adjacency-SID is not capable of MPLS forwarding but can still | |||
process SR-MPLS packets. In this scenario the top label would be | process SR-MPLS packets. In this scenario the top label would be | |||
replaced by an IP tunnel toward that adjacent node and then | replaced by an IP tunnel toward that adjacent node and then | |||
forwarded over the corresponding link indicated by the adjacency- | forwarded over the corresponding link indicated by the adjacency- | |||
SID. | SID. | |||
skipping to change at page 11, line 16 ¶ | skipping to change at page 11, line 16 ¶ | |||
now an SR-MPLS-capable transit node while all the other | now an SR-MPLS-capable transit node while all the other | |||
assumptions keep unchanged, since F is not identified by a SID in | assumptions keep unchanged, since F is not identified by a SID in | |||
the stack and an MPLS-over-UDP tunnel is preferred to an MPLS LSP | the stack and an MPLS-over-UDP tunnel is preferred to an MPLS LSP | |||
according to local policies, router E would replace the current | according to local policies, router E would replace the current | |||
top label with an MPLS-over-UDP tunnel toward router G and send it | top label with an MPLS-over-UDP tunnel toward router G and send it | |||
out. | out. | |||
IP Header Fields: When encapsulating an MPLS packet in UDP, the | IP Header Fields: When encapsulating an MPLS packet in UDP, the | |||
resulting packet is further encapsulated in IP for transmission. | resulting packet is further encapsulated in IP for transmission. | |||
IPv4 or IPv6 may be used according to the capabilities of the | IPv4 or IPv6 may be used according to the capabilities of the | |||
network. The address fields are set as described in Section 3. | network. The address fields are set as described in Section 2. | |||
The other IP header fields (such as DSCP code point, or IPv6 Flow | The other IP header fields (such as DSCP code point, or IPv6 Flow | |||
Label) on each UDP-encapsulated segment can be set according to | Label) on each UDP-encapsulated segment can be set according to | |||
the operator's policy: they may be copied from the header of the | the operator's policy: they may be copied from the header of the | |||
incoming packet; they may be promoted from the header of the | incoming packet; they may be promoted from the header of the | |||
payload packet; they may be set according to instructions | payload packet; they may be set according to instructions | |||
programmed to be associated with the SID; or they may be | programmed to be associated with the SID; or they may be | |||
configured dependent on the outgoing interface and payload. | configured dependent on the outgoing interface and payload. | |||
Entropy and ECMP: When encapsulating an MPLS packet with an IP | Entropy and ECMP: When encapsulating an MPLS packet with an IP | |||
tunnel header that is capable of encoding entropy (such as | tunnel header that is capable of encoding entropy (such as | |||
skipping to change at page 11, line 44 ¶ | skipping to change at page 11, line 44 ¶ | |||
copied to the source port of the UDP header. Otherwise, the | copied to the source port of the UDP header. Otherwise, the | |||
encapsulator may have to perform a hash on the whole label stack | encapsulator may have to perform a hash on the whole label stack | |||
or the five-tuple of the SR-MPLS payload if the payload is | or the five-tuple of the SR-MPLS payload if the payload is | |||
determined as an IP packet. To avoid re-performing the hash or | determined as an IP packet. To avoid re-performing the hash or | |||
hunting for the entropy label each time the packet is encapsulated | hunting for the entropy label each time the packet is encapsulated | |||
in a UDP tunnel it MAY be desirable that the entropy value | in a UDP tunnel it MAY be desirable that the entropy value | |||
contained in the incoming packet (i.e., the UDP source port value) | contained in the incoming packet (i.e., the UDP source port value) | |||
is retained when stripping the UDP header and is re-used as the | is retained when stripping the UDP header and is re-used as the | |||
entropy value of the outgoing packet. | entropy value of the outgoing packet. | |||
5. IANA Considerations | 4. IANA Considerations | |||
This document makes no requests for IANA action. | This document makes no requests for IANA action. | |||
6. Security Considerations | 5. Security Considerations | |||
The security consideration of [RFC8354] and [RFC7510] apply. DTLS | The security consideration of [RFC8354] and [RFC7510] apply. DTLS | |||
[RFC6347] SHOULD be used where security is needed on an MPLS-SR-over- | [RFC6347] SHOULD be used where security is needed on an MPLS-SR-over- | |||
UDP segment. | UDP segment. | |||
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. | excluding such packets at the network boundaries. | |||
It is easy for an ingress node to detect any attempt to smuggle an IP | It is easy for an ingress node to detect any attempt to smuggle an IP | |||
packet into the network since it would see that the UDP destination | packet into the network since it would see that the UDP destination | |||
port was set to MPLS. SR packets not having a destination address | port was set to MPLS. SR packets not having a destination address | |||
terminating in the network would be transparently carried and would | terminating in the network would be transparently carried and would | |||
pose no security risk to the network under consideration. | pose no security risk to the network under consideration. | |||
Where control plane techniques are used (as described in | Where control plane techniques are used (as described in | |||
Authors' Addresses it is important that these protocols are | Authors' Addresses it is important that these protocols are | |||
adequately secured for the environment in which they are run. | adequately secured for the environment in which they are run. | |||
7. Contributors | 6. Contributors | |||
Ahmed Bashandy | Ahmed Bashandy | |||
Individual | Individual | |||
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 | |||
skipping to change at page 13, line 30 ¶ | skipping to change at page 13, line 30 ¶ | |||
Email: gunter.van_de_velde@nokia.com | Email: gunter.van_de_velde@nokia.com | |||
Tal Mizrahi | Tal Mizrahi | |||
Marvell | Marvell | |||
Email: talmi@marvell.com | Email: talmi@marvell.com | |||
Jeff Tantsura | Jeff Tantsura | |||
Individual | Individual | |||
Email: jefftant@gmail.com | Email: jefftant@gmail.com | |||
8. Acknowledgements | 7. Acknowledgements | |||
Thanks to Joel Halpern, Bruno Decraene, Loa Andersson, Ron Bonica, | Thanks to Joel Halpern, Bruno Decraene, Loa Andersson, Ron Bonica, | |||
Eric Rosen, Jim Guichard, and Gunter Van De Velde for their | Eric Rosen, Jim Guichard, and Gunter Van De Velde for their | |||
insightful comments on this draft. | insightful comments on this draft. | |||
9. References | 8. References | |||
9.1. Normative References | ||||
[I-D.ietf-isis-encapsulation-cap] | ||||
Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras, | ||||
L., and L. Jalil, "Advertising Tunnelling Capability in | ||||
IS-IS", draft-ietf-isis-encapsulation-cap-01 (work in | ||||
progress), April 2017. | ||||
[I-D.ietf-isis-segment-routing-extensions] | ||||
Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., | ||||
Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, | ||||
"IS-IS Extensions for Segment Routing", draft-ietf-isis- | ||||
segment-routing-extensions-19 (work in progress), July | ||||
2018. | ||||
[I-D.ietf-ospf-encapsulation-cap] | ||||
Xu, X., Decraene, B., Raszuk, R., Contreras, L., and L. | ||||
Jalil, "The Tunnel Encapsulations OSPF Router | ||||
Information", draft-ietf-ospf-encapsulation-cap-09 (work | ||||
in progress), October 2017. | ||||
[I-D.ietf-ospf-segment-routing-extensions] | 8.1. Normative References | |||
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., | ||||
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF | ||||
Extensions for Segment Routing", draft-ietf-ospf-segment- | ||||
routing-extensions-25 (work in progress), April 2018. | ||||
[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-14 | data plane", draft-ietf-spring-segment-routing-mpls-14 | |||
(work in progress), June 2018. | (work in progress), June 2018. | |||
[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, | |||
skipping to change at page 15, line 24 ¶ | skipping to change at page 14, line 43 ¶ | |||
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions | [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions | |||
for Advertising Router Information", RFC 7981, | for Advertising Router Information", RFC 7981, | |||
DOI 10.17487/RFC7981, October 2016, | DOI 10.17487/RFC7981, October 2016, | |||
<https://www.rfc-editor.org/info/rfc7981>. | <https://www.rfc-editor.org/info/rfc7981>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
9.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-14 (work in | (SRH)", draft-ietf-6man-segment-routing-header-14 (work in | |||
progress), June 2018. | progress), June 2018. | |||
[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 | |||
skipping to change at page 15, line 47 ¶ | skipping to change at page 15, line 20 ¶ | |||
[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 | |||
Alibaba | Alibaba Inc. | |||
Email: xiaohu.xxh@alibaba-inc.com | Email: xiaohu.xxh@alibaba-inc.com | |||
Stewart Bryant | Stewart Bryant | |||
Huawei | Huawei | |||
Email: stewart.bryant@gmail.com | Email: stewart.bryant@gmail.com | |||
Adrian Farrel | Adrian Farrel | |||
Juniper | Old Dog Consulting | |||
Email: afarrel@juniper.net | Email: adrian@olddog.co.uk | |||
Syed Hassan | Syed Hassan | |||
Cisco | Cisco | |||
Email: shassan@cisco.com | Email: shassan@cisco.com | |||
Wim Henderickx | Wim Henderickx | |||
Nokia | Nokia | |||
Email: wim.henderickx@nokia.com | Email: wim.henderickx@nokia.com | |||
End of changes. 39 change blocks. | ||||
102 lines changed or deleted | 70 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/ |