[RTG-DIR] RtgDir review: draft-ietf-pim-ecmp-03.txt

["Papadimitriou, Dimitri (Dimitri)" <[e-mail]>]

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-pim-ecmp-03.txt
Reviewer: Dimitri Papadimitriou
Review Date: June 12, 2012
IETF LC End Date: date-if-known
Intended Status: copy-from-I-D

Summary:

    I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors.

Comments:

   In terms of readability, the introduction shall be a separate section from the protocol operation overview and applicability.

Major Issues:

   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." 
   Comment: How the upstream neighbor (preferred upstream router) determines the alternate neighbor ?

   How the proposed algorithm ensures an upstream neighbor will ever 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.

   Note: If the assumption made by the document is that all PIM routers know each other preferences/metrics why to propose this mechanism at first place ?

   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. Not convinced that a preference/metric discovery wouldn't be better included in the Hello exchanges. 

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

Minor Issues:

   Section 2: "This usually leads to inefficient or ineffective use of network resources." any 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.
 
Thanks,
-dimitri.
-----
Homepage:
<http://belllabs.be/people/dpapadimitriou/>
<http://psg.com/~dpapadimitriou>