Subject: Re: [Roll] Route Projection

From: "Turner, Randy" <[email-masked]>
Date: Sat, 1 Apr 2017 07:42:41 +0000

Hi Pascal

Yes, I think your suggestion where we add an option to the DAO seems like a reasonable approach to informing the root of node capabilities- seems like this could be in the same document. We have intermediate routers in our AMI mesh that are more capable in terms of resources than our standard endpoints. In certain scenarios they may could benefit from projection.

I guess we need a metric definition for "node capability". Does it only specify RAM capacity for storing routes? Is this metric an absolute number or is it relative to other nodes in the mesh? In addition to storage capability do we include other node capability? (Maybe a small number of extensible attribute bits for the node to say something like "I'm battery or mains powered" or some other bit of information that would allow the root (or maybe a PCE) to make more informed decisions about it treats a node.

Randy

On Apr 1, 2017, at 1:50 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Hello Randy:

The projected route may be computed based on a current state of the dodag but once installed it does not depend on its variation. IOW if a node moves packets end in the bucket just like for a stale route.

But if the projected route still works, the root does not need to react immediately to the churn in the dodag.

As you point out, SDN and high mobility are not really friendly. So yes, this technique is more appropriate for stable networks. We should add words on that in the draft.

More critical is to define the way the root learns the topology and node capacity.

Should (some of) that be in the same document?

Take care,

Pascal

Le 1 avr. 2017 à 02:26, Turner, Randy <[email-masked]<mailto:[email-masked]>> a écrit :

Hi All,

After hearing the presentation on RPL route projection, I just wanted to clarify that, if this technique was utilized in a network that (for whatever reason) was experiencing a situation where routers were frequently changing parents and/or re-establishing routes, then this would invalidate the projected routes in the effected parts of the network (where the routes were changing) - in addition to re-establishing the routes through normal DAO/DAO-ACK, the root would also have to re-project any previously projected routes.  If this is indeed the case, I'm assuming the root may elect to avoid projecting routes in these types of scenarios.

At the moment, I'm only talking about non-storing mode...

Thx,

Randy

_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

---

From: peter van der Stok <[email-masked]>
Date: Mon, 03 Apr 2017 08:49:31 +0200

> Should (some of) that be in the same document?

Does AODV-RPL not describe a method to detect new routes?
Could AODV-RPL not make use of DAO projection?

Peter

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 3 Apr 2017 09:59:09 +0000

Hello Peter:

DAO Projection is a centralized approach whereas AODV-RPL and classical RPL are distributed, respectively proactive and reactive. So DAO Projection is really its own category vs. the others, enabling for instance traffic engineering and determinism.

 As described,  DAO Projection is reactive, which may explain the analogy that you see between the two?

Take care,

Pascal

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]] 
Sent: lundi 3 avril 2017 01:50
To: Routing Over Low power and Lossy networks <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>
Subject: Re: [Roll] Route Projection and AODV-RPL

Peter

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Apr 2017 13:31:25 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > But if the projected route still works, the root does not need to
    > react immediately to the churn in the dodag.

But, if the route does not work, what do we do?
I would assume go back to the un-projected route.
Do we need to notify the root that this is occuring?

The root may see it in the form of increased consumption of resources further
up, but maybe it won't be looking for that kind of thing often enough.

    > Should (some of) that be in the same document?

I think that we should do discovery of topology and node capacity in
a different document.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Apr 2017 07:47:50 +0000

Hello Michael:

 <Pascal>
In non-storing mode of the main DODAG operation, a node that cannot forward a packet should notify the root (ICMP error), and the root should fix its ways. The root does all the routing so in the end it should be able to design a working network.

In Storing MOP, this can be more of an issue. 

On the one hand, it might be that a node cannot forward, as above. The normal reaction in that MOP is to flag the packet and send it back to the previous node, which cleans up its DAO state. This could probably work here too, when the projected route is not source routed. When it is source routed, should we go 1) to the node that added the source route (probably but that may be a long a path via the root), 2) to the root (which is good iff the root was the one that projected that source route path, but how can we know) or 3) should we reverse the SRH? I'd go for 1) which is the cleanest way... 

And OTOH, it might be that packets loop because the state in the root and the state in the nodes are not consistent, as Rahul raised at the ROLL meeting at IETF 98. Since this is designed for shortcuts, we may leverage small hop count. We could enforce that a packet that is routed by projection cannot be routed again by normal DAO. What do people think?
</Pascal>

The root may see it in the form of increased consumption of resources further up, but maybe it won't be looking for that kind of thing often enough.

<Pascal>

That's a bit too indirect. We want explicit signaling once a route that is broken is being used.

</Pascal>

    > Should (some of) that be in the same document?

I think that we should do discovery of topology and node capacity in a different document.

<Pascal>

Then we need to start that document. We could always merge before shipping, but yes, it would be good to go through the WG process of adoption etc... 

Do we have volunteers?

</Pascal>
--
Take care,

Pascal