Re: [Roll] RtgDir review: draft-ietf-roll-p2p-measurement-07.txt

[Mukul Goyal <[e-mail]>]

Hi Joel

Thanks for your review. I have made changes to the draft based on your comments. The modified draft can be seen at:

https://pantherfile.uwm.edu/mukul/public/files/draft-ietf-roll-p2p-measurement-08.txt

I will include these changes in the new version to be posted at the conclusion of the last call.

Please see my response to your comments below and let me know if the modifications to the draft look OK to you.

Thanks
Mukul

----- Original Message -----

Document: draft-ietf-roll-p2p-measurement-07.txt

Reviewer: Joel M. Halpern
Review Date: 9-Januar-2013
IETF LC End Date: 21-January-2013
Intended Status: Experimental

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

Comments:
     Generally, this is a well written and readable specification 
addressing an understandable problem.

Major Issues:

Minor Issues:
---------------------------------------------------------
[JH]
     I had not realized until section 4.3 that NUM (and the structure of 
the message) had to allow for the desired limit on the Address 
Accumulation.  (I had originally inferred a rather painful strategy.) 
Could this be stated earlier in the document please?

[MG]
Done. Please see the text between (mods_1_begin) and (mods_1_end) tags in Sections 2 and 3.

[JH]
     Can the first sentence of the text in the nested bullet on Source 
Routed Address vectors ("When the Measurement Request is traveling along 
a Source Route...") be moved before the description of the bits  (sorry, 
it may need to be slightly reworded to do so.)  This restriction is very 
helpful in understand the behaviors defined by the various flags in the 
message header.  

[MG]
Done. Please see the text between (mods_1_begin) and (mods_1_end) tags in Section 2.

[JH]
(Also, if it wouldn't bother the ROLL/RPL experts too 
much, a comment about he root not needing to add a source route for a 
local RPLInstance would complete the picture nicely.  I am merely 
inferring this behavior from the fact that accumulate is allowed with 
hop-by-hop and local RPLInstances.)

[MG]
To respond to your comment, I thought long and hard about including a brief section on global/local RPLInstanceIDs, storing/non-storing DAGs and other such RPL delicacies and then decided against it. I think this document is not the right place
for such details. The biggest concern was that it would be impossible to keep the section "brief". I think RPL and P2P-RPL documents must be referred to get these details. I did add a tiny bit of text in the Overview Section (see the tags mods_2_...) regarding how Source/Hop-by-hop routes are identified. 

BTW, the specific comment you sought would go some thing like this: RPL provides local RPLInstanceIDs to allow routers to create local DAGs. P2P-RPL uses local RPLInstanceIDs in a particular fashion. Under P2P-RPL, a router (the Origin) discovers a route by creating (by acting as the root for) a temporary DAG that is identified by one of the Origin's IPv6 addresses and a local RPLInstanceID. The temporary DAG dies soon after a Source Route has been discovered or a Hop-by-hop Route has been established. Such a Hop-by-hop route, discovered using P2P-RPL, is identified by the same <local RPLInstanceID, Origin's address> tuple that was used to identify the temporary DAG. So, a route discovered using P2P-RPL is always either a pure Source Route or a pure Hop-by-hop route and is never a "mixed" route. 

[JH]
     It appears that the loop prevention requirement on source routes 
requires every router that handles the packet to examine every entry in 
the source route to make sure that the inspecting router does not appear 
anywhere except a the current index entry.  ("MUST ensure that o address 
appears more than once" in section 5.1, and text in section 5.3.)  That 
would seem to be a significant cost, for no obvious benefit.  Why is it 
required?  (Yes, I have read the last bullet of section 9.  This seems 
to be a very expensive set of extra protections.  Given that the index 
gets increment, the cost of a loop seems pretty small.)

[MG]
You are right. I realized there is no real need for an Intermediate Point to check for loops. I also realized that this check does not always protect against a rogue Intermediate Point modifying the Address vector to insert a routing loop (suppose the nodes that appear multiple times in the modified Address vector wont see this Measurement Request). I have removed from the text this unnecessary check as well as the reference to it in the Security section.

[JH]
     I section 5.2 and 5.3, how can the processing node determine the 
"Address vector is present in the received message" if the Num field is 0?

[MG]
Right. The Num value is the only way to tell whether an Address vector is present or not. Corrected the language everywhere.

[JH]
Nits:
     Could the first bullet in section 5.1 be re-ordered so that the 
condition ("if it does not know how to reach the End Point") occurs 
before the "MUST discard".  As written, the reader is startled by 
thinking that the first thing the root must do is discard the request.
     Could the same be done to the second and third paragraphs of 5.2?
     And the second and third paragraphs of section 5.3?
     And the second paragraph of section 5.4?  (The third paragraph of 
5.4 has things in the order which I think is clearer for the reader.)

[MG]
Done.

[JH]
     The last sentence of the next to last paragraph of 5.5 could also 
be reversed, although for some unknown reason I find that one less 
bothersome.

[MG]
OK. I did not change this particular sentence.

[JH]
     Section 7, second paragraph could also be usefully reversed.

[MG]
Done.

[JH]
     I presume that all the "dropped with no further processing" is not 
intended to preclude updating error counters and similar actions.  Is 
there a place that could be said?

[MG]
Right. Added the relevant text towards the end of Section 3.1 (look for tags mods_3_...).

Thanks
Mukul