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/