Subject: Re: [Roll] Issue 59 on Transit information option

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 13 Jul 2010 14:10:12 +0200

Hi Mathilde

Thanks for your great help; I hope more people will follow your example
so we can deeply clean up the spec during the round. please find below:

Thanks again for your reply. What you say makes sense although I still
think that the separation of the fields between the target and transit
options is somewhat arbitrary J However this is not a major issue and
maybe at this point it's more important to clarify the specs with
respect to the meaning / usage of the path sequence, control, and
lifetime.

[Pascal] Yes; at the end of the day the path control really had to be in
the transit with the parent. Leaving the target without any bit allows
us to add more headers that would also qualify that target and thus
factorise.

- In storing mode, the path control is used to limit the DAO fan-out. It
can also be used to set a preference between routes with the limitation
that it cannot specify two routes which are equally preferred (since
path control bits sent to different parents have to be disjoint). 

[Pascal] We have to see that. ecmp should be acceptable. We have an
active thread on path control, lets deal with that there.

- It seems to me that the path control usage is incompatible with the
sentence "If a node sends a DAO to one DAO parent, it MUST send a DAO
with the same DAOSequence to all other DAO parents". No?

[Pascal] The sequence that we are talking about now is probably the path
sequence, right? Can you please elaborate on the issue?

- In the non storing mode, the path control is not used to limit the DAO
fan-out as nodes send DAOs to only one of their DAO parents. I guess it
can be used as a preference by the root when it computes the source
routes.

[Pascal] Yes

- How is the path sequence processed? Given that we have already a DAO
sequence is it possible to receive a stale path sequence? Isn't it
redundant? 

[Pascal] I expect not. But the node may have a stale state from that
needs to be deprecated. By deprecated I mean that the router should stop
forwarding through a node child that has last presented path sequence 21
as soon as  another child presents sequence  22 or more for a same
target. This indicates that in a DAG, a new path sequence should rapidly
cause a DAO. In a tree, that is less urgent.

- What does the lifetime represent concretely? Is it a measure of the
lifetime of the link between the target and the transit?

[Pascal] the lifetime is important for 2 things at least:

-          Flush. A lifetime of 0 is a route flush. That is how we do
no-path.

-          Seq number validation. The path lifetime covers the path
sequence so that in normal operations, the path sequence should not be
incremented by 16 during a lifetime, so we should never see path
sequence numbers that are out of sync by more than 16. 

It's a lot of questions, but I hope it will help make the DAO part
clearer to everybody!

[Pascal] including the editors since the doc belongs to the group.

Best,

Mathilde

From: Pascal Thubert (pthubert) 
Sent: mercredi, 7. juillet 2010 09:22
To: Mathilde Durvy (mdurvy); 'ROLL WG'
Subject: RE: [Roll] FW: Transit information option

Hi Mathilde,

1) In storing mode, the transit information "parent address" is not used

You're correct on that with the current spec. 

I'm pointing out that in some cases we are missing the info for the
tunnel endpoint and that it might become handy to indicate a RPL router
to which a target host is attached.

2)    Hence the pattern would be (Target+) for storing and
(Target+,Transit+)+ for non-storing.

We want to factorise: in non-storing mode, the target can have multiple
parents each one with a different path control.  

In storing mode, a router with multiple interfaces can place multiple
targets for all its addresses and then only one transit info that is
common to them all.

Pascal

From: Mathilde Durvy (mdurvy) 
Sent: Tuesday, July 06, 2010 4:47 PM
To: Pascal Thubert (pthubert); 'ROLL WG'
Subject: RE: [Roll] FW: Transit information option

Hi Pascal,

My point is a bit different.

In storing mode, the transit information "parent address" is not used.
The only fields that are relevant in the transit information are the
path control, sequence, and lifetime, which actually relate to the
target prefix. So why not put these fields in the target option and use
only the transit option when we are in non-storing mode and hence need
to specify a parent address?

Hence the pattern would be (Target+) for storing and (Target+,Transit+)+
for non-storing.

Does this make sense?

Best,

Mathilde

From: Pascal Thubert (pthubert) 
Sent: mardi, 6. juillet 2010 15:44
To: Mathilde Durvy (mdurvy); ROLL WG
Subject: RE: [Roll] FW: Transit information option

Hi Mathilde:

Pls note that the target identifies the final destination and the
transit tells you about how you get there. So you can factorize
optimally depending on what you are doing.

We have issue 55 that should cover your proposed change. AS Phil pointed
out, The pattern is really (Target+, Transit+)+. 

