< draft-ietf-pim-ecmp-04.txt		draft-ietf-pim-ecmp-05.txt >
	Network Working Group Yiqun Cai		Network Working Group Yiqun Cai
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track Liming Wei		Intended status: Standards Track Liming Wei
	Expires: December 30, 2012 Heidi Ou		Expires: February 1, 2013 Heidi Ou
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Vishal Arya		Vishal Arya
	Sunil Jethwani		Sunil Jethwani
	DIRECTV Inc.		DIRECTV Inc.
	June 28, 2012		July 31, 2012
	Protocol Independent Multicast ECMP Redirect		Protocol Independent Multicast ECMP Redirect
	draft-ietf-pim-ecmp-04.txt		draft-ietf-pim-ecmp-05.txt
	Abstract		Abstract
	A Protocol Independent Multicast (PIM) router uses the Reverse Path		A Protocol Independent Multicast (PIM) router uses the Reverse Path
	Forwarding (RPF) procedure to select an upstream interface and router		Forwarding (RPF) procedure to select an upstream interface and router
	to build forwarding state. When there are equal cost multiple paths		to build forwarding state. When there are equal cost multiple paths
	(ECMP), existing implementations often use hash algorithms to select		(ECMP), existing implementations often use hash algorithms to select
	a path. Such algorithms do not allow the spread of traffic among the		a path. Such algorithms do not allow the spread of traffic among the
	ECMPs according to administrative metrics. This usually leads to		ECMPs according to administrative metrics. This usually leads to
	inefficient or ineffective use of network resources. This document		inefficient or ineffective use of network resources. This document
	skipping to change at page 1, line 45		skipping to change at page 1, line 45
	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 December 30, 2012.		This Internet-Draft will expire on February 1, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 5		4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6		5. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6
	3.1. Sending ECMP Redirect . . . . . . . . . . . . . . . . . . 6		5.1. Sending ECMP Redirect . . . . . . . . . . . . . . . . . . 6
	3.2. Receiving ECMP Redirect . . . . . . . . . . . . . . . . . 7		5.2. Receiving ECMP Redirect . . . . . . . . . . . . . . . . . 7
	3.3. Transient State . . . . . . . . . . . . . . . . . . . . . 7		5.3. Transient State . . . . . . . . . . . . . . . . . . . . . 7
	3.4. Interoperability . . . . . . . . . . . . . . . . . . . . . 8		5.4. Interoperability . . . . . . . . . . . . . . . . . . . . . 8
	3.5. Packet Format . . . . . . . . . . . . . . . . . . . . . . 8		5.5. Packet Format . . . . . . . . . . . . . . . . . . . . . . 8
	3.5.1. PIM ECMP Redirect Hello Option . . . . . . . . . . . . 8		5.5.1. PIM ECMP Redirect Hello Option . . . . . . . . . . . . 8
	3.5.2. PIM ECMP Redirect Format . . . . . . . . . . . . . . . 9		5.5.2. PIM ECMP Redirect Format . . . . . . . . . . . . . . . 9
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10		8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 10		9.1. Normative Reference . . . . . . . . . . . . . . . . . . . 10
	7.2. Informative References . . . . . . . . . . . . . . . . . . 11		9.2. Informative References . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Terminology		1. Introduction
			A PIM router uses the RPF procedure to select an upstream interface
			and a PIM neighbor on that interface to build forwarding state. When
			there are equal cost multiple paths (ECMP) upstream, existing
			implementations often use hash algorithms to select a path. Such
			algorithms do not allow the spread of traffic among the ECMP
			according to administrative metrics. This usually leads to
			inefficient or ineffective use of network resources. This document
			introduces the ECMP Redirect, a mechanism to improve the RPF
			procedure over ECMP. It allows ECMP path selection to be based on
			administratively selected metrics, such as data transmission delays,
			path preferences and routing metrics, or a combination of metrics.
			ECMPs are frequently used in networks to provide redundancy and to
			increase available bandwidth. A PIM router selects a path in the
			ECMP based on its own implementation specific choice. The selection
			is a local decision. One way is to choose the PIM neighbor with the
			highest IP address, another is to pick the PIM neighbor with the best
			hash value over the destination and source addresses.
			While implementations supporting ECMP have been deployed widely, the
			existing RPF selection methods have weaknesses. The lack of
			administratively effective ways to allocate traffic over alternative
			paths is a major issue. For example, there is no straightforward way
			to tell two downstream routers to select either the same or different
			RPF neighbor routers for the same traffic flows.
			With the ECMP Redirect mechanism introduced here, the upstream
			routers use a PIM ECMP Redirect message to instruct the downstream
			routers on how to tie-break among the upstream neighbors. The PIM
			ECMP Redirect message conveys the tie-break information based on
			metrics selected administratively.
			2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	This document uses terms defined in [RFC4601] to describe actions		This document uses terms defined in [RFC4601] to describe actions
	taken by PIM routers.		taken by PIM routers.
	The following terms have special significance for ECMP Redirect:		The following terms have special significance for ECMP Redirect:
	skipping to change at page 3, line 43		skipping to change at page 4, line 32
	potentially capable of forwarding data packets onto interfaces in		potentially capable of forwarding data packets onto interfaces in
	an ECMP bundle.		an ECMP bundle.
	When there are multiple routers forwarding packets onto interfaces		When there are multiple routers forwarding packets onto interfaces
	in the ECMP bundle, all these routers are called upstream routers.		in the ECMP bundle, all these routers are called upstream routers.
	o Downstream. Away from the root of the multicast forwarding tree.		o Downstream. Away from the root of the multicast forwarding tree.
	A downstream router is a router that uses an interface in the ECMP		A downstream router is a router that uses an interface in the ECMP
	bundle as an RPF interface for a multicast forwarding entry.		bundle as an RPF interface for a multicast forwarding entry.
	2. Introduction		3. Overview
	A PIM router uses the RPF procedure to select an upstream interface
	and a PIM neighbor on that interface to build forwarding state. When
	there are equal cost multiple paths (ECMP) upstream, existing
	implementations often use hash algorithms to select a path. Such
	algorithms do not allow the spread of traffic among the ECMP
	according to administrative metrics. This usually leads to
	inefficient or ineffective use of network resources. This document
	introduces the ECMP Redirect, a mechanism to improve the RPF
	procedure over ECMP. It allows ECMP path selection to be based on
	administratively selected metrics, such as data transmission delays,
	path preferences and routing metrics, or a combination of metrics.
	ECMPs are frequently used in networks to provide redundancy and to
	increase available bandwidth. A PIM router selects a path in the
	ECMP based on its own implementation specific choice. The selection
	is a local decision. One way is to choose the PIM neighbor with the
	highest IP address, another is to pick the PIM neighbor with the best
	hash value over the destination and source addresses.
	While implementations supporting ECMP have been deployed widely, the
	existing RPF selection methods have weaknesses. The lack of
	administratively effective ways to allocate traffic over alternative
	paths is a major issue. For example, there is no straightforward way
	to tell two downstream routers to select either the same or different
	RPF neighbor routers for the same traffic flows.
	With the ECMP Redirect mechanism introduced here, the upstream
	routers use a PIM ECMP Redirect message to instruct the downstream
	routers on how to tie-break among the upstream neighbors. The PIM
	ECMP Redirect message conveys the tie-break information based on
	metrics selected administratively.
	2.1. Overview
	The existing PIM Assert mechanism allows the upstream router to		The existing PIM Assert mechanism allows the upstream router to
	detect the existence of multiple forwarders for the same multicast		detect the existence of multiple forwarders for the same multicast
	flow onto the same downstream interface. The upstream router sends a		flow onto the same downstream interface. The upstream router sends a
	PIM Assert message containing a routing metric for the downstream		PIM Assert message containing a routing metric for the downstream
	routers to use for tie-breaking among the multiple upstream		routers to use for tie-breaking among the multiple upstream
	forwarders on the same RPF interface.		forwarders on the same RPF interface.
	With ECMP interfaces between the downstream and upstream routers, the		With ECMP interfaces between the downstream and upstream routers, the
	PIM ECMP Redirect mechanism works in a similar way, but extends the		PIM ECMP Redirect mechanism works in a similar way, but extends the
	skipping to change at page 5, line 29		skipping to change at page 5, line 32
	However, the existing Assert message is used to select an upstream		However, the existing Assert message is used to select an upstream
	router within the same multi-access network (such as a LAN) while the		router within the same multi-access network (such as a LAN) while the
	Redirect message is used to select both a network and an upstream		Redirect message is used to select both a network and an upstream
	router.		router.
	One advantage of this design is that the control messages are only		One advantage of this design is that the control messages are only
	sent when there is need to "re-balance" the traffic. This reduces		sent when there is need to "re-balance" the traffic. This reduces
	the amount of control traffic.		the amount of control traffic.
	2.2. Applicability		4. Applicability
	The use of ECMP Redirect applies to shared trees or source trees		The use of ECMP Redirect applies to shared trees or source trees
	built with procedures described in [RFC4601]. The use of ECMP		built with procedures described in [RFC4601]. The use of ECMP
	Redirect in "Protocol Independent Multicast - Dense Mode" [RFC3973]		Redirect in "Protocol Independent Multicast - Dense Mode" [RFC3973]
	or in "Bidirectional Protocol Independent Multicast" [RFC5015] is not		or in "Bidirectional Protocol Independent Multicast" [RFC5015] is not
	considered in this document.		considered in this document.
	The enhancement described in this document can be applicable to a		The enhancement described in this document can be applicable to a
	number of scenarios. For example, it allows a network operator to		number of scenarios. For example, it allows a network operator to
	use ECMP paths and have the ability to perform load splitting based		use ECMP paths and have the ability to perform load splitting based
	skipping to change at page 6, line 5		skipping to change at page 6, line 8
	The ECMP Redirect mechanism assures that all downstream routers		The ECMP Redirect mechanism assures that all downstream routers
	select the desired network link and upstream router whenever		select the desired network link and upstream router whenever
	possible. Another example is for a network operator to impose a		possible. Another example is for a network operator to impose a
	transmission delay limit on certain links. The ECMP Redirect		transmission delay limit on certain links. The ECMP Redirect
	mechanism provides a means for an upstream router to instruct a		mechanism provides a means for an upstream router to instruct a
	downstream router to choose a different RPF path.		downstream router to choose a different RPF path.
	This specification does not dictate the scope of applications of this		This specification does not dictate the scope of applications of this
	mechanism.		mechanism.
	3. Protocol Specification		5. Protocol Specification
	3.1. Sending ECMP Redirect		5.1. Sending ECMP Redirect
	ECMP Redirects are sent by an upstream router in a rate limited		ECMP Redirects are sent by an upstream router in a rate limited
	fashion, under the following conditions,		fashion, under the following conditions,
	o It detects a PIM Join on a non-desired outgoing interface; or		o It detects a PIM Join on a non-desired outgoing interface; or
	o It detects multicast traffic on a non-desired outgoing interface.		o It detects multicast traffic on a non-desired outgoing interface.
	In both cases, an ECMP Redirect is sent to the non-desired interface.		In both cases, an ECMP Redirect is sent to the non-desired interface.
	An outgoing interface is considered "non-desired" when,		An outgoing interface is considered "non-desired" when,
	skipping to change at page 7, line 5		skipping to change at page 7, line 6
	addresses are in use. For other IPv4 usage, this field is zero'ed		addresses are in use. For other IPv4 usage, this field is zero'ed
	when sent, and ignored when received. If the "Router ID" part of the		when sent, and ignored when received. If the "Router ID" part of the
	Interface ID is zero, the field MUST be ignored. See [RFC6395] for		Interface ID is zero, the field MUST be ignored. See [RFC6395] for
	details of its assignment and usage in PIM Hellos. If the Interface		details of its assignment and usage in PIM Hellos. If the Interface
	ID is not ignored, the receiving router of this message MUST use the		ID is not ignored, the receiving router of this message MUST use the
	Interface ID, instead of Neighbor Address, to identify the new RPF		Interface ID, instead of Neighbor Address, to identify the new RPF
	neighbor, and an ECMP Redirect message MUST be discarded if the		neighbor, and an ECMP Redirect message MUST be discarded if the
	Interface ID field in the message does not match the cached interface		Interface ID field in the message does not match the cached interface
	ID.		ID.
	3.2. Receiving ECMP Redirect		5.2. Receiving ECMP Redirect
	When a downstream router receives an ECMP Redirect, and detects that		When a downstream router receives an ECMP Redirect, and detects that
	the desired RPF path from its upstream router's point of view is		the desired RPF path from its upstream router's point of view is
	different from its current one, it should choose to join the newly		different from its current one, it should choose to join the newly
	suggested path and prune from the current path. The exact order of		suggested path and prune from the current path. The exact order of
	such actions is implementation specific.		such actions is implementation specific.
	If a downstream router receives multiple ECMP Redirects sent by		If a downstream router receives multiple ECMP Redirects sent by
	different upstream routers, it SHOULD use the Preference, Metric, or		different upstream routers, it SHOULD use the Preference, Metric, or
	other fields as specified below, as the tie breakers to choose the		other fields as specified below, as the tie breakers to choose the
	most preferred RPF interface and neighbor.		most preferred RPF interface and neighbor. The tie break procedure
			is the same as that used in PIM Assert processing described by
			[RFC4601].
	If an upstream router receives an ECMP Redirect, it SHOULD NOT change		If an upstream router receives an ECMP Redirect, it SHOULD NOT change
	its forwarding behavior even if the ECMP Redirect makes it a less		its forwarding behavior even if the ECMP Redirect makes it a less
	preferred RPF neighbor on the receiving interface.		preferred RPF neighbor on the receiving interface.
	3.3. Transient State		5.3. Transient State
	During a transient network outage with a single link cut in an ECMP		During a transient network outage with a single link cut in an ECMP
	bundle, a downstream router may lose connection to its RPF neighbor		bundle, a downstream router may lose connection to its RPF neighbor
	and the normal ECMP Redirect operation may be interrupted		and the normal ECMP Redirect operation may be interrupted
	temporarily. In such an event, the following actions are		temporarily. In such an event, the following actions are
	RECOMMENDED.		RECOMMENDED.
	The downstream router SHOULD select a new RPF neighbor. Among all		The downstream router SHOULD select a new RPF neighbor. Among all
	ECMP upstream routers, the one on the LAN the previous RPF neighbor		ECMP upstream routers, the one on the LAN the previous RPF neighbor
	resided on is preferred.		resided on is preferred.
	skipping to change at page 8, line 5		skipping to change at page 8, line 6
	During normal ECMP Redirect operations, when PIM Joins for the same		During normal ECMP Redirect operations, when PIM Joins for the same
	(*,G) or (S,G) are received on a different LAN, an upstream router		(*,G) or (S,G) are received on a different LAN, an upstream router
	will send ECMP Redirect to prune the non-preferred LAN. Such ECMP		will send ECMP Redirect to prune the non-preferred LAN. Such ECMP
	Redirects during partial network outage can be suppressed if the		Redirects during partial network outage can be suppressed if the
	upstream router decides that the non-preferred PIM Join is from a		upstream router decides that the non-preferred PIM Join is from a
	router that is not reachable via the preferred LAN. This check can		router that is not reachable via the preferred LAN. This check can
	be performed by retrieving the downstream's Router ID, using the		be performed by retrieving the downstream's Router ID, using the
	source address in the PIM Join, and searching neighbors on the		source address in the PIM Join, and searching neighbors on the
	preferred LAN for one with the same router ID.		preferred LAN for one with the same router ID.
	3.4. Interoperability		5.4. Interoperability
	If a PIM router supports this specification, it MUST send the Hello		If a PIM router supports this specification, it MUST send the Hello
	option ECMP-Redirect-Supported TLV in its PIM Hello messages.		option ECMP-Redirect-Supported TLV in its PIM Hello messages.
	A PIM router sends ECMP Redirects on an interface only when it		A PIM router sends ECMP Redirects on an interface only when it
	detects that all neighbors on that interface have sent this Hello		detects that all neighbors on that interface have sent this Hello
	option. If a PIM router detects that any of its neighbors on an ECMP		option. If a PIM router detects that any of its neighbors on an ECMP
	bundle does not support this Hello option, it SHOULD NOT send ECMP		bundle does not support this Hello option, it SHOULD NOT send ECMP
	Redirects to any interface in that bundle, however, it SHOULD still		Redirects to any interface in that bundle, however, it SHOULD still
	process any ECMP Redirects received from any interface in the same		process any ECMP Redirects received from any interface in the same
	bundle.		bundle.
	If a PIM router does not support this specification, it will ignore		If a PIM router does not support this specification, it will ignore
	the ECMP-Redirect-Supported TLV in Hello and ECMP Redirects in PIM		the ECMP-Redirect-Supported TLV in Hello and ECMP Redirects in PIM
	packets, which it receives.		packets, which it receives.
	3.5. Packet Format		5.5. Packet Format
	3.5.1. PIM ECMP Redirect Hello Option		5.5.1. PIM ECMP Redirect Hello Option
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = 32 | Length = 0 |		| Type = 32 | Length = 0 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: ECMP Redirect Hello Option		Figure 1: ECMP Redirect Hello Option
	Type: 32, temporarily assigned by IANA		Type: 32, temporarily assigned by IANA
	Length: 0		Length: 0
	3.5.2. PIM ECMP Redirect Format		5.5.2. PIM ECMP Redirect Format
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|PIM Ver| Type | Reserved | Checksum |		|PIM Ver| Type | Reserved | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group Address (Encoded-Group format) |		| Group Address (Encoded-Group format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source Address (Encoded-Unicast format) |		| Source Address (Encoded-Unicast format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 10, line 13		skipping to change at page 10, line 13
	started to forward out of this interface.		started to forward out of this interface.
	Metric (64 bits): The second tie breaker if the "Preference" values		Metric (64 bits): The second tie breaker if the "Preference" values
	are the same. Numerically smaller metric is preferred. This		are the same. Numerically smaller metric is preferred. This
	"Metric" can contain path parameters defined by users. When both		"Metric" can contain path parameters defined by users. When both
	"Preference" and "Metric" values are the same, "Neighbor Address"		"Preference" and "Metric" values are the same, "Neighbor Address"
	or "Interface ID" field is used as the third tie-breaker,		or "Interface ID" field is used as the third tie-breaker,
	depending on which field is used to identify the RPF neighbor, and		depending on which field is used to identify the RPF neighbor, and
	the bigger value wins.		the bigger value wins.
	4. IANA Considerations		6. IANA Considerations
	A PIM Hello Option Type is requested to be assigned to the PIM ECMP		A PIM Hello Option Type is requested to be assigned to the PIM ECMP
	Redirect Hello Option. According to [HELLO-OPT], 32 (0x20) has been		Redirect Hello Option. According to [HELLO-OPT], 32 (0x20) has been
	temporarily assigned by IANA to the "PIM ECMP Redirect Hello Option		temporarily assigned by IANA to the "PIM ECMP Redirect Hello Option
	Type".		Type".
	A PIM Message Type (TBD) is requested to be assigned to the ECMP		A PIM Message Type (TBD) is requested to be assigned to the ECMP
	Redirect message. According to [RFC6166], the next available Type		Redirect message. According to [RFC6166], the next available Type
	value is 11 (0xB).		value is 11 (0xB).
	5. Security Considerations		7. Security Considerations
	Security of the ECMP Redirect is only guaranteed by the security of		Security of the ECMP Redirect is only guaranteed by the security of
	the PIM packet, the security considerations for PIM Assert packets as		the PIM packet, the security considerations for PIM Assert packets as
	described in [RFC4601] apply here. Spoofed ECMP Redirect packets may		described in [RFC4601] apply here. Spoofed ECMP Redirect packets may
	cause the downstream routers to send PIM Joins to an undesired		cause the downstream routers to send PIM Joins to an undesired
	upstream router, and trigger more ECMP Redirect messages. Security		upstream router, and trigger more ECMP Redirect messages. Security
	considerations for PIM packets described in [RFC4601] also apply to		considerations for PIM packets described in [RFC4601] also apply to
	the new hello option defined here.		the new hello option defined here.
	6. Acknowledgement		8. Acknowledgement
	The authors would like to thank Apoorva Karan for helping with the		The authors would like to thank Apoorva Karan for helping with the
	original idea, Eric Rosen, Isidor Kouvelas, Toerless Eckert, Stig		original idea, Eric Rosen, Isidor Kouvelas, Toerless Eckert, Stig
	Venaas, Jeffrey Zhang, Bill Atwood and Adrian Farrel for their review		Venaas, Jeffrey Zhang, Bill Atwood and Adrian Farrel for their review
	comments.		comments.
	7. References		9. References
	7.1. Normative Reference		9.1. Normative Reference
	[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.
	[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,		[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
	"Protocol Independent Multicast - Sparse Mode (PIM-SM):		"Protocol Independent Multicast - Sparse Mode (PIM-SM):
	Protocol Specification (Revised)", RFC 4601, August 2006.		Protocol Specification (Revised)", RFC 4601, August 2006.
	7.2. Informative References		9.2. Informative References
	[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol		[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
	Independent Multicast - Dense Mode (PIM-DM): Protocol		Independent Multicast - Dense Mode (PIM-DM): Protocol
	Specification (Revised)", RFC 3973, January 2005.		Specification (Revised)", RFC 3973, January 2005.
	[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,		[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
	"Bidirectional Protocol Independent Multicast (BIDIR-		"Bidirectional Protocol Independent Multicast (BIDIR-
	PIM)", RFC 5015, October 2007.		PIM)", RFC 5015, October 2007.
	[RFC6166] Venaas, S., "A Registry for PIM Message Types", RFC 6166,		[RFC6166] Venaas, S., "A Registry for PIM Message Types", RFC 6166,
	skipping to change at page 11, line 36		skipping to change at page 11, line 36
	[HELLO-OPT]		[HELLO-OPT]
	IANA, "PIM Hello Options", PIM-HELLO-OPTIONS per [RFC4601]		IANA, "PIM Hello Options", PIM-HELLO-OPTIONS per [RFC4601]
	http://www.iana.org/assignments/pim-hello-options,		http://www.iana.org/assignments/pim-hello-options,
	October 2011.		October 2011.
	Authors' Addresses		Authors' Addresses
	Yiqun Cai		Yiqun Cai
	Microsoft		Microsoft
	La Avenida		1065 La Avenida
	Mountain View, CA 94043		Mountain View, CA 94043
	USA		USA
	Email: yiqunc@microsoft.com		Email: yiqunc@microsoft.com
	Liming Wei		Liming Wei
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Tasman Drive		Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
End of changes. 24 change blocks.
	75 lines changed or deleted		77 lines changed or added
This html diff was produced by rfcdiff 1.39p1. The latest version is available from http://tools.ietf.org/tools/rfcdiff/