draft-ietf-mpls-sr-over-ip-03.txt | draft-ietf-mpls-sr-over-ip-04.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: September 4, 2019 Huawei | Expires: October 15, 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 | |||
March 3, 2019 | April 13, 2019 | |||
SR-MPLS over IP | SR-MPLS over IP | |||
draft-ietf-mpls-sr-over-ip-03 | draft-ietf-mpls-sr-over-ip-04 | |||
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 | |||
could 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 preserving backward compatibility with | routing instruction set while making no changes to SR-MPLS | |||
SR-MPLS. | specifications and interworking with SR-MPLS implementations. | |||
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 as defined in RFC 7510. | UDP as defined in RFC 7510. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at 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 September 4, 2019. | This Internet-Draft will expire on October 15, 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 32 ¶ | skipping to change at page 2, line 32 ¶ | |||
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.2. Packet Forwarding Procedures . . . . . . . . . . . . . . 7 | |||
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 . . 9 | |||
3.2.3. Additional Forwarding Procedures . . . . . . . . . . 10 | 3.2.3. Additional Forwarding Procedures . . . . . . . . . . 10 | |||
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 | 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 14 | 8.2. Informative References . . . . . . . . . . . . . . . . . 15 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
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 backward compatibility with SR-MPLS. | planes. This approach preserves makes no changes to SR-MPLS | |||
specifications and allows interworking with SR-MPLS implementations. | ||||
More specifically, the source routing instruction set information | More specifically, the source routing instruction set information | |||
contained in a source routed packet could be uniformly encoded as an | contained in a source routed packet could be uniformly encoded as an | |||
MPLS label stack no matter whether the underlay is IPv4, IPv6, or | MPLS label stack no matter whether the underlay is IPv4, IPv6, or | |||
MPLS. | 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]. | |||
skipping to change at page 4, line 27 ¶ | skipping to change at page 4, line 27 ¶ | |||
(_______) ( ) (_______) | (_______) ( ) (_______) | |||
(________________________) | (________________________) | |||
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 ([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. Refer to | the entropy label mechanism. This is to be contrasted with | |||
[I-D.ietf-mpls-spring-entropy-label]) for more discussion about | [RFC4023] where MPLS-in-IP does not provide for an entropy | |||
using entropy labels in SR-MPLS. | mechanism. Refer to [I-D.ietf-mpls-spring-entropy-label]) for | |||
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 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 2. | forwarding is not an option. This is shown in Figure 2. | |||
__________________________________ | __________________________________ | |||
__( IP Network )__ | __( IP Network )__ | |||
__( )__ | __( )__ | |||
( -- -- -- ) | ( -- -- -- ) | |||
skipping to change at page 6, line 5 ¶ | skipping to change at page 6, line 5 ¶ | |||
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. | |||
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 The Segment Routing Global Block (SRGB) is defined in [RFC8402]. | o Router E is SR-MPLS capable, so it advertises a Segment Routing | |||
Router E is SR-MPLS capable, so it advertises an SRGB as described | Global Block (SRGB) using the mechanisms 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]. The SRGB is defined | |||
in [RFC8402]. | ||||
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 does this using the mechanisms | of any tunnel used to reach E. It can do this using the | |||
described in [I-D.ietf-isis-encapsulation-cap] or | mechanisms 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. | |||
* The OSPF SID/label range TLV | * The OSPF SID/label range TLV | |||
skipping to change at page 6, line 41 ¶ | skipping to change at page 6, line 42 ¶ | |||
+ 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 | * If router E is running ISIS and advertises the ISIS capability | |||
capabilities TLV (TLV 242) [RFC7981], it MUST set the "router- | TLV (TLV 242) [RFC7981], it MUST set the "router-ID" field to a | |||
ID" field to a valid value or include an IPV6 TE router-ID sub- | valid value or include an IPV6 TE router-ID sub-TLV (TLV 12), | |||
TLV (TLV 12), or do both. The "S" bit (flooding scope) of the | or do both. The "S" bit (flooding scope) of the ISIS | |||
ISIS capabilities TLV (TLV 242) MUST be set to "1" . | capability TLV (TLV 242) MUST be 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) 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 to tell a router how to process | Once constructed, the FIB can be used by a router to tell it how to | |||
packets. It encapsulates the packets according to the encapsulation | process packets. It encapsulates the packets according to the | |||
advertised in [I-D.ietf-isis-encapsulation-cap] or | appropriate encapsulation (for example, as advertised using the | |||
mechanisms described in [I-D.ietf-isis-encapsulation-cap] or | ||||
[I-D.ietf-ospf-encapsulation-cap]. Then it sends the packets towards | [I-D.ietf-ospf-encapsulation-cap]. Then it sends the packets towards | |||
the next hop NHi. | 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 when UDP encapsulation is | details about the forwarding procedure when UDP encapsulation is | |||
adopted for SR-MPLS over IP. | adopted for SR-MPLS over IP. Other encapsulation and tunnelling | |||
mechanisms can be applied using similar techniques, but for clarity | ||||
this section uses UDP encapsulation as the exemplar. | ||||
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 3. 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 | |||
skipping to change at page 8, line 38 ¶ | skipping to change at page 8, line 44 ¶ | |||
| L(H) | | L(H) | |Exp Null| | | L(H) | | L(H) | |Exp Null| | |||
+--------+ +--------+ +--------+ | +--------+ +--------+ +--------+ | |||
| Packet | ---> | Packet | ---> | Packet | | | Packet | ---> | Packet | ---> | Packet | | |||
+--------+ +--------+ +--------+ | +--------+ +--------+ +--------+ | |||
Figure 3: Packet Forwarding Example with PHP | Figure 3: Packet Forwarding Example with PHP | |||
In the example shown in Figure 3, assume that routers A, E, G and H | In the example shown in Figure 3, assume that routers A, E, G and H | |||
are SR-MPLS-capable while the remaining routers (B, C, D and F) are | are SR-MPLS-capable while the remaining routers (B, C, D and F) are | |||
only capable of forwarding IP packets. Routers A, E, G, and H | only capable of forwarding IP packets. Routers A, E, G, and H | |||
advertise their Segment Routing related information via IS-IS or | advertise their Segment Routing related information, such as via IS- | |||
OSPF. | IS or OSPF. | |||
Now assume that router A (the Domain ingress) wants to send a packet | Now assume that router A (the Domain ingress) wants to send a packet | |||
to router H (the Domain egress) via the explicit path {E->G->H}. | to router H (the Domain egress) via the explicit path {E->G->H}. | |||
Router A will impose an MPLS label stack on the packet that | Router A will impose an MPLS label stack on the packet that | |||
corresponds to that explicit path. Since the next hop toward router | corresponds to that explicit path. Since the next hop toward router | |||
E is only IP-capable (B is a legacy transit node), router A replaces | E is only IP-capable (B is a legacy transit node), router A replaces | |||
the top label (that indicated router E) with a UDP-based tunnel for | the top label (that indicated router E) with a UDP-based tunnel for | |||
MPLS (i.e., MPLS-over-UDP [RFC7510]) to router E and then sends the | MPLS (i.e., MPLS-over-UDP [RFC7510]) to router E and then sends the | |||
packet. In other words, router A pops the top label and then | packet. In other words, router A pops the top label and then | |||
encapsulates the MPLS packet in a UDP tunnel to router E. | encapsulates the MPLS packet in a UDP tunnel to router E. | |||
skipping to change at page 11, line 7 ¶ | skipping to change at page 11, line 7 ¶ | |||
SID. | SID. | |||
When to use IP-based Tunnel: The description in the previous two | When to use IP-based Tunnel: The description in the previous two | |||
sections is based on the assumption that MPLS-over-UDP tunnel is | sections is based on the assumption that MPLS-over-UDP tunnel is | |||
used when the nexthop towards the next segment is not MPLS- | used when the nexthop towards the next segment is not MPLS- | |||
enabled. However, even in the case where the nexthop towards the | enabled. However, even in the case where the nexthop towards the | |||
next segment is MPLS-capable, an MPLS-over-UDP tunnel towards the | next segment is MPLS-capable, an MPLS-over-UDP tunnel towards the | |||
next segment could still be used instead due to local policies. | next segment could still be used instead due to local policies. | |||
For instance, in the example as described in Figure 4, assume F is | For instance, in the example as described in Figure 4, assume F is | |||
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 remain unchanged: since F is not identified by a SID | |||
the stack and an MPLS-over-UDP tunnel is preferred to an MPLS LSP | in the stack and an MPLS-over-UDP tunnel is preferred to an MPLS | |||
according to local policies, router E would replace the current | LSP according to local policies, router E replaces the current top | |||
top label with an MPLS-over-UDP tunnel toward router G and send it | label with an MPLS-over-UDP tunnel toward router G and send it | |||
out. | out. (Note that if an MPLS LSP was preferred, the packet would be | |||
forwarded as native SR-MPLS.) | ||||
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 2. | 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 the ECN field [RFC6040], the | |||
Label) on each UDP-encapsulated segment SHOULD be configurable | DSCP code point [RFC2983], or IPv6 Flow Label) on each UDP- | |||
according to the operator's policy: they may be copied from the | encapsulated segment SHOULD be configurable according to the | |||
header of the incoming packet; they may be promoted from the | operator's policy: they may be copied from the header of the | |||
header of the payload packet; they may be set according to | incoming packet; they may be promoted from the header of the | |||
instructions programmed to be associated with the SID; or they may | payload packet; they may be set according to instructions | |||
be configured dependent on the outgoing interface and payload. | programmed to be associated with the SID; or they may be | |||
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 | |||
[RFC7510]), the corresponding entropy field (the source port in | [RFC7510]), the corresponding entropy field (the source port in | |||
case UDP tunnel) MAY be filled with an entropy value that is | the case of a UDP tunnel) MAY be filled with an entropy value that | |||
generated by the encapsulator to uniquely identify a flow. | is generated by the encapsulator to uniquely identify a flow. | |||
However, what constitutes a flow is locally determined by the | However, what constitutes a flow is locally determined by the | |||
encapsulator. For instance, if the MPLS label stack contains at | encapsulator. For instance, if the MPLS label stack contains at | |||
least one entropy label and the encapsulator is capable of reading | least one entropy label and the encapsulator is capable of reading | |||
that entropy label, the entropy label value could be directly | that entropy label, the entropy label value could be directly | |||
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. | |||
Congestion Considerations: Section 5 of [RFC7510] provides a | ||||
detailed analysis of the implications of congestion in MPLS-over- | ||||
UDP systems and builds on section 3.1.3 of [RFC8085] that | ||||
describes the congestion implications of UDP tunnels. All of | ||||
those considerations apply to SR-MPLS-over-UDP tunnels as | ||||
described in this document. In particular, it should be noted | ||||
that the traffic carried in SR-MPLS flows is likely to be IP | ||||
traffic. | ||||
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] and [RFC7510] apply. DTLS | The security consideration of [RFC8354] (which redirects the reader | |||
[RFC6347] SHOULD be used where security is needed on an MPLS-SR-over- | to [RFC5095]) and [RFC7510] apply. DTLS [RFC6347] SHOULD be used | |||
UDP segment. | where security is needed on an MPLS-SR-over-UDP segment including | |||
when the IP segment crosses the public Internet or some other | ||||
untrusted environment. | ||||
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, for example by | |||
excluding all MPLS packets that are revealed as payload of IP | ||||
tunnels. Further discussion of MPLS security is found in [RFC5920]. | ||||
It is easy for an ingress node to detect any attempt to smuggle an IP | It is easy for a network ingress node to detect any attempt to | |||
packet into the network since it would see that the UDP destination | smuggle an IP packet into the network since it would see that the UDP | |||
port was set to MPLS. SR packets not having a destination address | destination port was set to MPLS, and such filtering SHOULD be | |||
terminating in the network would be transparently carried and would | applied. SR packets not having a destination address terminating in | |||
pose no security risk to the network under consideration. | the network would be transparently carried and would pose no | |||
different security risk to the network under consideration than any | ||||
other traffic. | ||||
Where control plane techniques are used (as described in Section 3), | Where control plane techniques are used (as described in Section 3), | |||
it is important that these protocols are adequately secured for the | it is important that these protocols are adequately secured for the | |||
environment in which they are run. | environment in which they are run as discussed in [RFC6862] and | |||
[RFC5920]. | ||||
6. 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 | |||
skipping to change at page 13, line 36 ¶ | skipping to change at page 14, line 5 ¶ | |||
Jeff Tantsura | Jeff Tantsura | |||
Individual | Individual | |||
Email: jefftant@gmail.com | Email: jefftant@gmail.com | |||
7. 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, Gunter Van De Velde, Andy Malis, Robert | Eric Rosen, Jim Guichard, Gunter Van De Velde, Andy Malis, Robert | |||
Sparks, and Al Morton for their insightful comments on this draft. | Sparks, and Al Morton for their insightful comments on this draft. | |||
Additional thanks to Mirja Kuehlewind, Alvaro Retana, Spencer | ||||
Dawkins, Benjamin Kaduk, and Martin Vigoureux for careful reviews and | ||||
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-18 | data plane", draft-ietf-spring-segment-routing-mpls-19 | |||
(work in progress), December 2018. | (work in progress), March 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>. | |||
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., | [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., | |||
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack | Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack | |||
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, | Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, | |||
<https://www.rfc-editor.org/info/rfc3032>. | <https://www.rfc-editor.org/info/rfc3032>. | |||
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation | ||||
of Type 0 Routing Headers in IPv6", RFC 5095, | ||||
DOI 10.17487/RFC5095, December 2007, | ||||
<https://www.rfc-editor.org/info/rfc5095>. | ||||
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion | ||||
Notification", RFC 6040, DOI 10.17487/RFC6040, November | ||||
2010, <https://www.rfc-editor.org/info/rfc6040>. | ||||
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | |||
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, | Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, | |||
January 2012, <https://www.rfc-editor.org/info/rfc6347>. | January 2012, <https://www.rfc-editor.org/info/rfc6347>. | |||
[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>. | |||
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., | [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., | |||
skipping to change at page 15, line 8 ¶ | skipping to change at page 15, line 34 ¶ | |||
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., | [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., | |||
Decraene, B., Litkowski, S., and R. Shakir, "Segment | Decraene, B., Litkowski, S., and R. Shakir, "Segment | |||
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, | Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, | |||
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-16 (work in | (SRH)", draft-ietf-6man-segment-routing-header-18 (work in | |||
progress), February 2019. | progress), April 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-22 (work in progress), December 2018. | extensions-23 (work in progress), March 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 | |||
Information", draft-ietf-ospf-encapsulation-cap-09 (work | Information", draft-ietf-ospf-encapsulation-cap-09 (work | |||
in progress), October 2017. | in progress), October 2017. | |||
[I-D.ietf-ospf-segment-routing-extensions] | [I-D.ietf-ospf-segment-routing-extensions] | |||
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., | Psenak, P., Previdi, S., Filsfils, C., Gredler, H., | |||
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF | Shakir, R., Henderickx, W., and J. Tantsura, "OSPF | |||
Extensions for Segment Routing", draft-ietf-ospf-segment- | Extensions for Segment Routing", draft-ietf-ospf-segment- | |||
routing-extensions-27 (work in progress), December 2018. | routing-extensions-27 (work in progress), December 2018. | |||
[RFC2983] Black, D., "Differentiated Services and Tunnels", | ||||
RFC 2983, DOI 10.17487/RFC2983, October 2000, | ||||
<https://www.rfc-editor.org/info/rfc2983>. | ||||
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., | ||||
"Encapsulating MPLS in IP or Generic Routing Encapsulation | ||||
(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, | ||||
<https://www.rfc-editor.org/info/rfc4023>. | ||||
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS | ||||
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, | ||||
<https://www.rfc-editor.org/info/rfc5920>. | ||||
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and | [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and | |||
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", | L. Yong, "The Use of Entropy Labels in MPLS Forwarding", | |||
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 | ||||
Authentication for Routing Protocols (KARP) Overview, | ||||
Threats, and Requirements", RFC 6862, | ||||
DOI 10.17487/RFC6862, March 2013, | ||||
<https://www.rfc-editor.org/info/rfc6862>. | ||||
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage | ||||
Guidelines", RFC 8085, DOI 10.17487/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 | |||
Alibaba, Inc | Alibaba, Inc | |||
End of changes. 31 change blocks. | ||||
63 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/ |