I tend to think that the parent is needed in storing mode to indicate
the tunnel end point for targets outside the RPL network, like the
proverbial dumb host attached to a RPL router. 

What do you think?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mathilde Durvy (mdurvy)
Sent: Tuesday, July 06, 2010 3:25 PM
To: ROLL WG
Subject: [Roll] FW: Transit information option

Hi All,

I didn't see these comments addressed in the new draft. Any reason? 

For point 2, I would go even further and propose to put the path
sequence, control, and lifetime fields in the Target option and keep
only the parent address field in the Transit option.

Let me add that the sentence "In a DIO, the RPL Target Option identifies
a resource that the root is trying to reach" should be removed if I
believe the list of options allowed for DIO.

Best,

Mathilde

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

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

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

Hi Phil,

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

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

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.

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

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?

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

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?

ICMP error.

Phil

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Thu, 15 Jul 2010 14:42:37 +0200

Hi Pascal,

To answer your question:

- It seems to me that the path control usage is incompatible with the
sentence "If a node sends a DAO to one DAO parent, it MUST send a DAO with
the same DAOSequence to all other DAO parents". No?

My point was not so much about the "sequence". What I meant is that if the
path control has 1 bit set and you have 2 parents, you will send a DAO to
one parent without sending "to all other parents" no?

Best,

Mathilde

From: Pascal Thubert (pthubert) 
Sent: mardi, 13. juillet 2010 14:10
To: Mathilde Durvy (mdurvy); JP Vasseur
Cc: [email-masked]
Subject: RE: [Roll] Issue 59 on Transit information option

Hi Mathilde

Thanks for your great help; I hope more people will follow your example so
we can deeply clean up the spec during the round. please find below:

Thanks again for your reply. What you say makes sense although I still think
that the separation of the fields between the target and transit options is
somewhat arbitrary J However this is not a major issue and maybe at this
point it's more important to clarify the specs with respect to the meaning /
usage of the path sequence, control, and lifetime.

[Pascal] Yes; at the end of the day the path control really had to be in the
transit with the parent. Leaving the target without any bit allows us to add
more headers that would also qualify that target and thus factorise.

- In storing mode, the path control is used to limit the DAO fan-out. It can
also be used to set a preference between routes with the limitation that it
cannot specify two routes which are equally preferred (since path control
bits sent to different parents have to be disjoint). 

[Pascal] We have to see that. ecmp should be acceptable. We have an active
thread on path control, lets deal with that there.

- It seems to me that the path control usage is incompatible with the
sentence "If a node sends a DAO to one DAO parent, it MUST send a DAO with
the same DAOSequence to all other DAO parents". No?

- In the non storing mode, the path control is not used to limit the DAO
fan-out as nodes send DAOs to only one of their DAO parents. I guess it can
be used as a preference by the root when it computes the source routes.

[Pascal] Yes

[Pascal] I expect not. But the node may have a stale state from that needs
to be deprecated. By deprecated I mean that the router should stop
forwarding through a node child that has last presented path sequence 21 as
soon as  another child presents sequence  22 or more for a same target. This
indicates that in a DAG, a new path sequence should rapidly cause a DAO. In
a tree, that is less urgent.

-          Seq number validation. The path lifetime covers the path sequence
so that in normal operations, the path sequence should not be incremented by
16 during a lifetime, so we should never see path sequence numbers that are
out of sync by more than 16. 

It's a lot of questions, but I hope it will help make the DAO part clearer
to everybody!

Best,

Mathilde

Hi Mathilde,

I'm pointing out that in some cases we are missing the info for the tunnel
endpoint and that it might become handy to indicate a RPL router to which a
target host is attached.

In storing mode, a router with multiple interfaces can place multiple
targets for all its addresses and then only one transit info that is common
to them all.

Pascal

Hi Pascal,

In storing mode, the transit information "parent address" is not used. The
only fields that are relevant in the transit information are the path
control, sequence, and lifetime, which actually relate to the target prefix.
So why not put these fields in the target option and use only the transit
option when we are in non-storing mode and hence need to specify a parent
address?

Hence the pattern would be (Target+) for storing and (Target+,Transit+)+ for
non-storing.

Does this make sense?

Best,

Mathilde

Hi Mathilde:

Pls note that the target identifies the final destination and the transit
tells you about how you get there. So you can factorize optimally depending
on what you are doing.

I tend to think that the parent is needed in storing mode to indicate the
tunnel end point for targets outside the RPL network, like the proverbial
dumb host attached to a RPL router. 

