Subject: [Roll] Transit information option

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Wed, 9 Jun 2010 15:08:16 +0200

Hi All,

A few items that might be worth clarifying in version 09:

- “Transit Information options MAY directly follow the Target option” Is it
really a MAY? If not included it means the path sequence / control /
lifetime are not specified (which seems to contradict section 7.1.4.2).

- “A non-storing node that has more than one DAO parent MAY include a
Transit Information option for each DAO parent as part of the non-storing
Destination Advertisement operation.” Why would a node do that? If a node is
sending a DAO for a specific target to e.g. 2 DAO parents (A and B)
shouldn’t he send one DAO with transit information A (i.e. parent address =
A) to DAO parent A and another DAO with transit information B to DAO parent
B? Otherwise how this would work over multiple hop? Maybe an example of DAO
would help.

- In section 7.1.5 point 2, I assume the node should add a transit
information with its parent before passing the content of the received DAO.
Also do the operation specified on the path control field in the previous
section for storing node also apply in the non-storing case?

- Has the advantage of having multiple DAO parents been assessed with
respect to the added complexity? One could argue that since we take so much
care in selecting a preferred this should be a good enough choice… Similar
to Phil I’m getting worried about the increased complexity.

Best,

Mathilde

http://www.cisco.com/swa/i/logo.gif

Durvy Mathilde
Software Engineer
Technology center

 <mailto:[email-masked]> [email-masked]
Phone: +41 21 822 1725
Mobile: +41 76 396 8116

Cisco Systems International Sàrl
Av. des Uttins, 5
CH-1180 Rolle

 <http://www.cisco.com> Cisco home page

Think before you print.Think before you print.

This e-mail may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or disclosure
by others is strictly prohibited. If you are not the intended recipient (or
authorized to receive for the recipient), please contact the sender by reply
e-mail and delete all copies of this message.

---

From: Philip Levis <[email-masked]>
Date: Wed, 9 Jun 2010 09:27:43 -0700

On Jun 9, 2010, at 6:08 AM, Mathilde Durvy (mdurvy) wrote:

> - “Transit Information options MAY directly follow the Target option” Is it really a MAY? If not included it means the path sequence / control / lifetime are not specified (which seems to contradict section 7.1.4.2).

In non-storing mode, it is definitely a MUST. Storing mode seems like it is a MUST as well...

> - “A non-storing node that has more than one DAO parent MAY include a Transit Information option for each DAO parent as part of the non-storing Destination Advertisement operation.” Why would a node do that? If a node is sending a DAO for a specific target to e.g. 2 DAO parents (A and B) shouldn’t he send one DAO with transit information A (i.e. parent address = A) to DAO parent A and another DAO with transit information B to DAO parent B? Otherwise how this would work over multiple hop? Maybe an example of DAO would help.

> - In section 7.1.5 point 2, I assume the node should add a transit information with its parent before passing the content of the received DAO. Also do the operation specified on the path control field in the previous section for storing node also apply in the non-storing case?

These are good questions. Currently the draft is a bit unclear on whether 

1) a DAO's transit option contains the full source route when it arrives at the DODAG Root, or 
2) the DODAG Root receives just the last downward hops of each node, and stitches together source routes with this information. 

1) seems like a much better idea to me. Note that if it's 2), then in non-storing mode node needs to send a DAO to just one DAO parent, and this DAO can contain the full set of last-hops. What are your thoughts?

> - Has the advantage of having multiple DAO parents been assessed with respect to the added complexity? One could argue that since we take so much care in selecting a preferred this should be a good enough choice… Similar to Phil I’m getting worried about the increased complexity.

But note that in upward routes, there's a parent set. The concern is that the vagaries and unreliability of wireless links call for supporting some degree of path diversity. Most protocols today maintain multiple candidate next hops for this exact reason. Because downward routes start at the endpoints, there needs to be some way to establish multiple routes. Otherwise, when one link breaks and you have to issue a trigger to the entire sub-DODAG.

Phil

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Fri, 11 Jun 2010 16:26:36 +0200

