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

From: peter van der Stok <[email-masked]>
Date: Fri, 26 Apr 2013 10:00:21 +0200

Hi Mukul,

thanks for your answer.
I apologize for my late questions but they are motivated by my recent 
contribution to rpl applicability statement.

I will reformulate my question in more detail.

Suppose that a DIO arrives with a source: <IPsource>, and route 
<IPhop1, IPhop2> and arrives at an interface with unicast IP address, 
IPdst, which is enabled for multicast address MCdst.
What will the DRO contain that is sent back? In my opinion the text 
seems to allow at least 2 possibilities (and needs clarification):
possibility 1: <source: IPsource, destination: MCdst, route: IPhop1, 
IPhop2>
possibility 2: <source: IPsource, destination: MCdst, route: IPhop1, 
IPhop2, IPdst>
variation 2: <source:IPsource, destination: IPdst, route IPhop1, 
IPhop2>

In case of possibility 1, a packet, unicast routed from source to 
IPhop2, is probably propagated with a link-local multicast from IPhop2 
to MCdst? That may suggest that only link-local Multicast addresses can 
be specified. When the packet is propagated from IPhop2 with MPL, (but 
then why do the unicast route first?) I would suggest to specify 
site-local and link-local MC addresses only.

In case of possibility 2, with variation 2, the packet is unicast 
routed from source to IPdst. (this is closest to the objective you 
describe below, but further from the RPL-P2P text)
The source receives as many DROs with at most 4 routes as there are 
members of the multicast group. That changes the restriction of "four 
source routes per target" into "four source routes per unicast 
destination". There is probably no technical limitation to the MC 
address but I would suggest also site-local and link-local MC addresses, 
given that rpl-p2p focusses on routing within a mesh, when routing via 
the root (edge router) gives unnecessary overhead.

I hope my question is clearer now. Glad to read where my interpretation 
goes wrong.

Greetings,

peter

Mukul Goyal schreef op 2013-04-25 13:36:
> 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).
> I guess it is too late to make the editorial changes you suggested. I
> am trying to answer your other queries below:
> 
>> 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.
> Yes. Also, it seems that there is no need for more routes per target.
> 
>> section 7, bullit TargetAddr, the unicast address is qualified but 
>> not
> the multicast address, why?
> 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,
> 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

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 26 Apr 2013 10:06:24 -0500 (CDT)

Peter

Please see inline.

[Peter]

[Mukul]
Variation 2 is what will happen. I think the draft is clear about it:

Section 7, inside the description of TargetAddr field inside P2P-RDO:
"When the P2P-RDO is included in a
      P2P-DRO, this field MUST contain a unicast global or unique local
      IPv6 address of the Target generating the P2P-DRO."

Also, in Section 8.2 (Setting a P2P-RDO Carried in a P2P Discovery Reply Object):
"TargetAddr: This field MUST contain a unicast global or unique
      local IPv6 address of the Target generating the P2P-DRO."

Section 7, inside the description of Address[1..n] field inside P2P-RDO:
"*  The Origin and Target addresses MUST NOT be included in the
         Address vector."
(So, the route wont include "IPdst")

Inside Section 9.3 (Processing a P2P mode DIO):
" The router MUST check the Target addresses listed in the P2P-RDO and
   any RPL Target Options included in the received DIO.  If one of its
   IPv6 addresses is listed as a Target address or if it belongs to the
   multicast group specified as one of the Target addresses, the router
   considers itself a Target and processes the received DIO as specified
   in Section 9.5."

and then Section 9.5 describes how P2P-DRO is generated.

[Peter]

[Mukul]
As I said above, I think the P2P-RPL text is clear about it.

[Peter]
The source receives as many DROs with at most 4 routes as there are 
members of the multicast group.

[Mukul]
If the Origin wants each Target (which, as per definition in Section 2, is "the IPv6 router at the other end point of the P2P route(s) to be discovered"; hence a multicast TargetAddr specifies multiple Targets) to send back 4 source routes.

[Peter] 
 That changes the restriction of "four 
source routes per target" into "four source routes per unicast 
destination". 

[Mukul]
I wonder what sense "four source routes per multicast group" would make? I think "four source routes per target/unicast-dest" is fine if that is what Origin wants. Origin can ask for "one source route per target/unicast-dest" if that is what it wants.

[Peter] 
There is probably no technical limitation to the MC 
address but I would suggest also site-local and link-local MC addresses, 
given that rpl-p2p focusses on routing within a mesh, when routing via 
the root (edge router) gives unnecessary overhead.

[Mukul]
Not sure what you mean.

Thanks
Mukul

> From the text it is not clear for me what the authors intended.
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: peter van der Stok <[email-masked]>
Date: Mon, 29 Apr 2013 09:31:26 +0200

Mukul,

Thanks for the detailed pointing out of text.
Not reading the explicit changing of MC address to unicast address in 
the RDO at arrival at the target, I read the text as being valid for the 
unicast case, with the multicast case left open.

My mistake,

Greetings,

peter

Mukul Goyal schreef op 2013-04-26 17:06:
> If the Origin wants each Target (which, as per definition in Section
> 2, is "the IPv6 router at the other end point of the P2P route(s) to
> be discovered"; hence a multicast TargetAddr specifies multiple
> Targets) to send back 4 source routes.
> 
> [Peter]
> I wonder what sense "four source routes per multicast group" would
> make? I think "four source routes per target/unicast-dest" is fine if
> that is what Origin wants. Origin can ask for "one source route per
> target/unicast-dest" if that is what it wants.
> 
> [Peter]