What do you think?

Pascal

Hi All,

For point 2, I would go even further and propose to put the path sequence,
control, and lifetime fields in the Target option and keep only the parent
address field in the Transit option.

Let me add that the sentence "In a DIO, the RPL Target Option identifies a
resource that the root is trying to reach" should be removed if I believe
the list of options allowed for DIO.

Best,

Mathilde

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

 

Hi Phil,

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

- 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 

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.

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.

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

ICMP error.

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 15 Jul 2010 17:06:16 +0200

Ho! I think the confusion is that not all the parents are necessarily
DAO parents. The DAO parents are the subset of parents to which DAO are
sent (in storing) or about whom DAO are sent (in non storing). So in
your example there would be only one. But the sentence can be improved
by saying that all DAOs sent at the same time are sent with the same
sequence in order to build multiple paths.

Pascal

From: Mathilde Durvy (mdurvy) 
Sent: Thursday, July 15, 2010 2:43 PM
To: Pascal Thubert (pthubert); 'JP Vasseur'
Cc: [email-masked]'
Subject: RE: [Roll] Issue 59 on Transit information option

Hi Pascal,

To answer your question:

My point was not so much about the "sequence". What I meant is that if
the path control has 1 bit set and you have 2 parents, you will send a
DAO to one parent without sending "to all other parents" no?

Best,

Mathilde

Hi Mathilde

[Pascal] Yes

Best,

Mathilde

Hi Mathilde,

Pascal

Hi Pascal,

Does this make sense?

Best,

Mathilde

Hi Mathilde:

What do you think?

Pascal

Hi All,

Best,

Mathilde

Hi All,

Best,

Mathilde

 

Hi Phil,

I think we all agree.

 

ICMP error.

Phil

---

From: Tim Winter <[email-masked]>
Date: Thu, 15 Jul 2010 12:37:49 -0400

> sequence in order to build multiple paths.

Yes, and it should also be clarified that if you have more DAO Parents than you can 
allocate Path Control bits for a given Target, then some of those Parents will be 
left out of getting a DAO for that Target.

-Tim

