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

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

Hello Michael,

Very interesting points! Few additional thoughts in-line.

Regards
Anand

On 21-08-24 13:50:43, Michael Richardson wrote:
> 
> 
> 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.

Thanks. I feel telemetry is very essential to manage an operational
network, in general. For this draft it is a critical requirement.

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]

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

I see your point. Apart from the functionality that you listed, perhaps
RPL can be used carry telemetry data. PCE-only is still possible, but
would prefer to use RPL for the above reasons. 

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

While reading the draft I too had the doubt regarding the positive
confirmation. But then if Track Ingress Node does not receive PDR-ACK to
its PDR, I would assume it would request again. Further, no news from
the Ingress node can be interpreted as successful track setup. 

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

I too think so. But PCE can come up with few tricks to manage the
mobility, independent of RPL. This was not covered in the current
draft but I am certain Pascal is ready with few techniques already :)

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



> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll