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/