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

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?

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.

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.

  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

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)

(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.

Thank you for addressing my concern