draft-ietf-pim-ecmp-02.txt   draft-ietf-pim-ecmp-03.txt 
Network Working Group Yiqun Cai Network Working Group Yiqun Cai
Internet-Draft Liming Wei Internet-Draft Microsoft
Intended status: Standards Track Heidi Ou Intended status: Standards Track Liming Wei
Expires: August 6, 2012 Cisco Systems, Inc. Expires: October 29, 2012 Heidi Ou
Cisco Systems, Inc.
Vishal Arya Vishal Arya
Sunil Jethwani Sunil Jethwani
DIRECTV Inc. DIRECTV Inc.
February 3, 2012 April 27, 2012
Protocol Independent Multicast ECMP Redirect Protocol Independent Multicast ECMP Redirect
draft-ietf-pim-ecmp-02.txt draft-ietf-pim-ecmp-03.txt
Abstract Abstract
A PIM router uses the RPF procedure to select an upstream interface A Protocol Independent Multicast (PIM) [RFC4601] router uses the
and router to build forwarding state. When there are equal cost Reverse Path Forwarding (RPF) procedure to select an upstream
multiple paths (ECMP), existing implementations often use hash interface and router to build forwarding state. When there are equal
cost multiple paths (ECMP), existing implementations often use hash
algorithms to select a path. Such algorithms do not allow the spread algorithms to select a path. Such algorithms do not allow the spread
of traffic among the ECMPs according to administrative metrics. This of traffic among the ECMPs according to administrative metrics. This
usually leads to inefficient or ineffective use of network resources. usually leads to inefficient or ineffective use of network resources.
This document introduces the ECMP Redirect, a mechanism to improve This document introduces the ECMP Redirect, a mechanism to improve
the RPF procedure over ECMPs. It allows ECMP path selection to be the RPF procedure over ECMPs. It allows ECMP path selection to be
based on administratively selected metrics, such as data transmission based on administratively selected metrics, such as data transmission
delays, path preferences and routing metrics. delays, path preferences and routing metrics.
Status of this Memo Status of this Memo
skipping to change at page 1, line 43 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 August 6, 2012. This Internet-Draft will expire on October 29, 2012.
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. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6
3.1. ECMP Bundle . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Sending ECMP Redirect . . . . . . . . . . . . . . . . . . 6
3.2. Sending ECMP Redirect . . . . . . . . . . . . . . . . . . 5 3.2. Receiving ECMP Redirect . . . . . . . . . . . . . . . . . 6
3.3. Receiving ECMP Redirect . . . . . . . . . . . . . . . . . 6 3.3. Transient State . . . . . . . . . . . . . . . . . . . . . 6
3.4. Transient State . . . . . . . . . . . . . . . . . . . . . 6 3.4. Interoperability . . . . . . . . . . . . . . . . . . . . . 7
3.5. Interoperability . . . . . . . . . . . . . . . . . . . . . 7 3.5. Packet Format . . . . . . . . . . . . . . . . . . . . . . 7
3.6. Packet Format . . . . . . . . . . . . . . . . . . . . . . 7 3.5.1. PIM ECMP Redirect Hello Option . . . . . . . . . . . . 8
3.6.1. PIM ECMP Redirect Hello Option . . . . . . . . . . . . 7 3.5.2. PIM ECMP Redirect Format . . . . . . . . . . . . . . . 8
3.6.2. PIM ECMP Redirect Format . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 10 7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Requirements Notation 1. 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
taken by PIM routers.
The following terms have special significance for ECMP Redirect:
o Equal Cost Multiple Path (ECMP). In this document, the term ECMP
refers to parallel, single-hop, equal cost links between adjacent
nodes.
o ECMP Bundle. An ECMP bundle is a set of PIM enabled interfaces on
a router, where all interfaces belonging to the same bundle share
the same routing metric. The ECMP links reside between the
upstream and downstream routers over the ECMP bundle.
There can be one or more ECMP bundles on any router, while one
individual interface can only belong to a single bundle. ECMP
bundles are created on a router via configuration.
o RPF. RPF stands for Reverse Path Forwarding.
o Upstream. Towards the root of the multicast forwarding tree. An
upstream router refers to a router that is forwarding, or
potentially capable of forwarding data packets onto interfaces in
an ECMP bundle.
When there are multiple routers forwarding packets onto interfaces
in the ECMP bundle, all these routers are called upstream routers.
o Downstream. Away from the root of the multicast forwarding tree.
A downstream router is a router that uses an interface in the ECMP
bundle as an RPF interface for a multicast forwarding entry.
2. Introduction 2. Introduction
A PIM [RFC4601] router uses the RPF procedure to select an upstream A PIM router uses the RPF procedure to select an upstream interface
interface and a PIM neighbor on that interface to build forwarding and a PIM neighbor on that interface to build forwarding state. When
state. When there are equal cost multiple paths (ECMP) upstream, there are equal cost multiple paths (ECMP) upstream, existing
existing implementations often use hash algorithms to select a path. implementations often use hash algorithms to select a path. Such
Such algorithms do not allow the spread of traffic among the ECMP algorithms do not allow the spread of traffic among the ECMP
according to administrative metrics. This usually leads to 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
introduces the ECMP Redirect, a mechanism to improve the RPF introduces the ECMP Redirect, a mechanism to improve the RPF
procedure over ECMP. It allows ECMP path selection to be based on procedure over ECMP. It allows ECMP path selection to be based on
administratively selected metrics, such as data transmission delays, administratively selected metrics, such as data transmission delays,
path preferences and routing metrics, or a combination of metrics. path preferences and routing metrics, or a combination of metrics.
ECMPs are frequently used in networks to provide redundancy and to ECMPs are frequently used in networks to provide redundancy and to
increase available bandwidth. A PIM router selects a path in the increase available bandwidth. A PIM router selects a path in the
ECMP based on its own implementation specific choice. The selection ECMP based on its own implementation specific choice. The selection
skipping to change at page 4, line 26 skipping to change at page 5, line 10
When the RPF neighbor router receives the Join message and finds that When the RPF neighbor router receives the Join message and finds that
the receiving interface is one of the ECMP interfaces, it will check the receiving interface is one of the ECMP interfaces, it will check
if the same flow is already being forwarded out of another ECMP if the same flow is already being forwarded out of another ECMP
interface. If so, this RPF neighbor router will send a PIM ECMP interface. If so, this RPF neighbor router will send a PIM ECMP
Redirect message onto the interface the Join was received on. The Redirect message onto the interface the Join was received on. The
PIM ECMP Redirect message contains the address of the desired RPF PIM ECMP Redirect message contains the address of the desired RPF
neighbor, an interface ID [RFC6395], along with other parameters used neighbor, an interface ID [RFC6395], along with other parameters used
as tie breakers. In essence, a PIM ECMP Redirect message is sent by as tie breakers. In essence, a PIM ECMP Redirect message is sent by
an upstream router to notify downstream routers to redirect PIM Joins an upstream router to notify downstream routers to redirect PIM Joins
to the new RPF neighbor via a different interface. When the to the new RPF neighbor via a different interface. When the
downstream routers receive this message, they should trigger PIM downstream routers receive this message, they SHOULD trigger PIM
Joins toward the new RPF neighbor specified in the packet. Joins toward the new RPF neighbor specified in the packet.
This PIM ECMP Redirect message has similar functions as the existing This PIM ECMP Redirect message has similar functions as the existing
PIM Assert message, PIM Assert message,
1. It is sent by an upstream router; 1. It is sent by an upstream router;
2. It is used to influence the RPF selection by downstream routers; 2. It is used to influence the RPF selection by downstream routers;
And
3. A tie breaker metric is used. 3. A tie breaker metric is used.
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.
skipping to change at page 5, line 23 skipping to change at page 6, line 7
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 3. Protocol Specification
3.1. ECMP Bundle 3.1. Sending ECMP Redirect
An ECMP bundle is a set of PIM enabled interfaces on a router, where
all interfaces belonging to the same bundle share the same routing
metric. The ECMP paths reside between the upstream and downstream
routers over the ECMP bundle.
There can be one or more ECMP bundles on any router, while one
individual interface can only belong to a single bundle.
ECMP bundles are created on a router via configuration.
3.2. Sending ECMP Redirect
ECMP Redirects are sent by a preferred upstream router in a rate ECMP Redirects are sent by a preferred upstream router in a rate
limited fashion, under the following conditions, limited 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,
o The upstream router is already forwarding the same flow out of o The upstream router is already forwarding the same flow out of
another interface belonging to the same ECMP bundle; another interface belonging to the same ECMP bundle;
o The upstream router is not forwarding the flow yet out any o The upstream router is not forwarding the flow yet out any
interfaces of the ECMP bundle, but there is another interface with interfaces of the ECMP bundle, but there is another interface with
more desired attributes. more desired attributes.
An upstream router may choose not to send ECMP Redirects if it An upstream router MAY choose not to send ECMP Redirects if it
becomes aware that some of the downstream routers do not support the becomes aware that some of the downstream routers are unreachable via
message, or are unreachable via some links in ECMP bundle. some links in ECMP bundle.
3.3. Receiving ECMP Redirect 3.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 prune from the different from its current one, it SHOULD choose to prune from the
current path and join the new path. The exact order of such actions current path and join the new path. The exact order of such actions
is implementation specific. 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.
If an upstream router receives an ECMP Redirect from another upstream If an upstream router receives an ECMP Redirect, it SHOULD NOT change
router, it SHOULD NOT change its forwarding behavior even if the ECMP its forwarding behavior even if the ECMP Redirect makes it a less
Redirect makes it a less preferred RPF neighbor on the receiving preferred RPF neighbor on the receiving interface.
interface.
3.4. Transient State 3.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 down stream router may re-select a new RPF neighbor. Among all The downstream router may select a new RPF neighbor. Among all ECMP
ECMP upstream routers, the one on the same LAN as the previous RPF upstream routers, the one on the same LAN as the previous RPF
neighbor is preferred. neighbor is preferred.
If there is no upstream router reachable on the same LAN, the down If there is no upstream router reachable on the same LAN, the
stream router will select an RPF neighbor on a different LAN. Among downstream router will select a new RPF neighbor on a different LAN.
all ECMP upstream routers, the one that served as RPF neighbor before Among all ECMP upstream routers, the one that served as RPF neighbor
the link failure is preferred. Such a router can be identified by before the link failure is preferred. Such a router can be
the Router ID, which is part of the Interface ID in the PIM ECMP identified by the Router ID, which is part of the Interface ID in the
Redirect Hello option. PIM ECMP Redirect Hello option.
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.5. Interoperability 3.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. A PIM option ECMP-Redirect-Supported TLV in its PIM Hello messages.
router sends ECMP Redirects on an interface only when it detects that
all neighbors have sent this Hello option. If a PIM router detects
that any of its neighbor does not support this Hello option, it MUST
not send ECMP Redirects, however, it SHOULD still process any ECMP
Redirects received.
3.6. Packet Format A PIM router sends ECMP Redirects on an interface only when it
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
bundle does not support this Hello option, it SHOULD NOT send ECMP
Redirects to any interface in that bundle, however, it SHOULD still
process any ECMP Redirects received from any interface in the same
bundle.
3.6.1. PIM ECMP Redirect Hello Option If a PIM router does not support this specification, it will ignore
the ECMP-Redirect-Supported TLV in Hello and ECMP Redirects in PIM
packets, which it receives.
3.5. Packet Format
3.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 = TBD | Length = 0 | | Type = 32 | Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ECMP Redirect Hello Option Figure 1: ECMP Redirect Hello Option
Type: TBD. Type: 32, temporarily assigned by IANA
Length: 0 Length: 0
3.6.2. PIM ECMP Redirect Format 3.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 8, line 33 skipping to change at page 9, line 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-- ... Metric ... -+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-- ... Metric ... -+-+-+-+-+-+-+-+-+
| | | |
+- .. Metric .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +- .. Metric .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 2: ECMP Redirect Message Format Figure 2: ECMP Redirect Message Format
Type: TBD Type: TBD
Neighbor Address (32/128 bits): Address of desired upstream Neighbor Address (32/128 bits): Address of desired upstream
neighbor where the downstream receiver should redirect PIM Joins. neighbor where the downstream receiver SHOULD redirect PIM Joins.
This address MUST be associated with an interface in the same ECMP This address MUST be associated with an interface in the same ECMP
bundle as the ECMP Redirect message's outgoing interface. If the bundle as the ECMP Redirect message's outgoing interface. If the
"Interface ID" field (see below) is ignored, this "Neighbor "Interface ID" field (see below) is ignored, this "Neighbor
Address" field uniquely identifies a LAN and an upstream router to Address" field uniquely identifies a LAN and an upstream router to
which a downstream router should redirect its Join messages, and which a downstream router SHOULD redirect its Join messages, and
an ECMP Redirect message MUST be discarded if the "Neighbor an ECMP Redirect message MUST be discarded if the "Neighbor
Address" field in the message does not match cached neighbor Address" field in the message does not match cached neighbor
address. address.
Interface ID (64 bits): This field is used in IPv4 when one or more Interface ID (64 bits): This field is used in IPv4 when one or more
RPF neighbors in the ECMP bundle are unnumbered, or in IPv6 where RPF neighbors in the ECMP bundle are unnumbered, or in IPv6 where
link local addresses are in use. For other IPv4 usage, this field link local addresses are in use. For other IPv4 usage, this field
is zero'ed when sent, and ignored when received. If the "Router is zero'ed when sent, and ignored when received. If the "Router
ID" part of the "Interface ID" is zero, the field must be ignored. ID" part of the "Interface ID" is zero, the field MUST be ignored.
See [RFC6395] for details of its assignment and usage in PIM See [RFC6395] for details of its assignment and usage in PIM
Hellos. If the "Interface ID" is not ignored, the receiving Hellos. If the "Interface ID" is not ignored, the receiving
router of this message MUST use the "Interface ID", instead of router of this message MUST use the "Interface ID", instead of
"Neighbor Address", to identify the new RPF neighbor, and an ECMP "Neighbor Address", to identify the new RPF neighbor, and an ECMP
Redirect message MUST be discarded if the "Interface ID" field in Redirect message MUST be discarded if the "Interface ID" field in
the message does not match the cached interface ID. the message does not match the cached interface ID.
Preference (8 bits): The first tie breaker when ECMP Redirects from Preference (8 bits): The first tie breaker when ECMP Redirects from
multiple upstream routers are compared against each other. multiple upstream routers are compared against each other.
Numerically smaller value is preferred. A reserved value (15) is Numerically smaller value is preferred. A reserved value (15) is
used to indicate the metric value following the "Preference" field used to indicate the metric value following the "Preference" field
is a timestamp, taken at the moment the sending router started to is a Network Time Protocol (NTP) timestamp, encoded in the format
forward out of this interface. specified in [RFC5905], taken at the moment the sending router
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 4. 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], this document Redirect Hello Option. According to [HELLO-OPT], 32 (0x20) has been
recommends 32 (0x20) as the "PIM ECMP Redirect Hello Option Type". temporarily assigned by IANA to the "PIM ECMP Redirect Hello Option
Type".
A PIM Message Type is requested to be assigned to the ECMP Redirect A PIM Message Type (TBD) is requested to be assigned to the ECMP
message. According to [RFC6166], the next available Type value is 11 Redirect message. According to [RFC6166], the next available Type
(0xB). value is 11 (0xB).
5. Security Considerations 5. 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. upstream router, and trigger more ECMP Redirect messages.
6. Acknowledgement 6. 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 and Jeffrey Zhang for their review comments. Venaas, Jeffrey Zhang, Bill Atwood and Adrian Farrel for their review
comments.
7. References 7. References
7.1. Normative Reference 7.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 7.2. Informative References
skipping to change at page 10, line 29 skipping to change at page 10, line 47
[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,
April 2011. April 2011.
[RFC6395] Gulrajani, S. and S. Venaas, "An Interface Identifier (ID) [RFC6395] Gulrajani, S. and S. Venaas, "An Interface Identifier (ID)
Hello Option for PIM", RFC 6395, October 2011. Hello Option for PIM", RFC 6395, October 2011.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2012.
[HELLO-OPT] [HELLO-OPT]
IANA, "PIM Hello Options", PIM-HELLO-OPTIONS per IANA, "PIM Hello Options", PIM-HELLO-OPTIONS per [RFC4601]
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
Cisco Systems, Inc. Microsoft
Tasman Drive La Avenida
San Jose, CA 95134 Mountain View, CA 94043
USA USA
Email: ycai@cisco.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
Email: lwei@cisco.com Email: lwei@cisco.com
Heidi Ou Heidi Ou
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 42 change blocks. 
93 lines changed or deleted 127 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/