Subject: [pim] AD Review draft-ietf-pim-ecmp

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 3 Apr 2012 20:53:20 +0100

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 [email-masked] 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?

---

From: Heidi Ou <[email-masked]>
Date: Wed, 04 Apr 2012 12:29:27 -0700

Hi Adrian,

We will generate a new version to address your comments.

BTW: my previous reply on  "Re:[pim] AD review of draft-ietf-pim-pop-count"
was a mistake.

thanks
- Heidi

On 4/3/12 12:53 PM, "Adrian Farrel" <[email-masked]> wrote:

> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim