draft-ietf-mpls-sr-over-ip-06.txt		draft-ietf-mpls-sr-over-ip-07.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: November 24, 2019 Huawei		Expires: December 18, 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
	May 23, 2019		June 16, 2019
	SR-MPLS over IP		SR-MPLS over IP
	draft-ietf-mpls-sr-over-ip-06		draft-ietf-mpls-sr-over-ip-07
	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 November 24, 2019.		This Internet-Draft will expire on December 18, 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 30 ¶		skipping to change at page 2, line 30 ¶
	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.1.1. FIB Construction Example . . . . . . . . . . . . . . 6		3.1.1. FIB Construction Example . . . . . . . . . . . . . . 6
	3.2. Packet Forwarding Procedures . . . . . . . . . . . . . . 8		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 . . . 9
	3.2.2. Packet Forwarding without Penultimate Hop Popping . . 10		3.2.2. Packet Forwarding without Penultimate Hop Popping . . 10
	3.2.3. Additional Forwarding Procedures . . . . . . . . . . 11		3.2.3. Additional Forwarding Procedures . . . . . . . . . . 11
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 13		5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13		6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	8.1. Normative References . . . . . . . . . . . . . . . . . . 15		8.1. Normative References . . . . . . . . . . . . . . . . . . 15
	8.2. Informative References . . . . . . . . . . . . . . . . . 16		8.2. Informative References . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		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 makes no changes to SR-MPLS specifications and		planes. This approach makes no changes to SR-MPLS specifications and
	allows interworking with SR-MPLS implementations. More specifically,		allows interworking with SR-MPLS implementations. More specifically,
	the source routing instruction set information contained in a source		the source routing instruction set information contained in a source
	routed packet could be uniformly encoded as an MPLS label stack no		routed packet could be uniformly encoded as an MPLS label stack no
	matter whether the underlay is IPv4, IPv6, or MPLS.		matter whether the underlay is IPv4, IPv6 (including Segment Routing
			for IPv6 (SRv6) [RFC8354]), 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 31 ¶		skipping to change at page 3, line 32 ¶
	[I-D.ietf-spring-segment-routing-mpls].		[I-D.ietf-spring-segment-routing-mpls].
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	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 (including SRv6) tunnels is
	in the use cases listed below. In all cases, this can be enabled		useful at least in the use cases listed below. In all cases, this
	using an IP tunneling mechanism such as MPLS-in-UDP as described in		can be enabled using an IP tunneling mechanism such as MPLS-in-UDP as
	[RFC7510]. The tunnel selected MUST have its remote end point		described in [RFC7510]. The tunnel selected MUST have its remote end
	(destination) address equal to the address of the next SR-MPLS		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		capable node identified as being on the SR path (i.e., the egress of
	the active segment). The local end point (source) address is set to		the active segment). The local end point (source) address is set to
	an address of the encapsulating node. [RFC7510] gives further advice		an address of the encapsulating node. [RFC7510] gives further advice
	on how to set the source address if the UDP zero-checksum mode is		on how to set the source address if the UDP zero-checksum mode is
	used with MPLS-in-UDP.		used with MPLS-in-UDP. Using UDP as the encapsulation may be
			particularly beneficial because it is agnostic of the underlying
			transport.
	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 as shown in Figure 1. This demonstrates how		that are not SR-MPLS as shown in Figure 1. This demonstrates how
	islands of SR-MPLS may be connected across a legacy network. It		islands of SR-MPLS may be connected across a legacy network. It
	may be particularly useful for joining sites (such as data		may be particularly useful for joining sites (such as data
	centers).		centers).
	________________________		________________________
	_______ ( ) _______		_______ ( ) _______
	skipping to change at page 8, line 8 ¶		skipping to change at page 8, line 8 ¶
	bound of the SRGB of E		bound of the SRGB of E
	When forwarding the packet according to the constructed FIB entry the		When forwarding the packet according to the constructed FIB entry the
	router encapsulates the packet according to the encapsulation as		router encapsulates the packet according to the encapsulation as
	advertised using the mechanisms described in		advertised using the mechanisms described in
	[I-D.ietf-isis-encapsulation-cap] or		[I-D.ietf-isis-encapsulation-cap] or
	[I-D.ietf-ospf-encapsulation-cap]). It then sends the packets		[I-D.ietf-ospf-encapsulation-cap]). It then sends the packets
	towards the next hop NHi.		towards the next hop NHi.
			Note that [RFC7510] specifies the use of port number 6635 to indicate
			that the payload of a UDP packet is MPLS, and port number 6636 for
			MPLS-in-UDP utilizing DTLS. However,
			[I-D.ietf-isis-encapsulation-cap] and
			[I-D.ietf-ospf-encapsulation-cap] provide dynamic protocol mechanisms
			to configure the use any Dynamic Port for a tunnel that uses UDP
			encapsulation. Nothing in this document prevents the use of an IGP
			or any other mechanism to negotiate the use of a Dynamic Port when
			UDP encapsulation is used for SR-MPLS, but if no such mechanism is
			used then the port numbers specified in [RFC7510] are used.
	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
	mechanisms can be applied using similar techniques, but for clarity		mechanisms can be applied using similar techniques, but for clarity
	skipping to change at page 11, line 46 ¶		skipping to change at page 11, line 46 ¶
	Non-MPLS Interfaces: Although the description in the previous two		Non-MPLS Interfaces: Although the description in the previous two
	sections is based on the use of prefix-SIDs, tunneling SR-MPLS		sections is based on the use of prefix-SIDs, tunneling SR-MPLS
	packets is useful when the top label of a received SR-MPLS packet		packets is useful when the top label of a received SR-MPLS packet
	indicates an adjacency-SID and the corresponding adjacent node to		indicates an adjacency-SID and the corresponding adjacent node to
	that adjacency-SID is not capable of MPLS forwarding but can still		that adjacency-SID is not capable of MPLS forwarding but can still
	process SR-MPLS packets. In this scenario the top label would be		process SR-MPLS packets. In this scenario the top label would be
	replaced by an IP tunnel toward that adjacent node and then		replaced by an IP tunnel toward that adjacent node and then
	forwarded over the corresponding link indicated by the adjacency-		forwarded over the corresponding link indicated by the adjacency-
	SID.		SID.
	When to use IP-based Tunnel: The description in the previous two		When to use IP-based Tunnels: 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 remain unchanged: since F is not identified by a SID		assumptions remain unchanged: since F is not identified by a SID
	in the stack and an MPLS-over-UDP tunnel is preferred to an MPLS		in the stack and an MPLS-over-UDP tunnel is preferred to an MPLS
	LSP according to local policies, router E replaces the current top		LSP according to local policies, router E replaces the current top
	skipping to change at page 12, line 23 ¶		skipping to change at page 12, line 23 ¶
	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 the ECN field [RFC6040], the		The other IP header fields (such as the ECN field [RFC6040], the
	DSCP code point [RFC2983], or IPv6 Flow Label) on each UDP-		DSCP code point [RFC2983], or IPv6 Flow Label) on each UDP-
	encapsulated segment SHOULD be configurable according to the		encapsulated segment SHOULD be configurable according to the
	operator's policy: they may be copied from the header of the		operator's policy: they may be copied from the header of the
	incoming packet; they may be promoted from the header of the		incoming packet; they may be promoted from the header of the
	payload packet; they may be set according to instructions		payload packet; they may be set according to instructions
	programmed to be associated with the SID; or they may be		programmed to be associated with the SID; or they may be
	configured dependent on the outgoing interface and payload.		configured dependent on the outgoing interface and payload. The
			TTL field setting in the encapsulating packet header is handled as
			described in [RFC7510] which refers to [RFC4023].
	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
	the case of a UDP tunnel) MAY be filled with an entropy value that		the case of a UDP tunnel) MAY be filled with an entropy value that
	is 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
	skipping to change at page 13, line 29 ¶		skipping to change at page 13, line 31 ¶
	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 packets that are revealed to be carrying an MPLS packet		excluding all packets that are revealed to be carrying an MPLS packet
	as the payload of IP tunnels. Further discussion of MPLS security is		as the payload of IP tunnels. Further discussion of MPLS security is
	found in [RFC5920].		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. If, however, the mechanisms described in
	the network would be transparently carried and would pose no		[I-D.ietf-ospf-segment-routing-extensions] or
	different security risk to the network under consideration than any		[I-D.ietf-isis-segment-routing-extensions] are applied, a wider
	other traffic.		variety of UDP port numbers might be in use making port filtering
			harder.
			SR packets not having a destination address terminating in 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 as discussed in [RFC6862] and		environment in which they are run as discussed in [RFC6862] and
	[RFC5920].		[RFC5920].
	6. Contributors		6. Contributors
	Ahmed Bashandy		Ahmed Bashandy
	Individual		Individual
	skipping to change at page 15, line 6 ¶		skipping to change at page 15, line 12 ¶
	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		Additional thanks to Mirja Kuehlewind, Alvaro Retana, Spencer
	Dawkins, Benjamin Kaduk, and Martin Vigoureux for careful reviews and		Dawkins, Benjamin Kaduk, Martin Vigoureux, Suresh Krishnan, and Eric
	resulting comments.		Vyncke 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-22		data plane", draft-ietf-spring-segment-routing-mpls-22
	(work in progress), May 2019.		(work in progress), May 2019.
	skipping to change at page 15, line 34 ¶		skipping to change at page 15, line 40 ¶
	[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>.
			[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>.
	[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation		[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
	of Type 0 Routing Headers in IPv6", RFC 5095,		of Type 0 Routing Headers in IPv6", RFC 5095,
	DOI 10.17487/RFC5095, December 2007,		DOI 10.17487/RFC5095, December 2007,
	<https://www.rfc-editor.org/info/rfc5095>.		<https://www.rfc-editor.org/info/rfc5095>.
	[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion		[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
	Notification", RFC 6040, DOI 10.17487/RFC6040, November		Notification", RFC 6040, DOI 10.17487/RFC6040, November
	2010, <https://www.rfc-editor.org/info/rfc6040>.		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
	skipping to change at page 16, line 35 ¶		skipping to change at page 16, line 44 ¶
	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., Dukes, D., Previdi, S., Leddy, J.,		Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
	Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment		Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
	Routing Header (SRH)", draft-ietf-6man-segment-routing-		Routing Header (SRH)", draft-ietf-6man-segment-routing-
	header-19 (work in progress), May 2019.		header-21 (work in progress), June 2019.
	[I-D.ietf-bess-datacenter-gateway]		[I-D.ietf-bess-datacenter-gateway]
	Farrel, A., Drake, J., Rosen, E., Patel, K., and L. Jalil,		Farrel, A., Drake, J., Rosen, E., Patel, K., and L. Jalil,
	"Gateway Auto-Discovery and Route Advertisement for		"Gateway Auto-Discovery and Route Advertisement for
	Segment Routing Enabled Domain Interconnection", draft-		Segment Routing Enabled Domain Interconnection", draft-
	ietf-bess-datacenter-gateway-02 (work in progress),		ietf-bess-datacenter-gateway-02 (work in progress),
	February 2019.		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,
	skipping to change at page 17, line 33 ¶		skipping to change at page 17, line 39 ¶
	[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",		[RFC2983] Black, D., "Differentiated Services and Tunnels",
	RFC 2983, DOI 10.17487/RFC2983, October 2000,		RFC 2983, DOI 10.17487/RFC2983, October 2000,
	<https://www.rfc-editor.org/info/rfc2983>.		<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		[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
	Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,		Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
	<https://www.rfc-editor.org/info/rfc5920>.		<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		[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and
End of changes. 17 change blocks.
	27 lines changed or deleted		49 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/