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

["S.V.R.Anand" <[e-mail]>]

Dear Authors,

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 :)

Hope the following feedback will be helpful. 

Regards
Anand


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

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.

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

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

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

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

----------------------------------------------------------------------

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 ?

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" ? 

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 ?

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. 

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 ?

6.3 Via Information Options
---------------------------

I suppose we can assume that these options are part of PDR-ACK Control Message.

7.1
----

Expand GUA and ULA in their first occurrence.

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