>
> Pascal
>
> *From:* Mathilde Durvy (mdurvy)
> *Sent**:* Thursday, July 15, 2010 2:43 PM
> *To:* Pascal Thubert (pthubert); 'JP Vasseur'
> *Cc:* [email-masked]'
> *Subject:* RE: [Roll] Issue 59 on Transit information option
>
> Hi Pascal,
>
> To answer your question:
>
> sentence “If a node sends a DAO to one DAO parent, it MUST send a DAO
> with the same DAOSequence to all other DAO parents”. No?
>
> */[Pascal] The sequence that we are talking about now is probably the
> path sequence, right? Can you please elaborate on the issue?/*
>
> My point was not so much about the “sequence”. What I meant is that if
> DAO to one parent without sending “to all other parents” no?
>
> Best,
>
> Mathilde
>
> */ /*
>
> *From:* Pascal Thubert (pthubert)
> *Sent:* mardi, 13. juillet 2010 14:10
> *To:* Mathilde Durvy (mdurvy); JP Vasseur
> *Cc:* [email-masked]
> *Subject:* RE: [Roll] Issue 59 on Transit information option
>
> Hi Mathilde
>
> maybe at this point it’s more important to clarify the specs with
> respect to the meaning / usage of the path sequence, control, and lifetime.
>
> */[Pascal] Yes; at the end of the day the path control really had to be
> in the transit with the parent. Leaving the target without any bit
> allows us to add more headers that would also qualify that target and
> thus factorise./*
>
> */[Pascal] We have to see that. ecmp should be acceptable. We have an
> active thread on path control, lets deal with that there./*
>
> sentence “If a node sends a DAO to one DAO parent, it MUST send a DAO
> with the same DAOSequence to all other DAO parents”. No?
>
> */[Pascal] The sequence that we are talking about now is probably the
> path sequence, right? Can you please elaborate on the issue?/*
>
> can be used as a preference by the root when it computes the source routes.
>
> */[Pascal] Yes/*
>
> sequence is it possible to receive a stale path sequence? Isn’t it
> redundant?
>
> */[Pascal] I expect not. But the node may have a stale state from that
> as soon as another child presents sequence 22 or more for a same target.
> This indicates that in a DAG, a new path sequence should rapidly cause a
> DAO. In a tree, that is less urgent./*
>
> */[Pascal] the lifetime is important for 2 things at least:/*
>
> - Flush. A lifetime of 0 is a route flush. That is how we do no-path.
>
> - Seq number validation. The path lifetime covers the path sequence so
> that in normal operations, the path sequence should not be incremented
> by 16 during a lifetime, so we should never see path sequence numbers
> that are out of sync by more than 16.
>
> It’s a lot of questions, but I hope it will help make the DAO part
> clearer to everybody!
>
> */[Pascal] including the editors since the doc belongs to the group./*
>
> Best,
>
> Mathilde
>
> *From:* Pascal Thubert (pthubert)
> *Sent:* mercredi, 7. juillet 2010 09:22
> *To:* Mathilde Durvy (mdurvy); 'ROLL WG'
> *Subject:* RE: [Roll] FW: Transit information option
>
> Hi Mathilde,
>
> 1) In storing mode, the transit information “parent address” is not used
>
> You’re correct on that with the current spec.
>
> I’m pointing out that in some cases we are missing the info for the
> *From:* Mathilde Durvy (mdurvy)
> *Sent:* Tuesday, July 06, 2010 4:47 PM
> *To:* Pascal Thubert (pthubert); 'ROLL WG'
> *Subject:* RE: [Roll] FW: Transit information option
>
> Hi Pascal,
>
> In storing mode, the transit information “parent address” is not used.
> *From:* Pascal Thubert (pthubert)
> *Sent:* mardi, 6. juillet 2010 15:44
> *To:* Mathilde Durvy (mdurvy); ROLL WG
> *Subject:* RE: [Roll] FW: Transit information option
>
> Hi Mathilde:
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Mathilde Durvy (mdurvy)
> *Sent:* Tuesday, July 06, 2010 3:25 PM
> *To:* ROLL WG
> *Subject:* [Roll] FW: Transit information option
>
> Hi All,
>
> I didn’t see these comments addressed in the new draft. Any reason?
>
> Let me add that the sentence “In a DIO, the RPL Target Option identifies
> a resource that the root is trying to reach” should be removed if I
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Mathilde Durvy (mdurvy)
> *Sent:* vendredi, 18. juin 2010 11:09
> *To:* Philip Levis
> *Cc:* [email-masked]
> *Subject:* Re: [Roll] Transit information option
>
> Hi All,
>
> 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
> Option ”.
> *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
>
> - “Transit Information options MAY directly follow the Target option” Is
> - “A non-storing node that has more than one DAO parent MAY include a
> non-storing Destination Advertisement operation.” Why would a node do
> parents (A and B) shouldn’t he send one DAO with transit information A
> much care in selecting a preferred this should be a good enough choice…
> Similar to Phil I’m getting worried about the increased complexity.
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 16 Jul 2010 16:26:12 +0200

Sure. 

Also this text 

  4.  When a node sends a DAO to one of its DAO parents, it MUST select
       one or more of the set, active bits in the aggregated Path
       Control field.  The DAO it transmits to its parent MUST have
       these active bits set and all other active bits cleared.

Can be misleading. My understanding is that attributing one or more PCF
bits to one parent  locks them so they cannot be passed to another
parent, correct?

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tim
> Winter
> Sent: Thursday, July 15, 2010 6:38 PM
> To: [email-masked]
> Subject: Re: [Roll] Issue 59 on Transit information option
> 
> 
> 
> > DAO parents. The DAO parents are the subset of parents to which DAO
> > are sent (in storing) or about whom DAO are sent (in non storing).
So
> > in your example there would be only one. But the sentence can be
> > improved by saying that all DAOs sent at the same time are sent with
> > the same sequence in order to build multiple paths.
> 
> Yes, and it should also be clarified that if you have more DAO Parents
than you
> can allocate Path Control bits for a given Target, then some of those
Parents
> will be left out of getting a DAO for that Target.
> 
> -Tim
> 
> 
> 
> >
> > Pascal
> >
> > Thanks for your great help; I hope more people will follow your
> > example so we can deeply clean up the spec during the round. please
find
> below:
lifetime.
> >
> > */[Pascal] Yes; at the end of the day the path control really had to
> > be in the transit with the parent. Leaving the target without any
bit
> > - In storing mode, the path control is used to limit the DAO
fan-out.
> > It can also be used to set a preference between routes with the
> > limitation that it cannot specify two routes which are equally
> > preferred (since path control bits sent to different parents have to
be
> disjoint).
> > - In the non storing mode, the path control is not used to limit the
> > DAO fan-out as nodes send DAOs to only one of their DAO parents. I
> > guess it can be used as a preference by the root when it computes
the source
> > needs to be deprecated. By deprecated I mean that the router should
> > stop forwarding through a node child that has last presented path
> > sequence 21 as soon as another child presents sequence 22 or more
for a
> same target.
> > This indicates that in a DAG, a new path sequence should rapidly
cause
> > a DAO. In a tree, that is less urgent./*
> >
no-path.
> > - Seq number validation. The path lifetime covers the path sequence
so
> > tunnel endpoint and that it might become handy to indicate a RPL
> > router to which a target host is attached.
> >
> > We want to factorise: in non-storing mode, the target can have
> > multiple parents each one with a different path control.
> >
> > target prefix. So why not put these fields in the target option and
> > use only the transit option when we are in non-storing mode and
hence
> > need to specify a parent address?
> >
> > Hence the pattern would be (Target+) for storing and
> > We have issue 55 that should cover your proposed change. AS Phil
> > pointed out, The pattern is really (Target+, Transit+)+.
> >
> > *From:* [email-masked] [mailto:[email-masked]] *On
> > Behalf Of *Mathilde Durvy (mdurvy)
> > Let me add that the sentence "In a DIO, the RPL Target Option
> > identifies a resource that the root is trying to reach" should be
> > removed if I believe the list of options allowed for DIO.
> >
> > Best,
> >
> > Mathilde
> >
> > *From:* [email-masked] [mailto:[email-masked]] *On
> > Behalf Of *Mathilde Durvy (mdurvy)
> > 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.
> > - "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...
> > 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.
> >
> > 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.
> >
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.
> >

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 16 Jul 2010 17:10:37 +0200

Apart from the clarification, I'd really like to enable Equal Cost
Multipath as Mathilde suggested.
Could we say that 2 consecutive bits 0-1, 2-3, 4-5, and 6-7 represent
paths of equal preference? That leaves us 4 degrees of preference which
is probably enough.
Ideas?

Pascal

Of Tim
So
than you
Parents
find
lifetime.
bit
fan-out.
be
the source
for a
cause
no-path.
so
hence
in
transit option.
in
option.
option"
section
like
transmitting
actually
confirmed
as
all
up
a
complexity.
to

---

From: "Alexander, Roger" <[email-masked]>
Date: Mon, 19 Jul 2010 18:24:33 -0400

I think equal cost multipath is a worthwhile objective. However, there
is a question as to what extent must equal-cost be enforced? It may
require at each hop that equal-cost be enforced by ensuring that DAOs of
'equal' preference always be sent to DAO Parents that are of equal rank.
As a result, to ensure that paths are indeed equal cost, a node may be
forced to send two DAOs to the same DAO Parent, even where multiple DAO
Parents exist, if none of alternative DAO Parents are of equal rank to
the selected DAO Parent. The net effect could be to reduce path
diversity. Alternatively, there can be less precision in the enforcement
of equal-cost with the corresponding softness in path preference
extending also to the preferred path. 

Roger 

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Pascal Thubert (pthubert)
> Sent: Friday, July 16, 2010 11:11 AM
> To: Tim Winter; [email-masked]
> > > My point was not so much about the "sequence". What I meant is
that
> if
> > > the path control has 1 bit set and you have 2 parents, you will
> send
> a
sequence
> > > 1) In storing mode, the transit information "parent address" is
not
> > > used
> > > - "A non-storing node that has more than one DAO parent MAY
include
> > > parents (A and B) shouldn't he send one DAO with transit
> information
> A
> > > respect to the added complexity? One could argue that since we
take

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 20 Jul 2010 09:08:26 +0200

Hi Roger:

On board with the latter. We can't have much precision here. But I'd
like to be able to make a difference between a strict order an loose
equivalence. If parent A and parent B give me an approximately equal
metric set downwards, then I do not necessarily want to impose an order.
Do you see an issue with the idea that says that the path control bits
are paired for roughly equivalent parents? The consequence is probably
that we'd have to skip (not use) some bits when there is not a second
equivalent parent, but I fail to see that as a problem. I do not expect
a real case to fan out more than 3 or 4 parents anyway. 

Do I miss something?

Pascal

> From: Alexander, Roger [mailto:[email-masked]]
> Sent: Tuesday, July 20, 2010 12:25 AM
> To: Pascal Thubert (pthubert); Tim Winter; [email-masked]
is a
> question as to what extent must equal-cost be enforced? It may require
at each
> hop that equal-cost be enforced by ensuring that DAOs of 'equal'
preference
> always be sent to DAO Parents that are of equal rank.
forced to
> send two DAOs to the same DAO Parent, even where multiple DAO Parents
> exist, if none of alternative DAO Parents are of equal rank to the
selected DAO
> Parent. The net effect could be to reduce path diversity.
Alternatively, there
> can be less precision in the enforcement of equal-cost with the
corresponding
> softness in path preference extending also to the preferred path.
> 
> Roger
> 
> > > > - It seems to me that the path control usage is incompatible
with
> > the
> > > > sentence "If a node sends a DAO to one DAO parent, it MUST send
a
> > DAO
> > > > */[Pascal] The sequence that we are talking about now is
probably
> > the
> > > > options is somewhat arbitrary J However this is not a major
issue
> > and
> > > > */[Pascal] Yes; at the end of the day the path control really
had
> > > > allows us to add more headers that would also qualify that
target
> > and
> > > > preferred (since path control bits sent to different parents
have
> > to
> > be
> > > disjoint).
> > > >
> > > > */[Pascal] We have to see that. ecmp should be acceptable. We
have
> > an
> > > > - It seems to me that the path control usage is incompatible
with
> > the
> > > > sentence "If a node sends a DAO to one DAO parent, it MUST send
a
> > DAO
> > > > */[Pascal] The sequence that we are talking about now is
probably
> > the
> > > > - How is the path sequence processed? Given that we have already
a
> > DAO
> > > > */[Pascal] I expect not. But the node may have a stale state
from
> > > > - What does the lifetime represent concretely? Is it a measure
of
> > the
> > > > targets for all its addresses and then only one transit info
that
> > is
> > > > I just looked at the updated draft and most of the comments
below
> > have
> > > > non-storing Destination Advertisement operation." Why would a
node
> > do
> > > > DAO. Also do the operation specified on the path control field
in
> > the
> > > > 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
> > > > What is quite clear is that 2 requires more processing power
than
> 1
> > > > Also concerning your last comment, I agree. The DAO produced
will
> > > > 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
> > > > But note that in upward routes, there's a parent set. The
concern
> > is

