draft-ietf-6man-flow-ecmp-04.txt		draft-ietf-6man-flow-ecmp-05.txt
	Network Working Group B. Carpenter		Network Working Group B. Carpenter
	Internet-Draft Univ. of Auckland		Internet-Draft Univ. of Auckland
	Intended status: BCP S. Amante		Intended status: Standards Track S. Amante
	Expires: January 6, 2012 Level 3		Expires: January 20, 2012 Level 3
	July 5, 2011		July 19, 2011
	Using the IPv6 flow label for equal cost multipath routing and link		Using the IPv6 flow label for equal cost multipath routing and link
	aggregation in tunnels		aggregation in tunnels
	draft-ietf-6man-flow-ecmp-04		draft-ietf-6man-flow-ecmp-05
	Abstract		Abstract
	The IPv6 flow label has certain restrictions on its use. This		The IPv6 flow label has certain restrictions on its use. This
	document describes how those restrictions apply when using the flow		document describes how those restrictions apply when using the flow
	label for load balancing by equal cost multipath routing, and for		label for load balancing by equal cost multipath routing, and for
	link aggregation, particularly for IP-in-IPv6 tunneled traffic.		link aggregation, particularly for IP-in-IPv6 tunneled traffic.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 January 6, 2012.		This Internet-Draft will expire on January 20, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Choice of IP Header Fields for Hash Input . . . . . . . . . 3		1.1. Choice of IP Header Fields for Hash Input . . . . . . . . 3
	1.2. Flow label rules . . . . . . . . . . . . . . . . . . . . . 5		1.2. Flow label rules . . . . . . . . . . . . . . . . . . . . . 5
	2. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 6		2. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 6
	3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7		4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
	7. Change log [RFC Editor: please remove] . . . . . . . . . . . . 8		7. Change log [RFC Editor: please remove] . . . . . . . . . . . . 8
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 9		8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	8.2. Informative References . . . . . . . . . . . . . . . . . . 9		8.2. Informative References . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	When several network paths between the same two nodes are known by		When several network paths between the same two nodes are known by
	the routing system to be equally good (in terms of capacity and		the routing system to be equally good (in terms of capacity and
	latency), it may be desirable to share traffic among them. Two such		latency), it may be desirable to share traffic among them. Two such
	techniques are known as equal cost multipath routing (ECMP) and link		techniques are known as equal cost multipath routing (ECMP) and link
	aggregation (LAG) [IEEE802.1AX]. There are of course numerous		aggregation (LAG) [IEEE802.1AX]. There are of course numerous
	possible approaches to this, but certain goals need to be met:		possible approaches to this, but certain goals need to be met:
	o Roughly equal share of traffic on each path.		o Roughly equal share of traffic on each path.
	skipping to change at page 4, line 47		skipping to change at page 4, line 47
	Identifying a flow inside the tunnel is more complicated,		Identifying a flow inside the tunnel is more complicated,
	particularly because nearly all hardware can only identify flows		particularly because nearly all hardware can only identify flows
	based on information contained in the outermost IP header. Assume		based on information contained in the outermost IP header. Assume
	that traffic from many sources to many destinations is aggregated in		that traffic from many sources to many destinations is aggregated in
	a single IP-in-IP tunnel from tunnel end point (TEP) A to TEP B (see		a single IP-in-IP tunnel from tunnel end point (TEP) A to TEP B (see
	figure). Then all the packets forming the tunnel have outer source		figure). Then all the packets forming the tunnel have outer source
	address A and outer destination address B. In all probability they		address A and outer destination address B. In all probability they
	also have the same port and protocol numbers. If there are multiple		also have the same port and protocol numbers. If there are multiple
	paths between routers R1 and R2, and ECMP or LAG is applied to choose		paths between routers R1 and R2, and ECMP or LAG is applied to choose
	a particular path, the 2-tuple or 5-tuple, and its hash, will be		a particular path, the 2-tuple or 5-tuple, and its hash, will be
	constant and no load sharing will be achieved. If there is a high		constant and no load sharing will be achieved, i.e., polarization
	proportion of traffic from one or small number of tunnels, traffic		will occur. If there is a high proportion of traffic from one or
	will not be distributed as intended across the paths between R1 and		small number of tunnels, traffic will not be distributed as intended
	R2.		across the paths between R1 and R2, due to partial polarization.
			(Related issues arise with MPLS [I-D.ietf-mpls-entropy-label].)
	_____ _____ _____ _____		_____ _____ _____ _____
	| TEP |_________| R1 |-------------| R2 |_________| TEP |		| TEP |_________| R1 |-------------| R2 |_________| TEP |
	|__A__| |_____|-------------|_____| |__B__|		|__A__| |_____|-------------|_____| |__B__|
	tunnel ECMP or LAG tunnel		tunnel ECMP or LAG tunnel
	here		here
	As noted above, for IPv6, the 5-tuple is in any case quite		As noted above, for IPv6, the 5-tuple is in any case quite
	inconvenient to extract due to the next-header placement. The		inconvenient to extract due to the next-header placement. The
	question therefore arises whether the 20-bit flow label in IPv6		question therefore arises whether the 20-bit flow label in IPv6
	packets would be suitable for use as input to an ECMP or LAG hash		packets would be suitable for use as input to an ECMP or LAG hash
	skipping to change at page 7, line 35		skipping to change at page 7, line 35
	{dest addr, source addr, flow label} and MAY also include the		{dest addr, source addr, flow label} and MAY also include the
	remaining components of the 5-tuple. This applies whether the		remaining components of the 5-tuple. This applies whether the
	traffic is tunneled traffic only, or a mixture of normal traffic		traffic is tunneled traffic only, or a mixture of normal traffic
	and tunneled traffic.		and tunneled traffic.
	* Intermediate IPv6 router(s) will presumably encounter a mixture		* Intermediate IPv6 router(s) will presumably encounter a mixture
	of tunneled traffic and normal IPv6 traffic. Because of this,		of tunneled traffic and normal IPv6 traffic. Because of this,
	the design should also include {protocol, dest port, source		the design should also include {protocol, dest port, source
	port} as input keys to the ECMP and/or LAG hash algorithms, to		port} as input keys to the ECMP and/or LAG hash algorithms, to
	provide additional entropy for flows whose flow label is set to		provide additional entropy for flows whose flow label is set to
	zero, including non-tunneled traffic flows.		zero, including non-tunneled traffic flows.
			o Individual nodes in a network are free to implement different
			algorithms that conform to this specification, without impacting
			the interoperability or function of the network.
			o OAM techniques will need to be adapted to manage ECMP and LAG
			based on the flow label. The issues will be similar to those that
			arise for MPLS [RFC4379] and pseudowires [I-D.ietf-pwe3-fat-pw].
	4. Security Considerations		4. Security Considerations
	The flow label is not protected in any way and can be forged by an		The flow label is not protected in any way and can be forged by an
	on-path attacker. However, it is expected that tunnel end-points and		on-path attacker. However, it is expected that tunnel end-points and
	the ECMP or LAG paths will be part of managed infrastructure that is		the ECMP or LAG paths will be part of managed infrastructure that is
	well protected against on-path attacks. Off-path attackers are		well protected against on-path attacks (e.g., by using IPsec between
	unlikely to guess a valid flow label if an apparently pseudo-random		the two tunnel end-points). Off-path attackers are unlikely to guess
	and unpredictable value is used. In either case, the worst an		a valid flow label if an apparently pseudo-random and unpredictable
	attacker could do against ECMP or LAG is to attempt to selectively		value is used. In either case, the worst an attacker could do
	overload a particular path. For further discussion, see		against ECMP or LAG is to attempt to selectively overload a
			particular path. For further discussion, see
	[I-D.ietf-6man-flow-3697bis].		[I-D.ietf-6man-flow-3697bis].
	5. IANA Considerations		5. IANA Considerations
	This document requests no action by IANA.		This document requests no action by IANA.
	6. Acknowledgements		6. Acknowledgements
	This document was suggested by corridor discussions at IETF76. Joel		This document was suggested by corridor discussions at IETF76. Joel
	Halpern made crucial comments on an early version. We are grateful		Halpern made crucial comments on an early version. We are grateful
	to Qinwen Hu for general discussion about the flow label. Valuable		to Qinwen Hu for general discussion about the flow label. Valuable
	comments and contributions were made by Miguel Garcia, Brian		comments and contributions were made by Miguel Garcia, Brian
	Haberman, Sheng Jiang, Thomas Narten, Jarno Rajahalme, Brian Weis,		Haberman, Sheng Jiang, Thomas Narten, Jarno Rajahalme, Brian Weis,
	and others.		and others.
	This document was produced using the xml2rfc tool [RFC2629].		This document was produced using the xml2rfc tool [RFC2629].
	7. Change log [RFC Editor: please remove]		7. Change log [RFC Editor: please remove]
	draft-ietf-6man-flow-ecmp-04: IETF Last Call comments, 2011-06-20.		draft-ietf-6man-flow-ecmp-05: IESG comments, 2011-07-19.
			draft-ietf-6man-flow-ecmp-04: IETF Last Call comments, 2011-07-05.
	draft-ietf-6man-flow-ecmp-03: minor editorial fixes, AD comments,		draft-ietf-6man-flow-ecmp-03: minor editorial fixes, AD comments,
	2011-06-20.		2011-06-20.
	draft-ietf-6man-flow-ecmp-02: updated after further comments, 2011-		draft-ietf-6man-flow-ecmp-02: updated after further comments, 2011-
	05-02. Note that RFC3697bis becomes a normative reference.		05-02. Note that RFC3697bis becomes a normative reference.
	draft-ietf-6man-flow-ecmp-01: updated after WG Last Call, 2011-02-10		draft-ietf-6man-flow-ecmp-01: updated after WG Last Call, 2011-02-10
	draft-ietf-6man-flow-ecmp-00: after WG adoption at IETF 79,		draft-ietf-6man-flow-ecmp-00: after WG adoption at IETF 79,
	skipping to change at page 8, line 43		skipping to change at page 9, line 4
	2010-12-02		2010-12-02
	draft-carpenter-flow-ecmp-03: clarifications after further comments,		draft-carpenter-flow-ecmp-03: clarifications after further comments,
	2010-10-07		2010-10-07
	draft-carpenter-flow-ecmp-02: updated after IETF77 discussion,		draft-carpenter-flow-ecmp-02: updated after IETF77 discussion,
	especially adding LAG, changed to BCP language, added second author,		especially adding LAG, changed to BCP language, added second author,
	2010-04-14		2010-04-14
	draft-carpenter-flow-ecmp-01: updated after comments, 2010-02-18		draft-carpenter-flow-ecmp-01: updated after comments, 2010-02-18
	draft-carpenter-flow-ecmp-00: original version, 2010-01-19		draft-carpenter-flow-ecmp-00: original version, 2010-01-19
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-6man-flow-3697bis]		[I-D.ietf-6man-flow-3697bis]
	Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,		Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
	"IPv6 Flow Label Specification",		"IPv6 Flow Label Specification",
	draft-ietf-6man-flow-3697bis-05 (work in progress),		draft-ietf-6man-flow-3697bis-06 (work in progress),
	June 2011.		July 2011.
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, December 1998.		(IPv6) Specification", RFC 2460, December 1998.
	[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,		[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
	"IPv6 Flow Label Specification", RFC 3697, March 2004.		"IPv6 Flow Label Specification", RFC 3697, March 2004.
	8.2. Informative References		8.2. Informative References
			[I-D.ietf-mpls-entropy-label]
			Kompella, K., Drake, J., Amante, S., Henderickx, W., and
			L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
			draft-ietf-mpls-entropy-label-00 (work in progress),
			May 2011.
			[I-D.ietf-pwe3-fat-pw]
			Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
			J., and S. Amante, "Flow Aware Transport of Pseudowires
			over an MPLS Packet Switched Network",
			draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011.
	[IEEE802.1AX]		[IEEE802.1AX]
	Institute of Electrical and Electronics Engineers, "Link		Institute of Electrical and Electronics Engineers, "Link
	Aggregation", IEEE Standard 802.1AX-2008, 2008.		Aggregation", IEEE Standard 802.1AX-2008, 2008.
	[Lee10] Lee, D., Carpenter, B., and N. Brownlee, "Observations of		[Lee10] Lee, D., Carpenter, B., and N. Brownlee, "Observations of
	UDP to TCP Ratio and Port Numbers", Fifth International		UDP to TCP Ratio and Port Numbers", Fifth International
	Conference on Internet Monitoring and Protection ICIMP		Conference on Internet Monitoring and Protection ICIMP
	2010, May 2010, <http://www.cs.auckland.ac.nz/~brian/		2010, May 2010, <http://www.cs.auckland.ac.nz/~brian/
	udptcp-paper-cam-submit.pdf>.		udptcp-paper-cam-submit.pdf>.
	skipping to change at page 10, line 5		skipping to change at page 10, line 17
	[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,		[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
	June 1999.		June 1999.
	[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.		[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
	Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,		Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
	March 2000.		March 2000.
	[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and		[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
	Multicast Next-Hop Selection", RFC 2991, November 2000.		Multicast Next-Hop Selection", RFC 2991, November 2000.
			[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
			Label Switched (MPLS) Data Plane Failures", RFC 4379,
			February 2006.
	Authors' Addresses		Authors' Addresses
	Brian Carpenter		Brian Carpenter
	Department of Computer Science		Department of Computer Science
	University of Auckland		University of Auckland
	PB 92019		PB 92019
	Auckland, 1142		Auckland, 1142
	New Zealand		New Zealand
	Email: brian.e.carpenter@gmail.com		Email: brian.e.carpenter@gmail.com
End of changes. 13 change blocks.
	32 lines changed or deleted		57 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/