Subject: [Roll] DAO Projection - identifying storing, non-storing P-DAO

From: Rahul Jadhav <[email-masked]>
Date: Wed, 13 Jun 2018 07:24:56 +0530

Hello Pascal, WG,

When i started implementing storing mode P-DAO, i faced one problem,
... as per the draft the only way to identify storing P-DAO from
non-storing P-DAO is that storing P-DAO has at-least 2 VIOs whereas
non-storing P-DAO has only one VIO.
The problem with implementation is that i need to traverse the whole
P-DAO before i know whether it is storing or non-storing P-DAO and
populate the route table accordingly. This way either i have
to buffer VIO/via temporarily and then act. Otherwise i have to have a
2-pass traversal through the P-DAO to check whether it is storing or
non-storing first and then act on the fields in later pass.

If we can have a flag somewhere in the P-DAO header to signal storing
or non-storing then it would make implementation much simpler.

For interested ones, part implementation of DAO projection code is at:
https://github.com/whitefield-framework/contiki/tree/dao_projection
It currently supports registration/unregistration of projected routes
using non-storing P-DAO with +/- ACKing.

Regards,
Rahul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 13 Jun 2018 09:24:31 +0000

I agree Rahul, 

I picked that method as a starting point but as I presented at the IETF meeting I do not like it either, and it would be great that the group come up with something better.

Would you have a particular preference based on your experience here?

Pascal

> -----Original Message-----
> From: Rahul Jadhav <[email-masked]>
> Sent: mercredi 13 juin 2018 03:55
> To: Routing Over Low power and Lossy networks <[email-masked]>; Pascal
> Thubert (pthubert) <[email-masked]>
> Subject: DAO Projection - identifying storing, non-storing P-DAO
> 
> Hello Pascal, WG,
> 
> When i started implementing storing mode P-DAO, i faced one problem, ... as
> per the draft the only way to identify storing P-DAO from non-storing P-DAO
> is that storing P-DAO has at-least 2 VIOs whereas non-storing P-DAO has only
> one VIO.
> The problem with implementation is that i need to traverse the whole P-DAO
> before i know whether it is storing or non-storing P-DAO and populate the
> route table accordingly. This way either i have to buffer VIO/via temporarily
> and then act. Otherwise i have to have a 2-pass traversal through the P-DAO
> to check whether it is storing or non-storing first and then act on the fields in
> later pass.
> 
> If we can have a flag somewhere in the P-DAO header to signal storing or non-
> storing then it would make implementation much simpler.
> 
> It currently supports registration/unregistration of projected routes using
> non-storing P-DAO with +/- ACKing.
> 
> Regards,
> Rahul

---

From: Rahul Jadhav <[email-masked]>
Date: Wed, 13 Jun 2018 17:28:14 +0530

One thing that comes to my mind is using DAO base object bits... But i
m not sure if they can/should be expended for such purpose.
Another option is to use TIO bits and make TIO mandatory preceding the
VIOs ... Other fields such as path-seq/lifetime can also be removed
from VIO and can be kept only in TIO. Anyways having a different
Path-Sequence in individual VIOs does not help (not sure if having a
different path lifetime in individual VIO is needed?).
For current implementation, i m planning to go ahead with an extra
pass/traversal over the options to check for multiple VIOs.
 On Wed, 13 Jun 2018 at 14:54, Pascal Thubert (pthubert)

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 13 Jun 2018 12:35:39 +0000

Hello Rahul:

As you figured, the original intent was to replace the TIO by a VIO. So yes, your proposal is workable.
An alternate could be to define a source-routed VIO (SRVIO) with Type = 0xB and keep the current VIO for storing mode only.

What do you think?

Pascal

> Sent: mercredi 13 juin 2018 13:58
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: Routing Over Low power and Lossy networks <[email-masked]>
> Subject: Re: DAO Projection - identifying storing, non-storing P-DAO
> 
> One thing that comes to my mind is using DAO base object bits... But i m not
> sure if they can/should be expended for such purpose.
> Another option is to use TIO bits and make TIO mandatory preceding the VIOs
> ... Other fields such as path-seq/lifetime can also be removed from VIO and
> can be kept only in TIO. Anyways having a different Path-Sequence in
> individual VIOs does not help (not sure if having a different path lifetime in
> individual VIO is needed?).
> > I picked that method as a starting point but as I presented at the IETF
> meeting I do not like it either, and it would be great that the group come up
> with something better.
> >
> > > To: Routing Over Low power and Lossy networks <[email-masked]>;
> > > Pascal Thubert (pthubert) <[email-masked]>
> > > populate the route table accordingly. This way either i have to
> > > buffer VIO/via temporarily and then act. Otherwise i have to have a
> > > If we can have a flag somewhere in the P-DAO header to signal
> > > storing or non- storing then it would make implementation much simpler.
> > >
> > > It currently supports registration/unregistration of projected
> > > routes using non-storing P-DAO with +/- ACKing.
> > >
> > > Regards,
> > > Rahul

---

From: Rahul Jadhav <[email-masked]>
Date: Thu, 14 Jun 2018 09:56:45 +0530

Yes, using new type (SRVIO) is a better idea.
Thus we can have SRVIO and VIO for non-storing and storing mode
respectively and these options will be mutually exclusive .. i.e. when
SRVIO is sent, there should not be any VIO in the DAO and vice-versa.

For storing mode P-DAO,no is there a reason to have multiple VIOs? I
mean, can we keep multiple vias in the same VIO? The reason for doing
this is, currently we have different path-seq/lifetime per VIO and
having it separately does not help. I m not sure what an
implementation can do with different path-seq values in multiple VIO
for the same target from the same originator.
On Wed, 13 Jun 2018 at 18:06, Pascal Thubert (pthubert)

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 14 Jun 2018 06:44:14 +0000

Hello Rahul

I think one intent was to easily snip snap the extra VIOs once they are consumed if we decided to do so. At the moment a node locates itself so it does not matter but that may be impractical.. 
With a single VIO that would mean either massage the VIO to shrink it (and then lose chances to sign from the root in the future) or to have an segment-used field like Routing Headers do.

Another intent was to indicate a shorter lifetime when closer to egress. The point being that the route must disappear at ingress before it disappears at egress, otherwise loops may form. 
We need to add words on that.

What do you think?

Pascal

> Sent: jeudi 14 juin 2018 06:27
> respectively and these options will be mutually exclusive .. i.e. when SRVIO is
> sent, there should not be any VIO in the DAO and vice-versa.
> 
> For storing mode P-DAO,no is there a reason to have multiple VIOs? I mean,
> can we keep multiple vias in the same VIO? The reason for doing this is,
> currently we have different path-seq/lifetime per VIO and having it separately
> does not help. I m not sure what an implementation can do with different
> path-seq values in multiple VIO for the same target from the same originator.
> > An alternate could be to define a source-routed VIO (SRVIO) with Type = 0xB
> and keep the current VIO for storing mode only.
> >
> > What do you think?
> >
> > Pascal
> >
> >
> > > One thing that comes to my mind is using DAO base object bits... But
> > > i m not sure if they can/should be expended for such purpose.
> > > Another option is to use TIO bits and make TIO mandatory preceding
> > > the VIOs ... Other fields such as path-seq/lifetime can also be
> > > removed from VIO and can be kept only in TIO. Anyways having a
> > > different Path-Sequence in individual VIOs does not help (not sure
> > > if having a different path lifetime in individual VIO is needed?).
> > > meeting I do not like it either, and it would be great that the
> > > group come up with something better.
> > > >
> > > > > When i started implementing storing mode P-DAO, i faced one
> > > > > problem, ... as per the draft the only way to identify storing
> > > > > P-DAO from non-storing P-DAO is that storing P-DAO has at-least
> > > > > 2 VIOs whereas non-storing P-DAO has only one VIO.
> > > > > The problem with implementation is that i need to traverse the
> > > > > whole P-DAO before i know whether it is storing or non-storing
> > > > > P-DAO and populate the route table accordingly. This way either
> > > > > i have to buffer VIO/via temporarily and then act. Otherwise i
> > > > > have to have a 2-pass traversal through the P-DAO to check
> > > > > whether it is storing or non-storing first and then act on the fields in
> later pass.
> > > > >
> > > > > https://github.com/whitefield-framework/contiki/tree/dao_project
> > > > > ion It currently supports registration/unregistration of
> > > > > projected routes using non-storing P-DAO with +/- ACKing.
> > > > >
> > > > > Regards,
> > > > > Rahul

