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

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

Hello again Anand

I added text in the intro to cover some of our discussion as follows :
"

   There specification considers that there's a unique PCE with full
   view of the network.  Distributing the function for a large network
   is out of scope.  This specification uses the RPL Root as a proxy to
   the PCE.  The PCE may be collocated with the Root, or may reside in
   an external Controller.  In that case, the protocol between the Root
   and the PCE is out of scope and abstracted by / mapped to RPL inside
   the DODAG.

   The algorithm to compute the paths and the protocol used by an
   external PCE to obtain the topology of the network from the Root are
   also out of scope.  The effectiveness of the route computation by the
   PCE depends on the quality of the metrics that are reported from the
   RPL network.  Which metrics are used and how they are reported is out
   of scope, but the expectation is that they are mostly of statistical
   nature, and provide visibility on link throughput, latency, stability
   and availability over relatively long periods, more in [RAW-ARCHI].
"
Please let me know if you're OK with that text;

> >
> > > For an effective operation of P-DAO route projection, one of the
> > > keys requirements is the presence of network monitoring mechanisms
> > > for LLNs in place for letting PCE have a complete view of the
> > > network state. I
> >
> > Very true...
> >
> >
> > > am not sure if we can assume that such OAM mechanisms are already in
> > > place for LLNs as the track setup and its maintenance are closely
> > > dependent on these.
> >
> > That too. The combo of this draft and RAW assumes that the PCE gets long
> term stats and availability information, and computes routes based on that.
> >
> >
> >  The effectiveness of the external route computation
> > > by PCE is tightly coupled with  network resources required for
> > > monitoring the network state, stability of the wireless links and
> > > delay in obtaining the network state information, and so on.
> > > Strictly speaking, this important functionality is a pre-requisite
> > > for implementing the draft.
> >
> > Yes; the PCE computation can be proprietary since it is inside the box so
> arguably the missing link is the metrics and formats to be reported. Should
> we do that in the same doc (complexity rising) or should we separate a new
> draft like RFC 6551 vs 6550? I'm tempted to do the latter.
> >
> > For now the PCE can live with existing link-related network management
> information to compute its routes.
> >
> >

All this is covered by the text above

> > >
> > > I list down few questions that came to mind after reading the draft.
> > >
> > > - Does the draft allow for the co-existence of centrally orchestrated
> > >   tracks and distributed RPL operate within the same network ? Since
> > >   draft does not say explicitly, is it reasonable to expect that
> > > both can
> > >   be present together ? If the answer is yes, then the draft
> > >   needs to mention the effect of PCE on RPL managed routes, if PCE
> > >   controls network resources for the entire network.
> >
> > Well, the assumption is that the root is really a proxy for the PCE,
> turning whatever abstraction the PCE uses into RPL.
> > See the intro:
> > "                                                       This document
> >    specifies protocol extensions to RPL [RPL] that enable the Root of a
> >    main DODAG to install centrally-computed routes inside the DODAG on
> >    behalf of a PCE.
> > "
> >
> > If your question is what if both the Root and an external PCE compute
> routes, well that's beyond this work. This would mean syncing and
> negotiating the use of constrained resources.
> 
> Yes, as you noted, my question is the latter where both Root and PCE are in
> operation. There will be a continuous churning of the RPL maintained routes
> whenever PCE re-provisions network resources for its own purposes. It is
> hard to maintain the objective functions of the RPL instances. How do we
> then resolve this possible situation in the context of current work ? Once
> the proposed mechanism allows for the co-existence of centralized and
> distributed routing mechanisms, then we need to worry about protecting RPL
> routes. Can the draft say something about it so that implementors are aware
> of the scope of the work ?



For one thing the PCE may run inside or outside the Root device, but there can be only one, and the new text clarifies that.
About the relationship of the 2 types of routes, this is like TE routes in a SP network, and multi topology routing. We have to ensure that we're not creating loop, and ultimately provide policies to select traffic that is injected in Tracks; in the context of this draft, we're just adding routes that have a highest precedence and go all the way to the destination, so we get there quickly in non-storing mode, and we know there's no loop in storing mode. Remote LFA would avoid that constraint at the expense of higher complexity.

I added

"
   This specification enables to combine one or more Projected Routes
   into a DODAG called a Track, that is traversed to reach the Targets.
   When the main RPL domain is operated in non-storing mode, a Track
   provides reachability to one or more destinations within the DODAG,
   which bypasses the Root and improves the latency for the redirected
   flows.  Note that this specification does not provide policies to
   decide which flows go in which Track.  Routes to specific
   destinations over a Track are always more specific than the default
   via the Root, and any packet reaching the Track Ingress for a
   destination that is reachable over the Track will be injected in the
   Track.

"

> > > - Curious question closely related to the above. If one decides to
> > > use PCE in
> > >   conjunction with P-DAO to centrally manage the entire network and
> > > thereby
> > >   aligning ourselves close to RAW architecture (Refer to Profile 3 and
> > >   above of Section 8), and not use distributed routing at all,
> > >   full-blown RPL seems to offer minimal benefits here. Why not use
> > > the compute
> > >   and memory for the purpose of implementing RAW mechanisms ?
> >
> > I think that's the same point that the Root is really a proxy forwarding
> in RPL parlance the abstract route decisions by the PCE. This is enables a
> simpler operation with less code in the devices.
> >
> >
> > >
> > > - There could be non-negligible indeterministic delays in setting up
> > > on-demand tracks
> > >   before the data starts flowing. Can the draft touch upon the
> > > possible ways to
> > >   minimize these delays ? Should we have dedicated tracks for
> > > signaling purposes ?
> >
> > Oh, interesting. Usually such thing happens with a net priority QoS.
> Maintaining dedicated tracks may be fragile, since they would be needed to
> repair themselves. True that the draft says nothing about that. I agree it
> should. Any suggestion?
> >
> 
> One suggestion is to identify and maintain dedicated reliable signaling
> tracks with minimal resources to cater to latency critical tracks that may
> be setup in near or far future. These special signaling tracks, as decided
> by application requirements, can use redundancy so that the tracks are
> always available.
> 

I added

"
  This specification extends the DAO message with the Projected DAO
   (P-DAO); a P-DAO message signals a Projected Route to one or more
   Targets using the new CMOs presented therein.  This provides a RPL-
   based signaling to build the Tracks as designed in the 6TiSCH
   Architecture [6TiSCH-ARCHI].  The Track may be set up for many
   reasons, including as a bypass to lower the load at the Root, or to
   enable urgent traffic to flow more directly.  The signaling should
   not be stuck behind high traffic levels.  The expectation is that the
   P-DAO message is sent as high QoS level, above that of data traffic,
   typically the Network Control precedence."

I'm not convinced by Tracks to configure Tracks. Quis custodiet ipsos custodes?
This addresses also your comment below:
 
> > > - 6TiSCH has been mentioned just in the introduction. It would be
> > > nice to associate
> > >   it with the P-DAO track installation process. A 6TiSCH track needs
> > > to be
> > >   setup depending on the application bandwidth and delay
> > > requirements before
> > >   sending P-DAO message. In some sense there is a dependency of one
> > > on the other.
> >
> > There is indeed. I can add more words on that too. This can be done
> together with your other suggestions below.
> >
> >
> >
> > > - Can the scope of the draft be extend to mobile scenarios, for
> > > instance, networked
> > >   robotics applications ? These present additional challenges in the
> > > form of
> > >   frequent topological changes causing flurry of network state, and
> > > track updates.
> > >   A short note on the issues that need to be addressed to support
> > > mobility could
> > >   be useful.
> >
> >
> > I've worked on interesting techniques that could apply. What strikes me
> is that you're describing an applicability draft as opposed to modifying
> the specification. Could some of your proposals actually become the subject
> of yet another draft, this time on applicability of P-DAO?
> >
> 
> I agree with your view.

Let's keep a note to start that doc asap.

> 
> What about P-DAO for mobility as an independent draft ? There you might
> want to describe the techniques you have developed.
> 
> I am not in favor stuffing-in all the interesting opportunities into the
> current draft. Can you introduce a "Scope" section where the applicability
> of P-DAO is mentioned ?
> 
> >
> > >
> > > - There could be situations where the Root can decide to modify the
> > > already
> > >   installed routes asynchronously to maintain the Objective
> > > Function/QoS of the tracks.
> > >   What is the consequence of this action on the ongoing data that is
> > > already in
> > >   transit ?
> >
> > We're in RAW territory here. I'd say that the PCE/Root only updates
> segments at a time so the parallel ways still operate nominally and enable
> the continuous service. One the additional path is installed, the Root can
> swap the Track (the source routed thingy) to use the new segments. All in
> all, with the redundancy that we can expect here, it seems doable to do it
> live.
> >
> 
> Yes, RAW territory indeed. I am strictly going by the abstract of the draft
> :)
> 
> Since Root/PCE does not know if the track is currently engaged, route
> modification which includes deletion of the routing entry can potentially
> result in data loss if we don't do what you suggested above.
> I think including some text helps in answering a natural "what if" question
> that I got.
> 
> 

OK, I'm adding a "Maintaining a Track" section as follows:

"

7.4.  Maintaining a Track

   Adding or rerouting a Track may affect the traffic that is
   transported over the Track, e.g., packets can be misordered if the
   new path is faster than the old.  For critical flows that require
   timely and/or in-order delivery, it might be necessary to deploy the
   PAREO functions [RAW-ARCHI] over a highly redundant Track.

   This specification allows to add subTracks to a Track by sending a
   non-storing mode P-DAO to the ingress associated to the same TrackID,
   and a new Segment ID.  It is also possible to replace a subTrack by
   sending a non-storing mode P-DAO to the ingress with the same Segment
   ID as the replaced subTrack and an incremented Segment Sequence.

   This specification also allows to add Segments to an existing Track
   by first installing the new Segment(s) with one Storing-Mode P-DAO
   each associated to the same TrackID, and then joining with a subTrack
   signaled by a non-storing mode P-DAO to the ingress and also
   associated to the same TrackID.  That subTrack may be an addition to
   the Track or a replacement, as indicated above.
   A misbehaving Segment may be modified by injecting a new Storing-Mode
   P-DAO, with the same SegmentID and an incremented Segment Sequence.
   The new Segment MUST be installed with the full new path from the
   Segment Ingress to Egress, both included.  When a node that is on
   both the old and the new Segments this updates the state associated
   to the path.

   Once the new segment is installed, the sequences of nodes that are no
   more in the Segment MUST be removed one contiguous sequence at a
   time, with the one or more nodes listed in the SF-VIO, and a Segment
   Lifetime of 0.  Nodes along the sequence clean up their state and
   pass the message to the previous node in the list; the first is the
   list sends the DAO-ACK back to the Root.
"

Are we getting there?

Keep safe;

Pascal