Re: [Roll] ID Tracker State Update Notice: <draft-ietf-roll-p2p-rpl-14.txt>
Mukul Goyal <mukul@uwm.edu> Wed, 12 December 2012 16:18 UTC
Return-Path: <prvs=68608198d=mukul@uwm.edu>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B2D21E804D for <roll@ietfa.amsl.com>; Wed, 12 Dec 2012 08:18:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQfvN82jNVvv for <roll@ietfa.amsl.com>; Wed, 12 Dec 2012 08:18:10 -0800 (PST)
Received: from ip4mta.uwm.edu (ip4mta.uwm.edu [129.89.7.194]) by ietfa.amsl.com (Postfix) with ESMTP id CA84721E804A for <roll@ietf.org>; Wed, 12 Dec 2012 08:18:09 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap4EAJ+tyFB/AAAB/2dsb2JhbAA7BAaGN7h0gxgjVhsaAg0ZAlkGEYgTDKpMiXyJBQSBIos6BRGDCYETA4hgjSmQSIMSIIEmPQ
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 4457E2A0F8F; Wed, 12 Dec 2012 10:18:08 -0600 (CST)
X-Virus-Scanned: amavisd-new at
Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qy24elT6Q3nc; Wed, 12 Dec 2012 10:18:08 -0600 (CST)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id F10AA2A0F9F; Wed, 12 Dec 2012 10:18:07 -0600 (CST)
Date: Wed, 12 Dec 2012 10:18:07 -0600
From: Mukul Goyal <mukul@uwm.edu>
To: adrian <adrian@olddog.co.uk>
Message-ID: <287955328.88535.1355329087754.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <20121205130218.2838.4560.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [99.20.249.193]
X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995)
X-Authenticated-User: mukul@uwm.edu
Cc: roll <roll@ietf.org>
Subject: Re: [Roll] ID Tracker State Update Notice: <draft-ietf-roll-p2p-rpl-14.txt>
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Dec 2012 16:18:12 -0000
Hi Adrian I have updated p2p-rpl draft based on your comments. The updated draft can be found at: https://pantherfile.uwm.edu/mukul/public/draft-ietf-roll-p2p-rpl-15.txt Please let me know if the updated draft meets your concerns or if further modifications are required. Once, you have no concerns left, I will post the new version of the document. Please see my response to your individual comments below. Thanks Mukul --- [Adrian] I would like you to include some discussion of the "experiment". There is a note in section 6.1 encouraging deployments to share their experience of the default values, but that seems like the tip of the iceberg. Section 9.2 might also usefully contain such a statement. [Mukul] See the additional line towards the end of Section 9.2 (search for mods_1_) [Adrian] A way to approach this is to put a paragraph or two at the end of Section 1 saying: - This document is presented as an Experimental specification because... - Reports of observations in implementation and deployment are encouraged in particular with respect to... - It is anticipated that, if there is interest and positive reports of experimental research and deployments, this specification might be revised at some time in the future to progress it on to the Standards Track. [Mukul] See the new paragraph towards the end of Section 1 (search for mods_2_). --- [Adrian] Some abbreviations will need to be spelled out: DODAG RPL [Mukul] Done. Search for mods_3_ and mods_4_ --- [Adrian] Section 1 Also, the discovered routes may not be optimal. I prefer s/may/might/ Similarly in Section 5 Also, the discovered routes may not be the best available. [Mukul] Done. Search for mods_5_ and mods_6_. --- [Adrian] There are several mentions of the fact that this I-D allows discovery of up to four Source Routes per Target. Should you include a comment about why that limit is acceptable? [Mukul] Done. Search for mods_7_. --- [Adrian] I am slightly worried by Section 5 saying The Target may remember the discovered route for use as a Source Route to reach the Origin. Of course, this is true, but there is no evidence that the discovered Origin-to-Target route can be reversed, so there is no evidence that the discovered route will work as a Source Route to reach the Origin. I feel that suggesting this option without qualifying it very heavily is rather unwise. Now 7.1 says * The IPv6 addresses in the Address vector MUST be reachable in both Forward and Backward directions. Reachability in the Backward direction allows a DRO message to use the route accumulated in the Address vector to travel from the Target to the Origin. This would address my concern, but I don't see how a node filling an address into the Address vector knows that that address is reachable in the backward direction. That could, itself, be fixed if there is a process that says a node receiving an Address vector MUST check the last address in the list and drop the whole message if the address is not reachable in the backward direction - ah, and there it is in Section 9.4. So it is all a bit buried! Can you put in some forward pointers? [Mukul] Done. Search for mods_8. --- [Adrian] Starting at the top of Section 6 there are some rules about how messages must be formed. E.g.: A P2P mode DIO MUST carry one and only one P2P Route Discovery Option We need a statement (presumably a catch-all, and possibly a pointer to 6550) that tells an implementation what to do with a malformed message. [Mukul] Done. Search for mods_9. [Adrian] Some cases will be reject/discard, but I think some will be ignore. For example, in Section 6.1: Version Number: MUST be set to zero ...can surely be safely ignored by the receiver. [Mukul] Actually, we insist that version number be set to zero else DIO has to be discarded. RPL uses (RPLInstanceID, DODAGID, VersionNumber) tuple to uniquely identify a DODAG and we dont want to change that in P2P-RPL. [Adrian] And, a number of the fields if set wrongly will simply break things, but it may be possible to protect against this by cross-checking with the MOP. At the end of 6.1, I do find... A router MUST discard a received P2P mode DIO if it violates any of the rules listed above. ...but it feels like this is intended to apply to the immediately- preceding bullet list. [Mukul] Right, the document was not very clear regarding when should a received DIO be dropped. I have added text at a number of places explicitly requiring a received DIO/DRO message to be dropped if given conditions are not met. Please search for mods_10_ to see this text. --- [Adrian] Section 6.1 has o Mode of Operation (MOP): MUST be set to 4, corresponding to P2P Route Discovery mode. I think this "4" needs to be replaced with "TBD1" [Mukul] Yes. Done. Search for mods_11. --- [Adrian] Section 7.1 * A router adding its address to the vector MUST ensure that its address does not already exist in the vector. s/its address does/any of its addresses do/ [Mukul] Done. Search for mods_12_. --- [Adrian] Section 7.2 and 14.4 Why do you feel it necessary or good to create a new registry of payload protocols? Is the 5237 registry a problem for some reason? Furthermore, why have you reserved 0xff for Private Use? Given that the whole document is Experimental, this seems a bit extreme. Do you have a specific motivation for this unusual assignment? [Mukul] We were using a new registry because this field was 4 bits earlier. Now that it is 8 bits now, we can use 5237 registry. The change has been made. Please search for mods_13_ to see the new text. --- [Adrian] Section 8: Options Since multiple options may be present, you need to describe any ordering rules. [Mukul] There are no ordering rules. RPL does not specify any ordering rules either. --- [Adrian] Section 13 Do you think you should advise applications sending data in the Data Option to take their own precautions to: a. secure against modification b. encrypt c. retransmit/acknowledge the data they are sending? [Mukul] Since the Data Option is inside a DIO/DRO message, it has the same level of protection as the message it is inside. A deployment may use link layer security or RPL's security mechanisms to meet its needs regarding security. I have added text in the Security Section (Section 13) as well as in the section defining Data Option (Section 7.2) to make this clear. I have also added text to clarify that P2P-RPL does not guarantee successful delivery of the data contained in a Data Option. Please search for mods_14 to see this text. In addition, I have made one more small modification (search for mods_15) to the document clarifying that a DRO MUST contain one and only one P2P-RDO. Thanks Mukul
- Re: [Roll] ID Tracker State Update Notice: <draft… Mukul Goyal
- Re: [Roll] ID Tracker State Update Notice: <draft… Adrian Farrel