---

From: Rahul Jadhav <[email-masked]>
Date: Thu, 14 Jun 2018 15:33:34 +0530

If we have to snip-snap, then VIO or via wont matter since the DAO
contents will be changed in either case. Do you mean that the VIOs can
be individually signed since they are containerized unlike via?
I m also not sure if loops can be avoided by indicating shorter
lifetime when closer to egress. Imo, the bigger questions for loop
formation are:
a. when the nodes along the projected segment change their parent
affiliation because of path changes...
b. route invalidation fails midway for the projected segment...
c. If the loop gets formed ... is there a detection scheme (like we
have for storing mode) and any contingency handling thereafter?

Also there is still the question of what to do with multiple
path-sequences in multiple VIOs?

Regards,
Rahul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 18 Jun 2018 14:20:32 +0000

Dear all:

To address Rahul's points, I added the generic term of RPO as follows:

"

   This specification introduces 2 new Control Message Options to be used as

   Route Projection Options (RPO). One RPO is the Information option (VIO) and

   the other is the Source-Routed VIO (SRVIO). The VIO installs a route on each

   hop along a projected route (in a fashion analogous to RPL Storing Mode)

   whereas the SRVIO installs a state at the ingress which uses it to insert a

   a routing header in a fashion similar to RPL Non-Storing Mode.

"

Writing new text for this, a few possibilities come to mind:

1) making the  RPOs factorizable. With the VIO/SRVIO separation, and all the via addresses listed in a row, 2 RPOs can mean 2 alternate paths to get to the target. I already added text accordingly:

"

    Like the TIO, the RPOs MUST be preceded by one or more RPL Target options to

    which they apply, and they can be factorized: multiple contiguous RPOs

    indicate alternate paths to the target(s).

"

2) uses VIO and SRVIO as alternates. If we allow the above, can we allow also that the alternate paths are of different types? Right now the text is silent, which kinda hints that you could...

3) intra DODAG routes vs. Inter DODAG routes. As the draft stands now, a P-route is constrained in a DDAG. With a PCE that has a more global view, the P-route could potentially span more than one DODAG. Should we consider this? Note: We’d need an “external” VIO.

What do you all think?

Pascal

> > As you figured, the original intent was to replace the TIO by a VIO. So yes,

> your proposal is workable.

> > > One thing that comes to my mind is using DAO base object bits... But i m

> not

> VIOs

> > > ... Other fields such as path-seq/lifetime can also be removed from VIO

> and

> > > meeting I do not like it either, and it would be great that the group come

> up

> problem,

> > > > > storing or non- storing then it would make implementation much

> simpler.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 19 Jun 2018 10:24:17 +0000

Hello Rahul:

I published a 04 adding the SRVIO.

Now, we need to agree on whether a P-DAO can have more than one VIO and if we can mix SRVIO and VIO in a same P-DAO.
We also need to work on routes that would span more than one DODAG, right now the draft does not allow for that.
Finally, the draft needs hardening on loop avoidance.

Comments welcome as usual!

Pascal