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

Hello Pascal,

Thank you very much for quickly responding to my review. We are almost
in sync. Let me present my thoughts to some of your responses below.

Regards
Anand

On 21-08-23 14:02:56, Pascal Thubert (pthubert) wrote:
> 
> 
> Hello Anand,
> 
> Good to hear from you, been a while. Many thanks for your review!
> 
> Let's see below:
> 
> 
> > Thanks a lot to the authors for writing up this important draft towards
> > building a deterministic network and thereby aligning ourselves to RAW
> > architecture. I thoroughly enjoyed reading the draft :)
> 
> Neat, thanks!
> 
> 
> > 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.
> 
> 
> >
> > 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 ?

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

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

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.

> 
> 
> > ----------------------------------------------------------------------
> >
> > Section 1. Introduction
> >
> > The text needs to be re-structured to make the flow smooth. The current
> > text starts off with RPL, abruptly introduces 6TiSCH, moves to DetNet
> > and PCE.
> >
> > One suggestion. The text can upfront state that IoT applications that
> > require deterministic network behavior are well supported by centrally
> > orchestrated network route and bandwidth resource management over PCE.
> > Then introduce 6TiSCH, followed by how RPL is an enabler for route
> > installation.
> >
> > The term "Root" in the Introduction attains special meaning. Is the
> > capitalization required here ?
> 
> Great suggestion, I'll work on it.
> 
> >
> > 3.1
> > ---
> >
> > "The Track Ingress is signaled in the DODAGID field of the Projected
> > DAO Base Object; that field is elided in the case of the main RPL
> > Instance."
> >
> > Shouldn't it be "global RPL Instance" ?
> 
> It's still the main, and it's true that the main is a global in the use cases I have in mind.
> Basically the Tracks are built within a larger DODAG that encompasses the nodes in the Tracks and allows to configure them.
> 
> 
> >
> > 6.1 New P-DAO Request Control Message
> > -------------------------------------
> >
> > Is there a timeout for getting PDR-ACK message ? If so, what is the
> > value of the re-transmission interval ?
> 
> There must be but the value can be very different with use cases; same as RPL we avoid giving values here.
> 
> 
> 
> >
> > One would have assumed to see QoS specification as part of the PDR sent
> > out by Track Ingress node to establish Track. The Root will then come
> > up with an appropriate route and bandwidth allocation that meets the
> > required QoS.
> 
> Yes. We probably need to define a QoS level for the whole signaling.
> 
> 
> >
> > After the Track is setup, what if Track Ingress wants to request for
> > additional or less network resources as per the application
> > requirements ? Does it mean tear down the existing Track and sending
> > new PDR all over ? Is there a way of requesting for additional
> > resources ?
> 
> Again RAW territory. There is no concept of distributing the load so we can add / remove resources and do load balancing as well as PAREO. There is no text on policies at all, whether that describes using network coding etc... I agree with the need, and would think that this belongs to RAW. Here we set up the routes but not the ingress policies.
> 
> At the moment every packet for which the Track is the route is injected in the Track and flooded. RAW can add:
> - a subTrack selected by the PSE within the Track (already in the archi)
> - load balancing and network coding so as to use more bandwidth in parallel (can add text in the archi)
> 
> 
> For ROLL: if the RAW policies can do load balancing, I agree that the PDR / PDR ack should indicate the required resources and the requested changes. Same point as before, it might makes sense to make all the metrics and sizing a separate draft (the RFC 6551 of the day), to reduce the complexity / load on this one.
> 
> 
> 
> >
> > 6.3 Via Information Options
> > ---------------------------
> >
> > I suppose we can assume that these options are part of PDR-ACK Control
> > Message.
> 
> The idea was that the PDR ACK to the Track Ingress indicates the trackID, and that a non-storing P-DAO to the Track Ingress for that Track ID has the SR-VIOs. Are you suggesting a change?
> 
> >
> > 7.1
> > ----
> >
> > Expand GUA and ULA in their first occurrence.
> 
> Will do
> 
> >
> > 8. Profiles
> > ------------
> >
> > OLD: "This sections described profiles that can be implemented
> > separately  and can be used to discriminate what an implementation can
> > and cannot  do."
> >
> > NEW: "This section describes profiles..."
> >
> 
> OK
> 
> I'll be editing once we agree on the details like the 2 drafts that your discussion seems to siuggest.
> 
> Take care, Anand.
> 
> Pascal
> 
> > _______________________________________________
> > Roll mailing list
> > Roll@ietf.org
> > https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll