Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect
draft-ietf-pim-ecmp-05

[Ballot discuss]
The following points are based on the Routing Directorate review by Dimitri Papadimitriou

To improve the readability of the document the introduction needs to be a separate section from the protocol operation overview and applicability.

===

  Section 2.1: From the statement "a PIM ECMP Redirect message is sent by
  an upstream router to notify downstream routers to redirect PIM Joins
  to the new RPF neighbor via a different interface. .  When the
  downstream routers receive this message, they SHOULD trigger PIM
  Joins toward the new RPF neighbor specified in the packet."
 

It is unclear how the upstream neighbor (preferred upstream router) determines the alternate neighbor.

Please describe how the proposed algorithm ensures an upstream neighbor will  be determined if the selection rules aren't consistent or known among PIM routers. The document specifies the conditions under which ECMP redirect has to be sent not the selection criteria leading to that decision. The alternative would be to specify tie breaking rules (not just the information) such that at least the downstream neighbor can determine the best among the non-desired upstream neighbors. This also contradicts the statement that pruning is to be used to process incoming " Receiving ECMP Redirect" message.

====

  Section 3.2: a preference-based process indicates (at least partially) sequential process, whereas the middle paragraphs of that section reads as if the Join messages would be used as a preference discovery process.

Would it have been better to have been better to have included the preference/metric information in the Hello exchanges?

====

  Section 3.3: how does  the proposed approach behaves in case upstream neighbor changes its preference rules ?

====

[Ballot comment]
The following points are based on the Routing Directorate review by Dimitri Papadimitriou

  Section 2: "This usually leads to inefficient or ineffective use of network resources." Do you have a reference to make this statement quantitative ?

  Section 3.5 s/3.5.  Packet Format/Message and Option Format

  Coding of preference and metrics type/value shall be specified.

[Ballot comment]
1) a: The RFC editor will make you remove the reference from the abstract.  If you're going to rec it before the draft gets there r/[RFC4061]/(RFC 4061).

2) s1: Tripped over the definition of EMCP bundle too.

3) s2 (nit picking): RFC 4601 calls it a hash function not a hash algorithm.

4) I tripped on the same thing Stephen did in the security considerations.

5) The paragraph in the security considerations seems to apply to the PIM message type, but since you're also defining a new hello message option shouldn't those be discussed as well?  Even it's just:  The use of the PIM Hello option defined in this document does not introduce additional security considerations to those already described in [RFC4601].  (assuming that's true of course)

[Ballot comment]
The following is a COMMENT. However, let's have a chat on this one, because I really would like to understand.

  When a downstream router receives an ECMP Redirect, and detects that
  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
  current path and join the new path.  The exact order of such actions
  is implementation specific.

Is the last sentence good enough for a standard track document?
Should I first join the new path and then prune? Otherwise, I will miss some traffic, right?
Because I see: "In essence, a PIM ECMP Redirect message is sent by an upstream router to notify downstream routers to redirect PIM Joins to the new RPF neighbor via a different interface.  When the downstream routers receive this message, they SHOULD trigger PIM Joins toward the new RPF neighbor specified in the packet."
So by the time the downstream router sends the JOIN, he will losing some traffic. Unless, the upstream router already sent the traffic to its preferred path: maybe I missed it, but I have not seen this specified in the draft.

Note: if I join the new path and then prune, then I will have duplicate traffic... which is fine with multicast.

I'm also confused by those SHOULD in the two sentences I mentioned regarding interoperability between downstream and upstream routers.


- One minor comment. Not sure what you gain by having the following entry in the terminology section
  o  RPF.  RPF stands for Reverse Path Forwarding.

- With some background in PIM, we can deduce if you speak about ECMP for forwarding traffic (downstream) or ECMP for RFP (upstream). However, sometimes is not that easy. For example:

  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.

First sentence is downstream, while the second one is upstream. Is my understanding correct?
Should we clarify the sentences in the document where ECMP is mentioned.


-  "An upstream router MAY choose not to send ECMP Redirects if it
  becomes aware that some of the downstream routers are unreachable via
  some links in ECMP bundle."

SHOULD NOT send?

-
OLD:

  When a downstream router receives an ECMP Redirect, and detects that
  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
  current path and join the new path.  The exact order of such actions
  is implementation specific.

NEW:
  When a downstream router receives an ECMP Redirect, and detects that
  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
  current path and join the new suggested path.  The exact order of such actions
  is implementation specific.

This change might be perceived as a detail. However, at that point in time in the draft, it was not clear that the path was suggested in the ECMP Redirect packet, and I was wondering: what if there are 3 ECMPs?


