Re: [Roll] Review of draft-ietf-roll-dao-projection

["Pascal Thubert (pthubert)" <[e-mail]>]

Very Cool Anand!

I added:


" Extending RFC 6550

   This specification extends RPL [RPL] to enable the Root to install
   east-west routes inside a main DODAG that is operated as non-storing
   mode.  A Projected DAO (P-DAO) message contains a new Via Information
   Option that can be seen as a multihop Transit Information Option and
   installs a strict or a loose sequence of hops to form a track Segment
   or a Track Leg. A P-DAO Request (PDR) message enables a Track Ingress
   to request the Track from the Root.  In the context of this
   specification, the installed route appears as a more specific route
   to the Track targets, and the Track ingress routes all the packets
   towards the targets are routed via the Track.

   To ensure that the PDR and P-DAO messages can flow at all time, it is
   RECOMMENDED that the nodes involved in a Track mantain multiple
   parents in the main DODAG, advertise them all to the Root, and use
   them in turn to retry similar packets.  It is also RECOMMENDED that
   the Root uses diverse source route paths to retry similar messages ot
   the nodes in the Track.

"

Take care,

Pascal

> -----Original Message-----
> From: Roll <[e-mail]> On Behalf Of S.V.R.Anand
> Sent: dimanche 29 août 2021 12:27
> To: Routing Over Low power and Lossy networks <[e-mail]>
> Subject: Re: [Roll] Review of draft-ietf-roll-dao-projection
> 
> Hello Pascal,
> 
> Thank you very much for addressing my concern and you can proceed with the
> publication without further delay :)
> 
> > What I do not see is the need for extra work to protect the path from the
> root to the node, but I agree that we could indicate that the node should
> advertise more than one parent and the root should retry over diverse SR
> paths, if that’s your point?
> >
> 
> Yes, the above indicative text will be very helpful as we are not ignoring
> the coupling effect. While the draft need not go into the specifics of all
> the possibilties, I feel bringing out the core issue is important.
> 
> Regards
> Anand
> 
> On 21-08-29 09:40:57, Pascal Thubert (pthubert) wrote:
> >
> >
> > Hello Anand,
> >
> > Certains the main DAG will undergo changes and transient localized
> failures.
> >
> > Since there is no objective of RAW on the main DAG we’re ok. In those
> transient times the Root will not be able to see trouble in a Track and the
> Track will have to survive on its redundancy.
> >
> > RPL already enables redundancy between the root and a node, it’s up to
> the root to select one of the possible source route path that it sees.
> >
> > If the Root completely looses connectivity to a node in a Track, it may
> not be able to clean it instantly but it can route around it. I have a lot
> of new text on maintenance that we’ll discuss it at the interim.
> >
> > What I do not see is the need for extra work to protect the path from the
> root to the node, but I agree that we could indicate that the node should
> advertise more than one parent and the root should retry over diverse SR
> paths, if that’s your point?
> >
> > Please let me know, I’d wish to publish Monday :)
> >
> > Keep safe,
> >
> > Pascal
> >
> > > Le 27 août 2021 à 08:04, S.V.R.Anand
> <anandsvr=[e-mail]> a écrit :
> > >
> > > Hello Michael, and all,
> > >
> > > At the time of writing the paper, we also wrote up first-cut version
> > > of the draft. But we never got to publish it in any of the working
> groups.
> > >
> > > I will be very happy to share the draft, which is still in the
> > > nascent form, and get initial feedback on whether it is suitable for an
> RFC.
> > >
> > > Regards
> > > Anand
> > >
> > >> On Wed, Aug 25, 2021 at 03:00:32PM -0400, Michael Richardson wrote:
> > >>
> > >>
> > >> S.V.R.Anand <anandsvr=[e-mail]> wrote:
> > >>> In our lab we developed an in-band OAM telemetry scheme for LLNs
> > >>> that we named it Co-iOAM. The idea is very simple but it has been
> > >>> very effective in monitoring a real-world deployment of
> > >>> RPL/6LoWPAN network that we setup.
> > >>
> > >>> ["Co-iOAM: In-situ telemetry metadata transport for resource
> > >>> constrained networks within IETF standards framework",
> > >>> https://ieeexplore.ieee.org/abstract/document/8328276]
> > >>
> > >> Behind a paywall.
> > >> Is this suitable for an RFC?
> > >>
> > >>
> > >> --
> > >> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT
> consulting )
> > >>           Sandelman Software Works Inc, Ottawa and Worldwide
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >> _______________________________________________
> > >> Roll mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/roll
> > >
> > > _______________________________________________
> > > Roll mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/roll
> > _______________________________________________
> > Roll mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll