Subject: [Roll] knowing which multiple metrics matter: MRHOF related questions

From: Michael Richardson <[email-masked]>
Date: Fri, 25 May 2012 10:53:51 -0400

Ralph asked some questions a few days ago.
His originally DISCUSS is at:
    http://datatracker.ietf.org/doc/draft-ietf-roll-minrank-hysteresis-of/ballot/

This was my reply.    I am particularly interested in replies from
Pascal, Anders and Mukul about my assertion about how we would never 
pick RPL instances by metrics; that they would in fact be seperate RPL
Instance numbers and DODAG values, and that these things would
provisioned by the network installer.

====

I'm going to reply to your comments in a different order than
you asked them, because I think question #3 is most important, and the
rest fall out of it.

>>>>> "Ralph" == Ralph Droms <[email-masked]> writes:
    Ralph> 3. Based on (1) and (2), would configuration and selection
    Ralph> issues be ameliorated if the five candidate selected metrics
    Ralph> were each asssigned a separate objective function?  Use of a
    Ralph> separate OF code point for each of the five possible selected
    Ralph> metrics would allow multiple RPL instances.

I think that it's important to understand that ROLL has a whole palette
of things that need to be provisioned by the "network operator".

In contrast to the situation of ISPs and customers, where the ISP is the
network operator, ROLL networks are more like highly orchestrated
Enterprises: "all your host belong to us"

so, when we write something like:
    "The metric chosen by the network operator to use for path
    selection."
in section 2, we really mean:
    "The metric chosen by the network operator and provisioned into
    the node when the firmware was flashed to use for path selection."

Ralph> 1.  Why is one objective function defined for several potential
Ralph> metrics?  The details of MRHOF seem to preclude the establishment
Ralph> of several RPL instances in an LLN, each of which uses MRHOF with
Ralph> a different selected metric.

If one had many different RPL Instances, then we would have different
RPL Instance numbers in the RPL header.   There can be many different
DODAG ("destinations") created within that instance.  The instances
share a common set of (provisioned) parameters.

(To put it into DHCP terms: if we have multiple DHCP servers on a link,
 then one would expect them to all offer IP addresses in the same subnet.
 If one wanted to have addresses in different subnets, and let the host
 pick between them, then, one would need different layer-2s: different
 VLANs or ESSIDs, or... )

If you feel that RPL is rather schizo about provisioning vs
configuration, then I agree.  It's not always clear to me why some
things are advertised while others are provisioned.

