< draft-ietf-sfc-nsh-ecn-support-00.txt		draft-ietf-sfc-nsh-ecn-support-01.txt >
	INTERNET-DRAFT Donald Eastlake		INTERNET-DRAFT Donald Eastlake
	Intended status: Proposed Standard Huawei		Intended status: Proposed Standard Futurewei Technologies
	Bob Briscoe		Bob Briscoe
	Independent		Independent
	Andrew Malis		Andrew Malis
	Huawei		Futurewei Technologies
	Expires: August 6, 2019 February 7, 2019		Expires: January 6, 2020 July 7, 2019
	Explicit Congestion Notification (ECN) and Congestion Feedback		Explicit Congestion Notification (ECN) and Congestion Feedback
	Using the Network Service Header (NSH)		Using the Network Service Header (NSH)
	<draft-ietf-sfc-nsh-ecn-support-00.txt>		<draft-ietf-sfc-nsh-ecn-support-01.txt>
	Abstract		Abstract
	Explicit congestion notification (ECN) allows a forwarding element to		Explicit congestion notification (ECN) allows a forwarding element to
	notify downstream devices of the onset of congestion without having		notify downstream devices of the onset of congestion without having
	to drop packets. Coupled with a means to feed back information about		to drop packets. Coupled with a means to feed back information about
	congestion to upstream nodes, this can improve network efficiency		congestion to upstream nodes, this can improve network efficiency
	through better congestion control, frequently without packet drops.		through better congestion control, frequently without packet drops.
	This document specifies ECN and congestion feedback support within a		This document specifies ECN and congestion feedback support within a
	Service Function Chaining (SFC) domain through use of the Network		Service Function Chaining (SFC) domain through use of the Network
	skipping to change at page 5, line 14 ¶		skipping to change at page 5, line 14 ¶
	INTERNET-DRAFT NSH ECN & Congestion Feedback		INTERNET-DRAFT NSH ECN & Congestion Feedback
	added may be different in different regions of the SFC domain. For		added may be different in different regions of the SFC domain. For
	example, IP could be used for some SFF-to-SFF communication and MPLS		example, IP could be used for some SFF-to-SFF communication and MPLS
	used for other such communication.		used for other such communication.
	1.2 ECN Background		1.2 ECN Background
	Explicit congestion notification (ECN [RFC3168]) allows a forwarding		Explicit congestion notification (ECN [RFC3168]) allows a forwarding
	element (such as a router or an Service Function Forwarder (SFF) or		element (such as a router or a Service Function Forwarder (SFF) or
	Service Function (SF)) to notify downstream devices of the onset of		Service Function (SF)) to notify downstream devices of the onset of
	congestion without having to drop packets. This can be used as an		congestion without having to drop packets. This can be used as an
	element in active queue management (AQM) [RFC7567] to improve network		element in active queue management (AQM) [RFC7567] to improve network
	efficiency through better traffic control without packet drops. The		efficiency through better traffic control without packet drops. The
	forwarding element can explicitly mark some packets in an ECN field		forwarding element can explicitly mark some packets in an ECN field
	instead of dropping the packet. For example, a two-bit field is		instead of dropping the packet. For example, a two-bit field is
	available for ECN marking in IP headers [RFC3168].		available for ECN marking in IP headers [RFC3168].
	1.3 Tunnel Congestion Feedback Background		1.3 Tunnel Congestion Feedback Background
	skipping to change at page 6, line 8 ¶		skipping to change at page 6, line 8 ¶
	of some future traffic so that it avoids congested paths. Great		of some future traffic so that it avoids congested paths. Great
	care must be taken to avoid (a) significant re-ordering of		care must be taken to avoid (a) significant re-ordering of
	traffic in flows that it is desirable to keep in order and (b)		traffic in flows that it is desirable to keep in order and (b)
	oscillation/instability in traffic paths due to alternate		oscillation/instability in traffic paths due to alternate
	congestion of previously idle paths and the idling of previously		congestion of previously idle paths and the idling of previously
	congested paths. For example, it is preferable to classify		congested paths. For example, it is preferable to classify
	INTERNET-DRAFT NSH ECN & Congestion Feedback		INTERNET-DRAFT NSH ECN & Congestion Feedback
	traffic into flows of a sufficiently coarse granularity that the		traffic into flows of a sufficiently coarse granularity that the
	flows are long lived and use a stable path per flow sending only		flows are long lived and use a stable path per flow, then send
	newly appearing flows on apparently uncongested paths.		only newly appearing flows on apparently uncongested paths.
	Figure 2 shows an example path from an origin sender to a final		Figure 2 shows an example path from an origin sender to a final
	receiver passing through an example chain of service functions		receiver passing through an example chain of service functions
	between the ingress and egress of an SFC domain. The path is also		between the ingress and egress of an SFC domain. The path is also
	likely to pass through other network nodes outside the SFC domain		likely to pass through other network nodes outside the SFC domain
	(not shown). The figure shows typical congestion feedback that would		(not shown). The figure shows typical congestion feedback that would
	be expected from the final receiver to the origin sender, which		be expected from the final receiver to the origin sender, which
	controls the load the origin sender applies to all elements on the		controls the load the origin sender applies to all elements on the
	path. The figure also shows the congestion feedback from the egress		path. The figure also shows the congestion feedback from the egress
	to the ingress of the SFC domain that is described in this document,		to the ingress of the SFC domain that is described in this document,
	skipping to change at page 10, line 26 ¶		skipping to change at page 10, line 26 ¶
	uniform so that, if this document is applicable, all SFFs will		uniform so that, if this document is applicable, all SFFs will
	support ECN; however, some legacy SFs might not support ECN.		support ECN; however, some legacy SFs might not support ECN.
	ECN Propagation:		ECN Propagation:
	The specification of ECN tunneling [RFC6040] explains that an		The specification of ECN tunneling [RFC6040] explains that an
	ingress must not propagate ECN support into an encapsulating		ingress must not propagate ECN support into an encapsulating
	header unless the egress supports correct onward propagation of		header unless the egress supports correct onward propagation of
	the ECN field during decapsulation. We define Compliant ECN		the ECN field during decapsulation. We define Compliant ECN
	Decapsulation here as decapsulation compliant with either		Decapsulation here as decapsulation compliant with either
	[RFC6040] or an earlier compatible equivalent ([RFC4301], or full		[RFC6040] or an earlier compatible equivalent ([RFC4301], or the
	functionality mode of [RFC3168]).		full functionality mode of [RFC3168]).
	The procedures in Section 3.2.1 ensure that each ingress of the		The procedures in Section 3.2.1 ensure that each ingress of the
	large number of possible transport links within the SFC domain		large number of possible transport links within the SFC domain
	does not propagate ECN support into the encapsulating outer		does not propagate ECN support into the encapsulating outer
	transport header unless the corresponding egress of that link		transport header unless the corresponding egress of that link
	supports Compliant ECN Decapsulation.		supports Compliant ECN Decapsulation.
	Section 3.3 requires that all the egress nodes of the SFC domain		Section 3.3 requires that all the egress nodes of the SFC domain
	support Compliant ECN Decapsulation in conjunction with tunnel		support Compliant ECN Decapsulation in conjunction with tunnel
	congestion feedback, otherwise the scheme in this document will		congestion feedback, otherwise the scheme in this document will
	not work.		not work.
	ECN Marking:		ECN Marking:
	At transit nodes the marking behavior specified in 3.2.1 is		At transit nodes the marking behavior specified in Section 3.2.1
	recommended and if not implemented at such transit nodes, there		is recommended and if not implemented at such transit nodes, there
	may be unmanaged congestion.		may be unmanaged congestion.
	Detection of congestion will be most effective if ECN marking is		Detection of congestion will be most effective if ECN marking is
	supported by all potential bottlenecks inside the domain in which		supported by all potential bottlenecks inside the domain in which
	NSH is being used to route traffic as well as at the ingress and		NSH is being used to route traffic as well as at the ingress and
	egress. Nodes that do not support ECN marking, or that support		egress. Nodes that do not support ECN marking, or that support
	AQM but not ECN, will naturally use drop to relieve congestion.		AQM but not ECN, will naturally use drop to relieve congestion.
	The gap in the end-to-end packet sequence will be detected as		The gap in the end-to-end packet sequence will be detected as
	congestion by the final receiving endpoint, but not by the NSH		congestion by the final receiving endpoint, but not by the NSH
	egress (see Figure 2).		egress (see Figure 2).
	skipping to change at page 13, line 37 ¶		skipping to change at page 13, line 37 ¶
	congestion in the proxy itself in the NSH that it returns to the		congestion in the proxy itself in the NSH that it returns to the
	SFF. The outer header used for the proxy to SF path uses Normal		SFF. The outer header used for the proxy to SF path uses Normal
	Mode. The outer head used for the proxy return to SFF path uses		Mode. The outer head used for the proxy return to SFF path uses
	Normal Mode based copying the NSH ECN field to the outer header.		Normal Mode based copying the NSH ECN field to the outer header.
	Thus congestion in the proxy will be managed. Congestion in the SF		Thus congestion in the proxy will be managed. Congestion in the SF
	will be managed only if the SF is ECN-aware implementing an AQM.		will be managed only if the SF is ECN-aware implementing an AQM.
	3.2.3 At Other Forwarding Nodes		3.2.3 At Other Forwarding Nodes
	Other forwarding nodes, that is non-NSH forwarding nodes between NSH		Other forwarding nodes, that is non-NSH forwarding nodes between NSH
	forwarding nodes, such as IP routers, might also be potential		forwarding nodes, such as IP routers, might also contain potential
	bottlenecks. If so, they SHOULD implement an AQM algorithm to update		bottlenecks. If so, they SHOULD implement an AQM algorithm to update
	the ECN marking in the outer transport header as specified in		the ECN marking in the outer transport header as specified in
	[RFC3168].		[RFC3168].
	3.3 At Exit/Egress		3.3 At Exit/Egress
	First, any actions are taken based on Congestion Experienced such as		First, any actions are taken based on Congestion Experienced, such as
	forwarding statistics back to the ingress (see Section 4). If the		forwarding statistics back to the ingress (see Section 4). If the
	packet being carried inside the NSH is IP, when the NSH is removed		packet being carried inside the NSH is IP, when the NSH is removed
	the NSH ECN field MUST be combined with IP ECN field as specified in		the NSH ECN field MUST be combined with IP ECN field as specified in
	Table 3 that was extracted from [RFC6040]. This requirement applies		Table 3 that was extracted from [RFC6040]. This requirement applies
	to all egress nodes for the domain in which NSH is being used to		to all egress nodes for the domain in which NSH is being used to
	route traffic.		route traffic.
	INTERNET-DRAFT NSH ECN & Congestion Feedback		INTERNET-DRAFT NSH ECN & Congestion Feedback
	+---------+---------------------------------------------+		+---------+---------------------------------------------+
	skipping to change at page 17, line 18 ¶		skipping to change at page 17, line 18 ¶
	For general NSH security considerations, see [RFC8300].		For general NSH security considerations, see [RFC8300].
	For security considerations concerning tampering with ECN signaling,		For security considerations concerning tampering with ECN signaling,
	see [RFC3168]. For security considerations concerning ECN		see [RFC3168]. For security considerations concerning ECN
	encapsulation, see [RFC6040].		encapsulation, see [RFC6040].
	For general IPFIX security considerations, see [RFC7011]. If deployed		For general IPFIX security considerations, see [RFC7011]. If deployed
	in an untrusted environment, the signaling traffic between ingress		in an untrusted environment, the signaling traffic between ingress
	and egress can be protected utilizing the security mechanisms		and egress can be protected utilizing the security mechanisms
	provided by IPFIX (see section 11 in RFC7011).		provided by IPFIX (see Section 11 in [RFC7011]).
	The solution in this document does not introduce any greater		The solution in this document does not introduce any greater
	potential to invade privacy than would have been possible without the		potential to invade privacy than would have been possible without the
	solution.		solution.
	7. Acknowledgements		7. Acknowledgements
	The authors wish to thank the following for their comments and		The authors wish to thank the following for their comments and
	suggestion:		suggestion:
	skipping to change at page 18, line 45 ¶		skipping to change at page 18, line 45 ¶
	editor.org/info/rfc7567>.		editor.org/info/rfc7567>.
	[RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
	2017, <http://www.rfc-editor.org/info/rfc8174>		2017, <http://www.rfc-editor.org/info/rfc8174>
	[RFC8300] - Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,		[RFC8300] - Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
	"Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300,		"Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300,
	January 2018, <https://www.rfc-editor.org/info/rfc8300>.		January 2018, <https://www.rfc-editor.org/info/rfc8300>.
	[TunnelCongFeedback] - Wei, X., Zhu, L., and L. Deng, "Tunnel		[TunnelCongFeedback] - Wei, X., Li, Y., Boutros, S., and L. Deng,
	Congestion Feedback", draft-ietf-tsvwg-tunnel-congestion-		"Tunnel Congestion Feedback", draft-ietf-tsvwg-tunnel-
	feedback, work in progress.		congestion-feedback, work in progress.
	INTERNET-DRAFT NSH ECN & Congestion Feedback		INTERNET-DRAFT NSH ECN & Congestion Feedback
	Informative References		Informative References
	[RFC4301] - Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] - Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December		Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December
	2005, <https://www.rfc-editor.org/info/rfc4301>.		2005, <https://www.rfc-editor.org/info/rfc4301>.
	[RFC4960] - Stewart, R., Ed., "Stream Control Transmission Protocol",		[RFC4960] - Stewart, R., Ed., "Stream Control Transmission Protocol",
	skipping to change at page 20, line 10 ¶		skipping to change at page 20, line 10 ¶
	[ecnL4S] - De Schepper, K., and B. Briscoe, "Identifying Modified		[ecnL4S] - De Schepper, K., and B. Briscoe, "Identifying Modified
	Explicit Congestion Notification (ECN) Semantics for Ultra-Low		Explicit Congestion Notification (ECN) Semantics for Ultra-Low
	Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s-id, work in		Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s-id, work in
	progress.		progress.
	INTERNET-DRAFT NSH ECN & Congestion Feedback		INTERNET-DRAFT NSH ECN & Congestion Feedback
	Authors' Addresses		Authors' Addresses
	Donald E. Eastlake, 3rd		Donald E. Eastlake, 3rd
	Huawei Technologies		Futurewei Technologies
	1424 Pro Shop Court		1424 Pro Shop Court
	Davenport, FL 33896 USA		Davenport, FL 33896 USA
	Tel: +1-508-333-2270		Tel: +1-508-333-2270
	Email: d3e3e3@gmail.com		Email: d3e3e3@gmail.com
	Bob Briscoe		Bob Briscoe
	Independent		Independent
	UK		UK
	Email: ietf@bobbriscoe.net		Email: ietf@bobbriscoe.net
	URI: http://bobbriscoe.net/		URI: http://bobbriscoe.net/
	Andrew G. Malis		Andrew G. Malis
	Huawei Technologies		Futurewei Technologies
	Email: agmalis@gmail.com		Email: agmalis@gmail.com
	INTERNET-DRAFT NSH ECN & Congestion Feedback		INTERNET-DRAFT NSH ECN & Congestion Feedback
	Copyright and IPR Provisions		Copyright and IPR Provisions
	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.
End of changes. 13 change blocks.
	19 lines changed or deleted		19 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/