Hi Phil,

Thanks a lot for your answer. Here are my comments:

- "Transit Information options MAY directly follow the Target option" Is it
really a MAY? If not included it means the path sequence / control /
lifetime are not specified (which seems to contradict section 7.1.4.2).

In non-storing mode, it is definitely a MUST. Storing mode seems like it is
a MUST as well...

I think we all agree.

- "A non-storing node that has more than one DAO parent MAY include a
Transit Information option for each DAO parent as part of the non-storing
Destination Advertisement operation." Why would a node do that? If a node is
sending a DAO for a specific target to e.g. 2 DAO parents (A and B)
shouldn't he send one DAO with transit information A (i.e. parent address =
A) to DAO parent A and another DAO with transit information B to DAO parent
B? Otherwise how this would work over multiple hop? Maybe an example of DAO
would help.

1) a DAO's transit option contains the full source route when it arrives at
the DODAG Root, or 

2) the DODAG Root receives just the last downward hops of each node, and
stitches together source routes with this information. 

1) seems like a much better idea to me. Note that if it's 2), then in
non-storing mode node needs to send a DAO to just one DAO parent, and this
DAO can contain the full set of last-hops. What are your thoughts?

Indeed, I think the current draft is a bit unclear. My interpretation when
reading was 1 (probably due mostly to the history of the draft). Now from
your comments I understand what the draft is proposing, namely 2. Thanks for
explaining.

What triggered this change? 

It seems to me that if proper aggregation of the routes is performed (in
particular if in the record route case you can avoid transmitting routes
which are sub-routes of others) the two schemes could actually be quite
similar in terms of overhead. This would need to be confirmed by a careful
study as it could depend quite on bit on the topology. What is quite clear
is that 2 requires more processing power than 1 as it needs to reassemble
routes from the received information.

Also concerning your last comment, I agree. The DAO produced will be
slightly larger but we send only one DAO instead of one DAO per DAO parent.
I think if we do that we might not really need the path control field,
correct?

- Has the advantage of having multiple DAO parents been assessed with
respect to the added complexity? One could argue that since we take so much
care in selecting a preferred this should be a good enough choice. Similar
to Phil I'm getting worried about the increased complexity.

But note that in upward routes, there's a parent set. The concern is that
the vagaries and unreliability of wireless links call for supporting some
degree of path diversity. Most protocols today maintain multiple candidate
next hops for this exact reason. Because downward routes start at the
endpoints, there needs to be some way to establish multiple routes.
Otherwise, when one link breaks and you have to issue a trigger to the
entire sub-DODAG.

I understand how this would work in the storing case but in the non-storing
case how would you know at the root that the path failed?

Best,

Mathilde

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 11 Jun 2010 17:32:36 +0200

Hi Mathilde

These are good questions. Currently the draft is a bit unclear on
whether 

1) a DAO's transit option contains the full source route when it arrives
at the DODAG Root, or 

1) seems like a much better idea to me. Note that if it's 2), then in
non-storing mode node needs to send a DAO to just one DAO parent, and
this DAO can contain the full set of last-hops. What are your thoughts?

Indeed, I think the current draft is a bit unclear. My interpretation
when reading was 1 (probably due mostly to the history of the draft).
Now from your comments I understand what the draft is proposing, namely
2. Thanks for explaining.

[Pascal] Savings. Prior to the change, each node would have to pass its
full path up, through all the path. This created a hall of a lot of
duplicate information from which the root had to dig updates.

Now, as you see, a node can just send one DAO about its list of parent
and we're all set.

It seems to me that if proper aggregation of the routes is performed (in
particular if in the record route case you can avoid transmitting routes
which are sub-routes of others) the two schemes could actually be quite
similar in terms of overhead. This would need to be confirmed by a
careful study as it could depend quite on bit on the topology. What is
quite clear is that 2 requires more processing power than 1 as it needs
to reassemble routes from the received information.

[Pascal] It is a simple recursive lookup. Any RIB does that. On the
other hand, getting a change in a source route path and trying to
figure:

-          If is is an alt or a change

-          What other paths are impacted to which other destinations

Well, that was difficult

Also concerning your last comment, I agree. The DAO produced will be
slightly larger but we send only one DAO instead of one DAO per DAO
parent. I think if we do that we might not really need the path control
field, correct?

[Pascal] The path control field will be different for all parents. The
root will find the highest preference there. In the recursive lookup
where it builds the RH4, the root will always select the highest
preference.

Upon an ICMP telling that a hop is failing, it will establish a
temporary bypass using a lesser preference. Upon a DAO where the parent
is not listed anymore, the root will remove the one hop route from the
RIB.

- Has the advantage of having multiple DAO parents been assessed with
respect to the added complexity? One could argue that since we take so
much care in selecting a preferred this should be a good enough
choice... Similar to Phil I'm getting worried about the increased
complexity.

But note that in upward routes, there's a parent set. The concern is
that the vagaries and unreliability of wireless links call for
supporting some degree of path diversity. Most protocols today maintain
multiple candidate next hops for this exact reason. Because downward
routes start at the endpoints, there needs to be some way to establish
multiple routes. Otherwise, when one link breaks and you have to issue a
trigger to the entire sub-DODAG.

I understand how this would work in the storing case but in the
non-storing case how would you know at the root that the path failed?

[Pascal] Good question; I think that the proposal on the table is an
ICMP back, since this is similar to unreachable. 

Best,

Mathilde

---

From: Philip Levis <[email-masked]>
Date: Fri, 11 Jun 2010 09:10:21 -0700

On Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) wrote:

> Indeed, I think the current draft is a bit unclear. My interpretation when reading was 1 (probably due mostly to the history of the draft). Now from your comments I understand what the draft is proposing, namely 2. Thanks for explaining.
> It seems to me that if proper aggregation of the routes is performed (in particular if in the record route case you can avoid transmitting routes which are sub-routes of others) the two schemes could actually be quite similar in terms of overhead. This would need to be confirmed by a careful study as it could depend quite on bit on the topology. What is quite clear is that 2 requires more processing power than 1 as it needs to reassemble routes from the received information.
> Also concerning your last comment, I agree. The DAO produced will be slightly larger but we send only one DAO instead of one DAO per DAO parent. I think if we do that we might not really need the path control field, correct?

-09 has a rewrite of the Downward Routes section that should make all of this much clearer. The answer is 2), for reasons Richard brought up a few months ago. In particular, if you use 1), then when a node changes its parent set it entire sub-DODAG must resend DAOs. This is a significant cost. If you use 2), then only that node needs to send a new DAO.

> I understand how this would work in the storing case but in the non-storing case how would you know at the root that the path failed?

ICMP error.

Phil

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Fri, 18 Jun 2010 11:09:04 +0200

Hi All,

I just looked at the updated draft and most of the comments below have been
addresses / clarified. Just a few rather minor points:

- Section 5.7.7. RPL Target. Based on the discussion below I would change "A
set of one or more Transit Information options MAY directly follow the
Target option in a DAO message" to "a RPL Target Option in a unicast DAO
MUST be followed by a set of one or more Transit Information Option ".

- If the Path-Sequence / Control fields are indeed used both in storing
(where I have doubts they are really needed) and non-storing mode, why not
put them in the target option rather than in the transit option. This way we
could maybe only use only the target option in storing mode and the
target+transit option in non-storing mode. This would have the additional
benefit of making the parent address mandatory in the transit information
option and thus avoid a variable length option.

Best,

Mathilde

From: Philip Levis [mailto:[email-masked]] 
Sent: vendredi, 11. juin 2010 18:10
To: Mathilde Durvy (mdurvy)
Cc: [email-masked]
Subject: Re: [Roll] Transit information option

Hi Phil,

I think we all agree.

-09 has a rewrite of the Downward Routes section that should make all of
this much clearer. The answer is 2), for reasons Richard brought up a few
months ago. In particular, if you use 1), then when a node changes its
parent set it entire sub-DODAG must resend DAOs. This is a significant cost.
If you use 2), then only that node needs to send a new DAO.