---

From: "Alexander, Roger" <[email-masked]>
Date: Wed, 21 Jul 2010 18:09:02 -0400

Hi Pascal,

I agree that the association of paired path control bits with roughly
equivalent parents will achieve the ability for load balancing even
though there will be occasions where the lack of rough equivalence among
DAO Parents will limit the use of diverse paths. In essence the source
node (that is, the node owner of the given Prefix) will dictate the path
choices by the initial determination of the relative equivalence of DAO
Parents. If equivalent DAO Parents exist at the source node, the
potential will be established to have equal path choices potentially
through the network and at the root. If the source node does not have
equivalent DAO Parents then different bits are set within the path
control field (some bit(s) within the bit pairs not used) and load
balancing is no longer an option across the network or at the DODAG
root. 

Yes, I agree, other than halving the preference to 4 levels, which
should not be much of a concern, the overall fan out control is
maintained together with an option for equal path routing when
equivalent DAO Parent links exist at the source node. Works for me.

Roger

> From: Pascal Thubert (pthubert) [mailto:[email-masked]]
> Sent: Tuesday, July 20, 2010 3:08 AM
> To: Alexander, Roger; Tim Winter; [email-masked]
> > > > > DAO parents. The DAO parents are the subset of parents to
which
> > > > > improved by saying that all DAOs sent at the same time are
sent
> > > > > Thanks again for your reply. What you say makes sense although
> I
> > > still
> > > > > - In the non storing mode, the path control is not used to
> limit
> > > the
> > > > > DAO fan-out as nodes send DAOs to only one of their DAO
> parents.
> I
> > > > > sequence is it possible to receive a stale path sequence?
Isn't
> it
> > > > > I'm pointing out that in some cases we are missing the info
for
> > > > > In storing mode, the transit information "parent address" is
> not
> > > used.
> > > > > The only fields that are relevant in the transit information
> are
> > > the
> > > > > target prefix. So why not put these fields in the target
option
> > > > > sequence, control, and lifetime fields in the Target option
and
> > > keep
> > > > > that? If a node is sending a DAO for a specific target to e.g.
> 2
> > > DAO
> > > > > previous section for storing node also apply in the
non-storing
> > > case?
> > > > > slightly larger but we send only one DAO instead of one DAO
per
> > > > > - Has the advantage of having multiple DAO parents been
> assessed
> > > with