Subject: [RTG-DIR] RtgDir review: draft-ietf-pim-pop-count-06

From: "Retana, Alvaro" <[email-masked]>
Date: Tue, 12 Jun 2012 01:06:47 +0000

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-pop-count-06
Reviewer: Alvaro Retana
Review Date: June 11, 2012
Intended Status: Experimental

Summary:

I have some minor concerns about this document that I think should be resolved before publication.

Comments:

In general, I found the draft to be well written, the intent, functionality and operation easy to follow.
Major Issues:
No major issues found.

Minor Issues:

1.       Section 2.   The first paragraph is a little confusing: it goes from sending Join/Prune messages, to how a router indicates support for the draft in a Hello message, back to when to send the Join/Prune messages, back to the format of the Hello option...

It would be nice to order the thoughts/process in the respective sections:  Section 2 covers the Hello Option and 3 the Join Attribute.  Note that Section 3 already includes the needed text so there's no need to put it here as well.

2.       The text explaining the Hello Option sounds contradictory to me.  The OptionLength is specified as 0, and the text reads: "In order to allow future updates of this specification that may include an option value, implementations of this document MUST accept and process this option also if the length is non-zero.  Implementations of this specification MUST accept and process the option ignoring any option value that may be included."

If the OptionLength is 0, then no value field should exist.  Presumably if future extensions would want to include a value, then they wouldn't want it to be ignored (as the second MUST mandates now).

3.       Section 3...There are no IANA considerations as to how to assign the Flags.  The same applies to the Option bits later in the text.

4.       P Flag.   If I understand correctly, the P Flag is set by a router when all its downstream neighbors support the draft...which seems to result in a hop-by-hop indication of the support.  Let's assume routers A, B, C and D in a line...if C supports the spec, then B should set the P flag towards A...but if D doesn't have support, C will still use the Hello Option to indicate it's support, *and* not set the P flag towards B.   In this case, A assumes that the "entire sub-tree" is accounting capable, but only A, B and C are.  Should the value received from the downstream be kept if not set?   Did I miss something?

5.       Transit Oif-List Count.  It defines a transit branch as one that has "no members...".  This definition contradicts the fact that a link may be both a transit link and a stub link, from section 1.2.

6.       Transit Oif-List Count.  The value is not just the number or oifs (as mentioned in the first sentence), but the additive value of all transit branches on the tree (as in the next to last sentence), right?  If so, it should be clarified.

7.       Stub Oif-List Count.  Same comment as above about the additive value.

8.       Section 4...on the last paragraph.  Should the "should not" on the last sentence be "SHOULD NOT"?

Nits:

1.       Section 3...the first field in the Flags is described as "Unalloc/Reserved", but then it's explained as "Unallocated Flags".    The same applies to the Option bits later in the text.

Thanks!

Alvaro.