ICMP error.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Fri, 18 Jun 2010 19:44:08 +0200

fair comment.

On Jun 18, 2010, at 11:09 AM, Mathilde Durvy (mdurvy) wrote:

> Hi All,
>
> I just looked at the updated draft and most of the comments below  
> have been addresses / clarified. Just a few rather minor points:
> - Section 5.7.7. RPL Target. Based on the discussion below I would  
> change “A set of one or more Transit Information options MAY  
> directly follow the Target option in a DAO message” to “a RPL Target  
> Option in a unicast DAO MUST be followed by a set of one or more  
> Transit Information Option ”.
> - If the Path-Sequence / Control fields are indeed used both in  
> storing (where I have doubts they are really needed) and non-storing  
> mode, why not put them in the target option rather than in the  
> transit option. This way we could maybe only use only the target  
> option in storing mode and the target+transit option in non-storing  
> mode. This would have the additional benefit of making the parent  
> address mandatory in the transit information option and thus avoid a  
> variable length option.
>
> Best,
> Mathilde
>
>
> - “Transit Information options MAY directly follow the Target  
> option” Is it really a MAY? If not included it means the path  
> sequence / control / lifetime are not specified (which seems to  
> contradict section 7.1.4.2).
> - “A non-storing node that has more than one DAO parent MAY include  
> a Transit Information option for each DAO parent as part of the non- 
> storing Destination Advertisement operation.” Why would a node do  
> that? If a node is sending a DAO for a specific target to e.g. 2 DAO  
> parents (A and B) shouldn’t he send one DAO with transit information  
> A (i.e. parent address = A) to DAO parent A and another DAO with  
> transit information B to DAO parent B? Otherwise how this would work  
> over multiple hop? Maybe an example of DAO would help.
> information with its parent before passing the content of the  
> received DAO. Also do the operation specified on the path control  
> field in the previous section for storing node also apply in the non- 
> storing case?
>
> 2) the DODAG Root receives just the last downward hops of each node,  
> and stitches together source routes with this information.
> 1) seems like a much better idea to me. Note that if it's 2), then  
> in non-storing mode node needs to send a DAO to just one DAO parent,  
> and this DAO can contain the full set of last-hops. What are your  
> thoughts?
>
> Indeed, I think the current draft is a bit unclear. My  
> interpretation when reading was 1 (probably due mostly to the  
> history of the draft). Now from your comments I understand what the  
> draft is proposing, namely 2. Thanks for explaining.
> It seems to me that if proper aggregation of the routes is performed  
> (in particular if in the record route case you can avoid  
> transmitting routes which are sub-routes of others) the two schemes  
> could actually be quite similar in terms of overhead. This would  
> need to be confirmed by a careful study as it could depend quite on  
> bit on the topology. What is quite clear is that 2 requires more  
> processing power than 1 as it needs to reassemble routes from the  
> received information.
> parent. I think if we do that we might not really need the path  
> control field, correct?
>
> -09 has a rewrite of the Downward Routes section that should make  
> all of this much clearer. The answer is 2), for reasons Richard  
> brought up a few months ago. In particular, if you use 1), then when  
> a node changes its parent set it entire sub-DODAG must resend DAOs.  
> This is a significant cost. If you use 2), then only that node needs  
> to send a new DAO.
>
>
>
>
>
> - Has the advantage of having multiple DAO parents been assessed  
> with respect to the added complexity? One could argue that since we  
> take so much care in selecting a preferred this should be a good  
> enough choice… Similar to Phil I’m getting worried about the  
> increased complexity.
>
> supporting some degree of path diversity. Most protocols today  
> maintain multiple candidate next hops for this exact reason. Because  
> downward routes start at the endpoints, there needs to be some way  
> to establish multiple routes. Otherwise, when one link breaks and  
> you have to issue a trigger to the entire sub-DODAG.
> I understand how this would work in the storing case but in the non- 
> storing case how would you know at the root that the path failed?
>
> ICMP error.
>
> Phil
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll