Re: [Roll] ID Tracker State Update Notice: <draft-ietf-roll-p2p-rpl-14.txt>

Mukul Goyal <> Wed, 12 December 2012 16:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E8B2D21E804D for <>; Wed, 12 Dec 2012 08:18:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dQfvN82jNVvv for <>; Wed, 12 Dec 2012 08:18:10 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CA84721E804A for <>; 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 []) by (Postfix) with ESMTP id 4457E2A0F8F; Wed, 12 Dec 2012 10:18:08 -0600 (CST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qy24elT6Q3nc; Wed, 12 Dec 2012 10:18:08 -0600 (CST)
Received: from ( []) by (Postfix) with ESMTP id F10AA2A0F9F; Wed, 12 Dec 2012 10:18:07 -0600 (CST)
Date: Wed, 12 Dec 2012 10:18:07 -0600 (CST)
From: Mukul Goyal <>
To: adrian <>
Message-ID: <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995)
Cc: roll <>
Subject: Re: [Roll] ID Tracker State Update Notice: <draft-ietf-roll-p2p-rpl-14.txt>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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:

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.



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.


See the additional line towards the end of Section 9.2 (search for mods_1_)


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

See the new paragraph towards the end of Section 1 (search for mods_2_).

Some abbreviations will need to be spelled out:


Done. Search for mods_3_ and mods_4_

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.


Done. Search for mods_5_ and mods_6_.


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?

Done. Search for mods_7_.

I am slightly worried by Section 5 saying

   The Target may
   remember the discovered route for use as a Source Route to reach the

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

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

So it is all a bit buried! Can you put in some forward pointers?

Done. Search for mods_8.


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.

Done. Search for mods_9.

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.

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.

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

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.

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

Yes. Done. Search for mods_11.
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/

Done. Search for mods_12_.
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?


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.


Section 8: Options

Since multiple options may be present, you need to describe any ordering

There are no ordering rules. RPL does not specify any ordering rules either.
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?

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.