- There is something wrong with RECOMMENDED and may in the next sentence

  In such an event, the following actions are  RECOMMENDED.

  The downstream router may select a new RPF neighbor.  Among all ECMP
  upstream routers, the one on the same LAN as the previous RPF
  neighbor is preferred.

[Ballot comment]
I don't think this is worthy of DISCUSSion, and if you ignore these I will not be throwing a fit, but I strongly suggest that you correct the following problems:

I feel more strongly than Barry about the 2119 keyword usage. He is correct that you can't tell for many of the SHOULDs what circumstances might cause one to violate the requirement. However, as far as I can tell, most of the 2119 keywords are misused:

3.1: "An upstream router MAY choose not to send ECMP Redirects if it becomes aware that some of the downstream routers are unreachable via some links in ECMP bundle."

That's not a proper use of MAY. What if it is *not* aware of unreachable downstream routers? Is it then that it MUST send the ECMP Redirects? What protocol requirement is the sentence trying to describe?

3.2: What are the interoperability implications of each of these three SHOULDs? What bad things happen if I don't follow those requirements? And again, what are the kinds of circumstances where it might be reasonable to violate?

3.3: It says that "the following actions are RECOMMENDED", but then the first one says that the "downstream router may select a new neighbor". It is an interoperability RECOMMENDation that the router *may* do something? That seems weird. I don't think RECOMMENDED is used correctly here.

3.5.2: I think it's generally bad form to use 2119 keywords in the definitions of packet formats.

  Neighbor Address (32/128 bits):  Address of desired upstream
      neighbor where the downstream receiver SHOULD redirect PIM Joins.
     
Where else might it send PIM Joins? Don't you rather mean, "Address of neighbor that has requested redirected PIM Joins."? Same with the other SHOULD in this section.

      This address MUST be associated with an interface in the same ECMP
      bundle as the ECMP Redirect message's outgoing interface.

Doesn't this belong in 3.1 or 3.4?

      an ECMP Redirect message MUST be discarded if the "Neighbor
      Address" field in the message does not match cached neighbor
      address.

Again, doesn't this belong in 3.2 or 3.4? Here, it should simply say, "is discarded".

I think the same is true for the other two MUSTs in this section.

[Ballot comment]

  Please consider the editorial comments from the Gen-ART Review by
  Miguel Garcia on 11-Jun-2012.  The review can be found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07506.html

[Ballot comment]

  Please consider the editorial comments from the Gen-ART Review by
  Miguel Garcia on 11-Jun-2012-06-11.  The review can be found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07506.html

[Ballot comment]

(You should be aware of my ignorance of PIM when reading this;-)

- I don't quite get what this means: "The ECMP links reside
between the upstream and downstream routers over the ECMP
bundle." I think its just awkwardly phrased though, if it means
that the ECMP links are those whose interfaces are part of some
ECMP bundle. If it means something else then I didn't get it.

- 3.1: What's a "preferred" upstream router? Its not clear
whose preference is meant.

- 3.3: Is "on the same LAN" well-defined? Where?

- 3.5.2: The text after figure 2 says nothing about the 1st set
of fields, I guess a reference to where those are described
would be good. (Its kind of obvious, but still...)

- 3.5.2: "unnumbered" - just curious - is that defined
somewhere in an RFC?

- 3.5.2: This doesn't actually define smaller or bigger very
well, but its kind of obvious I guess.  Be no harm to say it
though, esp. for the Metric or just say "same as RFC foo".

- security considerations: it might be worth stating that the
4601 statement that you SHOULD NOT accept (PIM) protocol
messages from anyone from whom you've not got an acceptable PIM
Hello also applies here. I believe that is already implied by
the current text, (if not, I'd probably make that a DISCUSS),
but maybe could be missed by an implementer since you only say
"same as PIM assert" in this document.

[Ballot comment]
Thanks for a very clear, very readable document, giving this Applications guy something in Routing that he can read, understand, and see the use of.

One very small comment: you have a number of SHOULD, SHOULD NOT, and RECOMMENDED keywords (sections 3.2 thru 3.4, and I'm especially thinking of 3.3).  It might be nice to include some sense of when it would be reasonable to choose against these,  -- if you can identify such situations --.  Remember that "RECOMMENDED", in RFC 2119, isn't just about recommendations: it basically means that this is what you MUST do unless you fully understand the ramifications of not doing so.

-- Security Considerations --
   Spoofed ECMP Redirect packets may
   cause the downstream routers to send PIM Joins to an undesired
   upstream router, and trigger more ECMP Redirect messages.

Any recommendations on what to do about this?

IANA has reviewed draft-ietf-pim-ecmp-03 and has the following comments:

IANA understands that, upon approval of this document, there are two IANA actions which must be completed.

First, in the PIM-Hello Options subregistry of the Protocol Independent
Multicast (PIM) Parameters registry located at:

http://www.iana.org/assignments/pim-parameters/pim-parameters.xml

the value 320 "PIM ECMP Redirect Hello Option" which has been provisionally
allocated should be permanently allocated and its reference changed to [
RFC-to-be ].

Second, in the PIM Message Types subregistry of the Protocol Independent
Multicast (PIM) Parameters registry located at:

http://www.iana.org/assignments/pim-parameters/pim-parameters.xml

a new Message Type will be allocated as follows:

Type: [ TBD ]
Name: ECMP Redirect
Reference: [ RFC-to-be ]

IANA notes that the authors suggest 11 (0xB) for this value.

IANA understands that these are the only actions required upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Protocol Independent Multicast ECMP Redirect) to Proposed Standard


The IESG has received a request from the Protocol Independent Multicast
WG (pim) to consider the following document:
- 'Protocol Independent Multicast ECMP Redirect'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-06-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  A Protocol Independent Multicast (PIM) [RFC4601] router uses the
  Reverse Path Forwarding (RPF) procedure to select an upstream
  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
  of traffic among the ECMPs 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 ECMPs.  It allows ECMP path selection to be
  based on administratively selected metrics, such as data transmission
  delays, path preferences and routing metrics.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pim-ecmp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pim-ecmp/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1780/

UPDATED DOCUMENT WRITE-UP
===========================

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard RFC due to wg consensus. The title page indicates
Standards Track.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document introduces the ECMP Redirect, a mechanism to improve
  the RPF procedure over ECMPs.  It allows ECMP path selection to be
  based on administratively selected metrics, such as data
  transmission delays, path preferences and routing metrics.

Working Group Summary

  There is consensus within the PIM WG to publish this document. The
  document has been actively discussed on the wg list and in wg
  meetings.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

Yes there is at least one implementation that will soon ship.

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Mike McBride is the document shepherd and Adrian Farrel is the
responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I read the document. The AD read the document. My co-chair has read
the document. The WG has read the document. It has been successfully
run through idnits. This version of the document is ready for
publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

I have no concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

IPR has been appropriately been confirmed by each author. The RFC
editor will need to add the IPR disclosure statement to the document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

During this document write-up it was discovered that IPR did exist on
this document. The authors subsequently disclosed and filed the
necessary IPR. One wg participant requested the details of the patent
which the authors then provided. The wg agreed to continue with the
advancement of this document despite the late IPR notice.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

There is solid WG consensus behind the document. It has undergone
thorough review within the multicast community. The document has been
actively discussed on the WG mailing listand in WG meetings.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No required formal review.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

RFC4601 is on the path to becoming an Internet Standard.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No, publication of this document will not change the status of any
existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

IANA considerations are clear and detailed.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No expert review necessary.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Not applicable

Hi,

I have done my usual AD review of your draft in response to the
publication request from the working group. The purpose of the
review is to clean up issues that I think might show up in IETF
last call, Directorate reviews, or during IESG evaluation. By
catching the issues at this stage we can save the effort of multiple
reviewers, and achieve a smoother passage through the publication
process.

All of my comments can be discussed.

As it stands, I think a new revision would help address these point
so I will move the I-D into "New Revision Required" state, and when
I see an update I will advance the document to IETF last call. Please
be sure to run idnits on the new revision and fix all of the warnings.

Thanks,
Adrian

---

It took me some time to determine that you are only talking about
parallel links between adjacent routers and not talking about the
more generic, network view of ECMP. In fact, I was so confused, I
had to ask for clarification on the PIM list.

In this context, is it really helpful to say ECMP? Wouldn't
"parallel, equal cost links" be a better term? It would also tie in
with other terminology relating to link bundles (such as in TE) while
avoiding confusion with the wider concept of ECMP.

While I would prefer that the document replaced "ECMP" with "parallel
links" throughout, I understand that this is a lot of effort and you
might not have the stamina to make the change. If you can't/won't do
that, could you please add a clarification to the Abstract and early
in the Introduction to say "In this document, the term ECMP is used to
apply to parallel, single-hop, equal cost links between a pair of
adjacent nodes."

---

Please update Yiqun's email address to yiqunc@microsoft.com and his
coordinates to Microsoft.

---

Please expand RPF in the Abstract and on first use in the Introduction.

---

The RFC Editor usually requires that the first section is the
Introduction, so best to move Section 1 to 2.3 and renumber.

---

The concept of an ECMP bundle is introduced in Section 3, and seems to
be central to the document. That means that the text in Section 2 is
missing this concept. Do you think you should move the definition of
an ECMP bundle to Section 2 so that Section 2.1 can refer to it?

---

In Section 3.2

  An upstream router may choose not to send ECMP Redirects if it
  becomes aware that some of the downstream routers do not support the
  message...

You need to say how it might "become aware". A pointer to 3.5 is
probably enough.

I think "may" is "MAY"

---

In Section 3.3

  When a downstream router receives an ECMP Redirect, and detects that
  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
  current path and join the new path.

Is that "SHOULD"?

---

Section 3.3

  If an upstream router receives an ECMP Redirect from another upstream
  router, it SHOULD NOT change its forwarding behavior even if the ECMP
  Redirect makes it a less preferred RPF neighbor on the receiving
  interface.

Too many "upstreams" to make this easy to parse. Is the second upstream
router upstream of the first upstream router? Or just upstream of the
downstream router?

Maybe you are missing some pictures in this document!

---

Section 3.4

  In such an event, the following actions are
  recommended.

Is that "RECOMMENDED"?

---

Section 3.4

s/down stream/downstream/  (twice)

Either
s/re-select a new/re-select a/
Or
s/re-select a new/select a new/

---

Section 3.5

  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.

s/neighbor/neighbors/
s/MUST not/MUST NOT/
s/send ECMP Redirects/send ECMP Redirects to that neighbor/

What would a legacy node do with an ECMP Redirect that it received?
You should be able to answer this with a reference to an existing RFC.

---

It would help IANA get their actions right if you could use TBD1 and
TBD2 instead of TBD twice. You can then also use those flags in
Section 4.

---

3.6.2

I am missing a definition of how a timestamp is encoded in the Metric
field. Assuming the idea is that the router that has been forwarding
out of its interface for longer will be preferred (by having a smaller
timestamp value), it would be important that everyone has the same
understanding of what a timestamp looks like.

---

Section 4

Could you help IANA by naming the registries as they are named on
the IANA pages?

PROTO Writeup for draft-ietf-pim-ecmp-02
=================================================

http://www.ietf.org/id/draft-ietf-pim-ecmp-02.txt

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the document
and, in particular, does he or she believe this version is ready
for forwarding to the IESG for publication?

Mike McBride is the document shepherd. I have personally reviewed the
document, and believe it is ready for publication as a Standards Track RFC.

(1.b) Has the document had adequate review both from key members of
the interested community and others? Does the Document Shepherd
have any concerns about the depth or breadth of the reviews that
have been performed?

The document has undergone thorough review within IETF's Multicast
community.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective, e.g.,
security, operational complexity, someone familiar with AAA,
internationalization or XML?

No

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or
she is uncomfortable with certain parts of the document, or has
concerns whether there really is a need for it. In any event, if
the interested community has discussed those issues and has
indicated that it still wishes to advance the document, detail
those concerns here.

I have no concerns.

(1.e) How solid is the consensus of the interested community behind
this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the interested
community as a whole understand and agree with it?

There is consensus within the PIM WG to publish the document. The document
has been actively discussed on the wg list and in wg meetings.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough. Has the document met all
formal review criteria it needs to, such as the MIB Doctor, media
type and URI type reviews?

Yes. We may need to have one update for Miscellaneous warnings if necessary:
----------------------------------------------------------------------------

== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).

Found 'MUST not' in this paragraph:

If a PIM router supports this specification, it MUST send the Hello
option ECMP-Redirect-Supported TLV in its PIM Hello messages. A PIM
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.


(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that are
not ready for advancement or are otherwise in an unclear state
If such normative references exist, what is the strategy for their
completion? Are there normative references that are downward
references, as described in [RFC3967]? If so, list these downward
references to support the Area Director in the Last Call procedure
for them [RFC3967].

Yes. Normative references are all stable documents published as RFCs.


(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of
the document? If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries? Are the
IANA registries clearly identified? If the document creates a new
registry, does it define the proposed initial contents of the
registry and an allocation procedure for future registrations?
Does it suggested a reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document
describes an Expert Review process has Shepherd conferred with the
Responsible Area Director so that the IESG can appoint the needed
Expert during the IESG Evaluation?

The IANA Considerations section exists. A PIM Hello Option Type is
requested to be assigned to the PIM ECMP Redirect Hello Option. This
document recommends 32 (0x20) as the "PIM ECMP Redirect Hello Option Type.

A PIM Message Type is requested to be assigned to the ECMP Redirect
message. The next available Type value is 11(0xB).

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML code,
BNF rules, MIB definitions, etc., validate correctly in an
automated checker?

Not applicable.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup. Recent examples can be found in the
"Action" announcements for approved documents.

This document introduces the ECMP Redirect, a mechanism to improve
the RPF procedure over ECMPs. It allows ECMP path selection to be
based on administratively selected metrics, such as data transmission
delays, path preferences and routing metrics.