In BGPv4, we calculate metrics by adding AS entries in the path.
(It's always additive), and we add at least one AS entry to the path.
One can AS-stuff and add more, but proper operation of BGP does not
depend upon the exact algorithm used.

Finally, my impression is that how the various metrics are used (singly,
or in some combination) to calculate Rank Increase is a question of
further research, experimentation, and trade secret.  

So long as the Rank increases, and a node does not flap between parents,
the exact details do not matter.  Each node can do it's parent selection
based upon the available metrics on it's own.  It advertises the metrics
it has.

I hope the authors will correct me if I'm completely off here.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 25 May 2012 16:31:16 +0000

Hi Michael:

I think RPL does not want to take party there. The OF is a piece of logic to tie metrics and policies together. 
As such, there could be multiple metrics as long as there is good logic to tie them in. for instance one would look at optimizing metric A within contraints as expressed by metric B and the OF model will allow that.

OTOH, it a flows requires a certain optimization (say per one metric) and another requires something different, then certainly you want two instances.

So ... it depends!

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: vendredi 25 mai 2012 16:54
To: [email-masked]
Subject: [Roll] knowing which multiple metrics matter: MRHOF related questions

This was my reply.    I am particularly interested in replies from
Pascal, Anders and Mukul about my assertion about how we would never pick RPL instances by metrics; that they would in fact be seperate RPL Instance numbers and DODAG values, and that these things would provisioned by the network installer.

====

I'm going to reply to your comments in a different order than you asked them, because I think question #3 is most important, and the rest fall out of it.

I think that it's important to understand that ROLL has a whole palette of things that need to be provisioned by the "network operator".

In contrast to the situation of ISPs and customers, where the ISP is the network operator, ROLL networks are more like highly orchestrated
Enterprises: "all your host belong to us"

If one had many different RPL Instances, then we would have different
RPL Instance numbers in the RPL header.   There can be many different
DODAG ("destinations") created within that instance.  The instances share a common set of (provisioned) parameters.

(To put it into DHCP terms: if we have multiple DHCP servers on a link,  then one would expect them to all offer IP addresses in the same subnet.
 If one wanted to have addresses in different subnets, and let the host  pick between them, then, one would need different layer-2s: different  VLANs or ESSIDs, or... )

If you feel that RPL is rather schizo about provisioning vs configuration, then I agree.  It's not always clear to me why some things are advertised while others are provisioned.

In BGPv4, we calculate metrics by adding AS entries in the path.
(It's always additive), and we add at least one AS entry to the path.
One can AS-stuff and add more, but proper operation of BGP does not depend upon the exact algorithm used.

Finally, my impression is that how the various metrics are used (singly, or in some combination) to calculate Rank Increase is a question of further research, experimentation, and trade secret.  

So long as the Rank increases, and a node does not flap between parents, the exact details do not matter.  Each node can do it's parent selection based upon the available metrics on it's own.  It advertises the metrics it has.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 25 May 2012 18:43:39 +0200

I would agree, the OF solves the tough tension between flexibility and under-specifcation.

On May 25, 2012, at 6:31 PM, Pascal Thubert (pthubert) wrote:

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 May 2012 15:29:49 -0400

>>>>> "Pascal" == Pascal Thubert <(pthubert)" <[email-masked]>> writes:
    Pascal> I think RPL does not want to take party there. The OF is a
    Pascal> piece of logic to tie metrics and policies together.  

My question is:

- do the nodes of a DODAG have to use the same metrics to pick a parent,
  (and if so, how do they agree)
  I think that they do not, so long as they use an algorithm (such as
  MRHOF) which has certain properties.

- if we had multiple RPL instances in an LLN, using different metrics,
  then we would have multiple RPL Instances and DODAGs.  The different
  set of metrics would not co-exist in the same RPL Instance.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Mukul Goyal <[email-masked]>
Date: Sat, 26 May 2012 01:00:53 -0500 (CDT)

Hi Michael

Here is my take:

[MCR]

[Mukul]
Yes, the nodes in a DODAG have to use the same metrics. Otherwise, it is not possible for an OF to map the aggregated (from root till this node) values of the metrics to a rank.

[MCR] 
- if we had multiple RPL instances in an LLN, using different metrics,
  then we would have multiple RPL Instances and DODAGs.  The different
  set of metrics would not co-exist in the same RPL Instance.
[Mukul]
Not sure what does the first sentence mean. About the second, different sets of metrics can certainly coexist in the same RPL instance. An RPL Instance is associated with a particular OF but different DODAGs in the RPL Instance can certainly use different routing metrics.

Thanks
Mukul

----- Original Message -----
From: "Michael Richardson" <[email-masked]>
To: "Pascal Thubert (pthubert)" <[email-masked]>
Cc: [email-masked]
Sent: Friday, May 25, 2012 2:29:49 PM
Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related	questions

My question is:

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 28 May 2012 19:04:59 +0000

Hello Micheal

My question is:

[Pascal]  The current spec requires that all players of an instance play by the same rule, that is same OF, in order to guarantee the expected result. 
The goal there was deeper than the OF, like same OF with same parameterization. MRHOF is generic and allows various incarnations, depending in the metrics; all those incarnations are to be seen as different OFs WRT to RPL 's uniqueness rule.

Note that this rule is not for looplessness, the Rank would assure that anyway.

[Pascal] I think we agree. An instance can use multiple metrics bound by some logic. But those metrics and that logic must be identical throughout the instance. 
A different (set of) metric means a different OF even if MRHOF is behind both.

Cheers,

Pascal