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

From: "S.V.R.Anand" <[email-masked]>
Date: Sun, 22 Aug 2021 10:43:55 +0530

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 23 Aug 2021 14:02:56 +0000

Hello Anand,

Good to hear from you, been a while. Many thanks for your review!

> architecture. I thoroughly enjoyed reading the draft :)

Neat, thanks!

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

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

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

>   minimize these delays ? Should we have dedicated tracks for signaling

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? 

>   sending P-DAO message. In some sense there is a dependency of one on

There is indeed. I can add more words on that too. This can be done together with your other suggestions below.

>   A short note on the issues that need to be addressed to support

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?

>   What is the consequence of this action on the ongoing data that is

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.

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

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

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

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

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?

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

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "S.V.R.Anand" <[email-masked]>
Date: Mon, 23 Aug 2021 22:39:26 +0530

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

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

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

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'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 actu…

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 ? 

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

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.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Aug 2021 13:50:43 -0400

> architecture. I thoroughly enjoyed reading the draft :)

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

    > controls network resources for the entire network.

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

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

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

    > sending P-DAO message. In some sense there is a dependency of one on

Can we use the P-DAO message being forwarded as indication to kick creation
of the track?

    > A short note on the issues that need to be addressed to support mobility could

I think that RPL has a challenge with this kind of mobile situation.

    > What is the consequence of this action on the ongoing data that is already in

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

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

---

From: "S.V.R.Anand" <[email-masked]>
Date: Wed, 25 Aug 2021 22:11:01 +0530

Hello Michael,

Very interesting points! Few additional thoughts in-line.

Regards
Anand

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

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

> but rather that I'm not sure we have a positive confirmation that it has been

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. 

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 25 Aug 2021 17:02:54 +0000

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

All this is covered by the text above

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

"

> > 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.
> >
> >
> > >
> > 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?
> >
> 
> 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:
 
> > There is indeed. I can add more words on that too. This can be done
> together with your other suggestions below.
> >
> >
> >
> > 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.

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Aug 2021 15:00:32 -0400

> https://ieeexplore.ieee.org/abstract/document/8328276]

Behind a paywall.
Is this suitable for an RFC?

---

From: "S.V.R.Anand" <[email-masked]>
Date: Thu, 26 Aug 2021 21:40:13 +0530

Hello Pascal,

Thank you very much! 

All the changes look good to me except one specific point mentioned
in-line for which you might want to provide additional text. 

Regards
Anand

> Please let me know if you're OK with that text;

The above text looks fine.

>    destination that is reachable over the Track will be injected in the

It certainly is an important text. But I am not sure if it addresses my
concern which has to do with topology changes that can occur in the RPL
DODAG due to frequent changes in the available radio resources because
of track management activities by PCE. The RPL ranks will
undergo changes causing path recomputation so as to maintain the OFs of
the RPL Instances in operation. Am I missing something while reading
your modified text ?

>    list sends the DAO-ACK back to the Root.

Looks good :)

---

From: "S.V.R.Anand" <[email-masked]>
Date: Fri, 27 Aug 2021 11:33:15 +0530

Hello Michael, and all,

At the time of writing the paper, we also wrote up first-cut version of the
draft. But we never got to publish it in any of the working groups.

I will be very happy to share the draft, which is still in the nascent form, and
get initial feedback on whether it is suitable for an RFC.

Regards
Anand

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 29 Aug 2021 09:40:57 +0000

Hello Anand,

Certains the main DAG will undergo changes and transient localized failures. 

Since there is no objective of RAW on the main DAG we’re ok. In those transient times the Root will not be able to see trouble in a Track and the Track will have to survive on its redundancy.

RPL already enables redundancy between the root and a node, it’s up to the root to select one of the possible source route path that it sees.

If the Root completely looses connectivity to a node in a Track, it may not be able to clean it instantly but it can route around it. I have a lot of new text on maintenance that we’ll discuss it at the interim.

What I do not see is the need for extra work to protect the path from the root to the node, but I agree that we could indicate that the node should advertise more than one parent and the root should retry over diverse SR paths, if that’s your point?

Please let me know, I’d wish to publish Monday :)

Keep safe,

Pascal

> Le 27 août 2021 à 08:04, S.V.R.Anand <anandsvr=[email-masked]> a écrit :
> 
> Hello Michael, and all,
>

---

From: "S.V.R.Anand" <[email-masked]>
Date: Sun, 29 Aug 2021 15:57:05 +0530

Hello Pascal,

Thank you very much for addressing my concern and you can proceed with
the publication without further delay :) 

> What I do not see is the need for extra work to protect the path from the root to the node, but I agree that we could indicate that the node should advertise more than one parent and the root shoul…

Yes, the above indicative text will be very helpful as we are not
ignoring the coupling effect. While the draft need not go into the
specifics of all the possibilties, I feel bringing out the core issue is
important. 

Regards
Anand

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 30 Aug 2021 11:31:32 +0000

Very Cool Anand!

I added:

" Extending RFC 6550

   This specification extends RPL [RPL] to enable the Root to install
   east-west routes inside a main DODAG that is operated as non-storing
   mode.  A Projected DAO (P-DAO) message contains a new Via Information
   Option that can be seen as a multihop Transit Information Option and
   installs a strict or a loose sequence of hops to form a track Segment
   or a Track Leg. A P-DAO Request (PDR) message enables a Track Ingress
   to request the Track from the Root.  In the context of this
   specification, the installed route appears as a more specific route
   to the Track targets, and the Track ingress routes all the packets
   towards the targets are routed via the Track.

   To ensure that the PDR and P-DAO messages can flow at all time, it is
   RECOMMENDED that the nodes involved in a Track mantain multiple
   parents in the main DODAG, advertise them all to the Root, and use
   them in turn to retry similar packets.  It is also RECOMMENDED that
   the Root uses diverse source route paths to retry similar messages ot
   the nodes in the Track.

"

Take care,

Pascal

> -----Original Message-----
> From: Roll <[email-masked]> On Behalf Of S.V.R.Anand
> Sent: dimanche 29 août 2021 12:27
> To: Routing Over Low power and Lossy networks <[email-masked]>
> Subject: Re: [Roll] Review of draft-ietf-roll-dao-projection
> 
> Hello Pascal,
> 
> Thank you very much for addressing my concern and you can proceed with the
> publication without further delay :)
> 
> > What I do not see is the need for extra work to protect the path from the
> root to the node, but I agree that we could indicate that the node should
> advertise more than one parent and the root should retry over diverse SR
> paths, if that’s your point?
> >
> 
> Yes, the above indicative text will be very helpful as we are not ignoring
> the coupling effect. While the draft need not go into the specifics of all
> the possibilties, I feel bringing out the core issue is important.
> 
> Regards
> Anand
> 
> > Since there is no objective of RAW on the main DAG we’re ok. In those
> transient times the Root will not be able to see trouble in a Track and the
> Track will have to survive on its redundancy.
> >
> > RPL already enables redundancy between the root and a node, it’s up to
> the root to select one of the possible source route path that it sees.
> >
> > If the Root completely looses connectivity to a node in a Track, it may
> not be able to clean it instantly but it can route around it. I have a lot
> of new text on maintenance that we’ll discuss it at the interim.
> >
> > What I do not see is the need for extra work to protect the path from the
> root to the node, but I agree that we could indicate that the node should
> advertise more than one parent and the root should retry over diverse SR
> paths, if that’s your point?
> >
> > > Le 27 août 2021 à 08:04, S.V.R.Anand
> <anandsvr=[email-masked]> a écrit :
> > >
> > > Hello Michael, and all,
> > >
> > > At the time of writing the paper, we also wrote up first-cut version
> > > of the draft. But we never got to publish it in any of the working
> groups.
> > >
> > > I will be very happy to share the draft, which is still in the
> > > nascent form, and get initial feedback on whether it is suitable for an
> RFC.
> > >
> > > Regards
> > > Anand
> > >
> > >>> 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",