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

[Rahul Jadhav <[e-mail]>]

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)
<[e-mail]> wrote:
>
> 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
>
>
> > -----Original Message-----
> > From: Rahul Jadhav <[e-mail]>
> > Sent: mercredi 13 juin 2018 13:58
> > To: Pascal Thubert (pthubert) <[e-mail]>
> > Cc: Routing Over Low power and Lossy networks <[e-mail]>
> > 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?).
> > 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)
> > <[e-mail]> wrote:
> > >
> > > 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 <[e-mail]>
> > > > Sent: mercredi 13 juin 2018 03:55
> > > > To: Routing Over Low power and Lossy networks <[e-mail]>;
> > > > Pascal Thubert (pthubert) <[e-mail]>
> > > > 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.
> > > >
> > > > 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