Re: [Roll] ROLL WG Last Call on draft-ietf-roll-p2p-measurement-04

Hi Phil

Thanks for pointing out the problem.

>1) The originator specifies the metrics of interest and nodes update this value as they generate responses/replies. Part of the challenge here is a question of whether one is measuring the forward or reverse route, something the document should be clearer on. This has the advantage that it requires less coordination and specification with respect to RPL and OFs. It has the disadvantage that a node could request a metric the network does not support.

This is what we have in mind. I will make it clear in the next revision of the draft. Also, I will clarify that the route being measured is the one in forward direction (from the origin to the target) and an intermediate router MUST drop a Measurement Request if it cannot update (or add local value to) a routing metric specified inside the Metric Container.

Thanks
Mukul 

----- Original Message -----
From: "Philip Levis" <pal@cs.stanford.edu>
To: "ROLL WG" <roll@ietf.org>
Sent: Friday, March 16, 2012 2:50:51 PM
Subject: Re: [Roll] ROLL WG Last Call on draft-ietf-roll-p2p-measurement-04

Comments on p2p-measurement:

Overall this draft is very solid. It sets out a very simple mechanism and its options. The use cases are especially helpful.

The one major thing that seems to be missing in the document, however, is exactly how one populates and updates the metric container. For example, what metrics should a node put into the metric container? The metrics that the DODAG root is advertising for that RPL Instance? What happens if the network is using MRHOF and so ETX directly through Rank? The only text I can find is the last paragraph of 5.0:

"   Next, the router MUST update the routing metric objects, contained in
   the Metric Container options inside the MO, either by updating the
   aggregated value for the routing metric or by attaching the local
   values for the metric inside the object.  After updating the routing
   metrics, the router MUST unicast the MO to the next hop."

Is it that the metric container behavior is specified elsewhere? If not, then it's possible for a node meeting this document specification to do whatever it wants with the metric container. I can see a few options:

1) The originator specifies the metrics of interest and nodes update this value as they generate responses/replies. Part of the challenge here is a question of whether one is measuring the forward or reverse route, something the document should be clearer on. This has the advantage that it requires less coordination and specification with respect to RPL and OFs. It has the disadvantage that a node could request a metric the network does not support.

2) All nodes follow the metrics in DIOs. This has the advantage that the ability to handle these metrics is well defined by a RPL instance. It has the disadvantage that it requires coordinating how OFs manage metrics with path discovery.

Phil
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll