Subject: [Roll] multicast address in p2p-rpl-17

From: peter van der Stok <[email-masked]>
Date: Thu, 25 Apr 2013 09:52:43 +0200

Dear wg,

having read draft-ietf-roll-p2p-rpl-17 I ended up with a question 
concerning the routing to a multicast address.
I assume that routing the packet implies sending the packet with 
unicast to a given unicast address, following the source route table.
However, in case of a multicast address, the draft does not specify how 
routing should take place from the last unicast address in the source 
route to the multicast destination address. Is this:
- a link-local multicast to the multicast address
- an invocation of MPL

An alternative might be that all nodes for which an interface is 
enabled for the multicast address fill in their unicast address in the 
source route table; that means as many source routes as there are 
members of the multicast group; and routing ends at the last destination 
of the source route table.

 From the text it is not clear for me what the authors intended.

__________________________________________________________________________________________________________________________________

Below there are some suggestions to improve text readability:

section 1, introduction, text before the two bullits:
.... due to the following reasons: /replace with/ ....due to the 
following characteristics of RPL [RFC6550]

section 2 line 3, /remove/ "suddenly"

section 3 last alinea   ... The values for Counter is Time /replace 
with/ ... The values for Counter with T-flag (the first time this reads 
as a major cut/paste mistake)

section 5 alinea 2, line 3, up to four source routes per target. Where 
does "four" come from? The text seems to hint that it is linked to a 2 
bit field in the RDO format.

section 5, last alinea of page 9. The story about service discovery 
rather breaks the flow of the document and needs much more becakground 
and motivation to be useful. I suggest to suppress or to start a new 
section.
The consequence is that on page 10 the phrase: "This document does not 
specify ..... to select a route for ...." is less emphasized than it 
merits.

section 6, page 11 and 12, use k instead of l, the latter confuses 
easily with 1, although I understand the relation with L.

section 7, bullit TargetAddr, the unicast address is qualified but not 
the multicast address, why?

section 9.5 2nd alinea end at page 27. ... avoid selecting routes that 
have large segments in common. The reason for this criterium being that 
multiple paths can be used to supply fault tolerance within a short 
period and not needing new route discovery. I found this rather 
important aspect nowhere mentioned in the text. I suggest adding a 
paragraph in the introduction for motivating p2p-rpl.

Greetings, hope this helps,

peter
-- 
Peter van der Stok
mailto: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 25 Apr 2013 06:36:34 -0500 (CDT)

Hi Peter

P2P-RPL does not form a multicast tree if that is what you are asking. It just allows the discovery of _unicast_ routes to destinations that belong to a particular multicast group. A multicast address can be specified as Target in a P2P-RPL discovery and when a destination subscribing to this multicast group receives the DIO, it sends a DRO back (which carries a _unicast_ source route to this destination and which also establishes a hop-by-hop _unicast_ route to this particular destination if desired).

Yes. Also, it seems that there is no need for more routes per target.

I guess you are referring to the requirement that unicast address be global or unique local. What qualification do you seek for the multicast address?

Thanks
Mukul

----- Original Message -----
From: "peter van der Stok" <[email-masked]>
To: [email-masked]
Sent: Thursday, April 25, 2013 2:52:43 AM
Subject: [Roll] multicast address in p2p-rpl-17

Dear wg,

peter
-- 
Peter van der Stok
mailto: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll