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

[Michael Richardson <[e-mail]>]

S.V.R.Anand <anandsvr=[e-mail]> wrote:
    > 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 :)

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

I think that this is a good point.  We do need that telemetry.
At the stupidest side of things, the root can assume a group of identical 6LN
(same resources), and given an initial non-storing mode, knows most of entire
topology, and knows that the FIB is empty.

I think that any PCE needs to communicate with the RPL ROOT to translate, as
Pascal suggested.  That protocol is probably missing.
Maybe we can adapt P-DAO into a proxy version, and we should probably think
about that now.

The telemetry protocol is, I think, tied up/related to capex.
Is it the same reply process, or a protocol that capex discovers, I'm not
sure.  I know that the telemetry has been done by a view vendors in
proprietary fashion, and going back 10 years, we talked about SNMP for that
too.

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

I think that yes, but only via the PCE talking to the DODAG root.

    > - 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 is a bootstrap of the connectivity.
There is also an onboarding challenge.
There is a recovery from failure issue.  But, if you can keep the "SDN"^WPCE
controller path alive without RPL, then please... write a draft :-)

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

Perhaps the biggest issue here is not that the delay could be indeterminate,
but rather that I'm not sure we have a positive confirmation that it has been
done.

    > - 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 we use the P-DAO message being forwarded as indication to kick creation
of the track?

    > - 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 think that RPL has a challenge with this kind of mobile situation.

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

Two things can happen: it gets there (possibly via the Root), or it finds a
loop, and causes repair.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide