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

From: Stig Venaas <[email-masked]>
Date: Wed, 26 Sep 2012 12:11:22 -0700

Hi Alvaro, thanks for the careful review. Sorry for not responding
earlier. I'm working on updating the draft finally.

On 6/11/2012 6:06 PM, Retana, Alvaro wrote:
> 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.

I'll take care of this.

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

The main concern is that if you implement this now and we later define
an extension making the length non-zero, the implementations of this
draft should ignore the length. It would be bad if they assumed
something was wrong because the length was not 0.

If we define an extension in an RFC, that document can update this
document. Old implementations will work as intended. New implementations
will per the new document accept the non-zero length.

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

There is no registry, and no registry assignments. New options will
have to be defined by updating this document.

> 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?

If B receives joins from C without the P flag set, then B should also
not set the P flag when sending joins to A. This because B knows that
a downstream router does not support it. So basically if one router in
the entire tree sends a join without P set, then from that router, and
all the way to the root, P will not be set.

It says "entire sub-tree", this implies that it must be "transitive".

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

Right. I think I need to confer with the other authors and the WG.
The question is whether we want to count an interface twice (both
transit and stub) if both PIM and IGMP/MLD membership.

The alternative would be to say that either transit or stub is the
case where there are only PIM joins, or only host membership.

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

Right, will try to clarify. It's the number of oifs + the sum of the
transit count in the joins received from the downstream neighbors.

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

Right.

> 8.Section 4…on the last paragraph.  Should the “should not” on the last
> sentence be “SHOULD NOT”?

Yes, think so. Will change.

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

Will fix.

Stig

> Thanks!
> Alvaro.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 27 Sep 2012 10:54:45 +0000

Stig:

Hi!

I have some comments below (leaving just the relevant text).

Thanks!

Alvaro.

On 9/26/12 3:11 PM, "Stig Venaas" <[email-masked]> wrote:
...
>
>> 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).
>

The text is still confusing, but I see what you mean; you're using the
OptionLength as some sort of "version number": 0 indicates support for
this draft, some other number indicates support for extensions.

Isn't it easier/cleaner to just mandate that the OptionType for this draft
be of length 0, and let any extensions get a new OptionType?  That new
OptionType can implicitly signal support for this draft as well.

>
>> 3.Section 3ŠThere are no IANA considerations as to how to assign the

Yes, but what is the criteria for letting someone use one of the flags?
Can anyone just write a draft and get a bit?  Will it be
first-come-first-serve, do we need a standards track doc?

Maybe I'm making a big deal about this since this draft is Experimental,
but I think there could easily be overlaps in assignments and the bits may
be gone fast (only 16).

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

Yeah, I missed the part about clearing it.  Maybe just change "must" to
"MUST".

---

From: Stig Venaas <[email-masked]>
Date: Thu, 27 Sep 2012 12:05:24 -0700

Hi

> OptionType can implicitly signal support for this draft as well.

That could be done, but all I'm trying to say is that implementations of
this RFC MUST ignore the length and still accept the option if non-0.
Basically just check if the option is present, don't check contents or
length.

> but I think there could easily be overlaps in assignments and the bits may

I agree. I don't think we need to create a registry though. At least not
at this point. Does it still make sense to specify in the IANA
considerations what is needed? Or in another document? If there is no
registry and nothing is said, then I would assume by default that an RFC
is needed though. Maybe I'll just state where the bits are defined, that
an RFC is needed to define new bits.

It just feels a bit weird doing a registry for bits like this. Of course
what we're doing is a bit unusual.

> Yeah, I missed the part about clearing it.  Maybe just change "must" to
OK

Stig