Subject: [RTG-DIR] RtgDir review: draft-ietf-roll-p2p-measurement-07.txt

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 09 Jan 2013 20:46:55 -0500

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

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

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

     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?

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

     Section 7, second paragraph could also be usefully reversed.

     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?

Yours,
Joel M. Halpern

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 15 Jan 2013 01:43:46 -0600 (CST)

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

Comments:

Major Issues:

Minor Issues:
---------------------------------------------------------
[JH]

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

[JH]
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 

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

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

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

[MG]
Done.

[JH]

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

[JH]

[MG]
Done.

[JH]

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

Thanks
Mukul

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 15 Jan 2013 14:50:56 -0500

Thank you very much.
These changes very nicely address my concerns.  I can understood why you 
chose not to make the one change about route construction restrictions. 
  Your modified text does help that somewhat, without being verbose, and 
I can live with that.

Yours,
Joel