Subject: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: (with DISCUSS and COMMENT)

From: Ralph Droms <[email-masked]>
Date: Mon, 08 Aug 2011 16:23:50 -0700

Ralph Droms has entered the following ballot position for
draft-ietf-roll-of0-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

1. I would like to discuss the interoperability and deployability of
nodes in a RPL Instance that uses OF0.  If I understand section 4.1
correctly, a node is free to compute step-of-rank using any method it
chooses.  There is a suggestion that using link properties for the
computation is preferred, but the specific link properties and the
method of computation are not specified.  Later, section 4.1 defines
two parameters, rank_factor and stretch_factor, that modify
step_of_rank to generate a "stretched step_of_rank".  The latter value
is then multiplied by the MinHopRankIncrease to compute the node's
rank_increase.

My concern is the degrees of freedom provided to the implementation in
the computation of rank_increase.  I'm hoping I can get an explanation
of some reason to believe that independent implementations, using
different methods to compute step_of_rank and potentially different
configured values for rank_factor and stretch_factor, will
interoperate successfully to form an operational network.

More specifically, if a simple metric that leads to a hop-count
computation for path lengths and route computation is know to yield
unusable performance, why is it not required that a node use some sort
of computation based on link characteristics?  And, if the computation
of the step_factor is entirely up to the node, why are the rank_factor
and stretch_factor needed?  Why not just leave the entire computation
to the implementation, with limitations that the resulting step_factor
lie in the range MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK?

2. I would also like to discuss the requirement for a
mandatory-to-implement OF, whether OF0 is that mandatory-to-implement
OF and where the requirement to implement OF0 is specified.

3. In section 7.1, why is support of the DODAG Configuration option
only a SHOULD?

   An OF0 implementation SHOULD support the DODAG Configuration option
   as specified in section 6.7.6 of [I-D.ietf-roll-rpl] and apply the
   parameters contained therein.

4. This point is more editorial than completely technical, but I list
it as a Discuss because of the potential for confusion among
implementors.  I found the use of "DODAG Version" a little confusing,
because it appears sometimes to mean one of the successive Versions of
one DODAG and at other times to mean a specific DODAG chosen from
several DODAGs.  For example, from the Introduction:

   RPL forms Directed Acyclic Graphs (DAGs) as collections of
   Destination Oriented DAGs (DODAGs) within instances of the protocol.
   Each instance is associated with a specialized Objective Function.  A
   DODAG is periodically reconstructed as a new DODAG Version to enable
   a global reoptimization of the graph.

   An instance of RPL running on a device uses an Objective Function to
   help it determine which DODAG Version it should join.  The OF is also
   used by the RPL instance to select a number of routers within the
   DODAG Version to serve as parents or as feasible successors.

In my opinion, the first use of "DODAG Version" refers to a sucessive
Version of one DODAG, while the second use refers to a selection of
one DODAG from many DODAGs.  Would it be possible to just use "DODAG"
for the second intended use?  Or am I confused about the intended
meanings?

5. In section 4.2.1, what does it mean to "validate a router"?  Why
would a router that passes validation ("succeeded that validation
process") only be "preferable"?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. I consider the following comment to be a technical rather than an
editorial suggestion because of the redundancy and potential conflict
between the text in the Introduction of this document and the contents
of draft-ietf-roll-rpl-19.  It would improve the document to edit the
Introduction down to a paragrpah that combines the following sentence
from the first paragraph with the content from the last paragraph:

   An Objective Function
   defines how a RPL node selects and optimizes routes within a RPL
   Instance based on the information objects available.

Editing out the text describing RPL would also presumably address
Stewart's Discuss about the use of multiple OFs in one RPL Instance.

2. I don't understand this phrase from the last paragraph of the
Introduction:

   [...] OF0 enforces normalized values for the rank_increase of a
   normal link and its acceptable range

Do I have it right that a node uses OF0 to determine the rank_increase
for a successor within the range:

   MINIMUM_STEP_OF_RANK < stretched step_of_rank < MAXIMUM_STEP_OF_RANK

Unless I'm missing something, these limits on the stretched
step_of_rank enforce (indirectly) a range on rank_increase, but don't
normalize rank_increase by some normalizing factor.

3. Is there a reason to switch between "successor" and "parent"
throughout the document?  For example, the title of section 4.2 is
"Feasible Successors Selection" and the title of the immediately
following section 4.2.1 is "Selection Of The Preferred Parent".  Are
"successor" and "parent" are synonymous in this context?  Would it be
asking for foolish consistency to choose one or the other?

4. In section 7.1, what is "build-time"?

   At build-time [...]

Also in section 7.1, what is a "fixed constant" (as opposed to any
other kind of "constant").  Why are overridden values - I assume these
are overriden by some administrative method like CLI configuration or
some management protocol? - only applied at the next Version of the
DODAG?

5. In section 3, how is "good enough" defined?  From reading the rest
of the spec, I don't see where any assessment of quality is applied to
ensure that "good enough" is more than basic connectivity.  I suggest
just dropping "good enough".

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 9 Aug 2011 11:12:20 +0200

Hello Ralph;

If that's what it takes, so be it. The drawback of removing such text as
opposed to making it more clear is that more and more people will
interpret as Stewart did that mixing OFs could create loops.

This was in fact an arbitrary decision by the WG to keep things simple
and guarantee a global optimization. This also constrains RPL more than
actually needed and we might end up blocking deployments that the group
did not foresee at the time.

My original "bubbles" work allowed to mix plugins - which RPL dubbed OFs
later -, and this allowed deployments like cars from different car
makers in a parking lot having different goals yet forming a DAG. Loops
will not form, but the cars will not necessarily get the connectivity
they expect.

Cheers,

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Ralph Droms
> Sent: Tuesday, August 09, 2011 1:24 AM
> To: The IESG
> Cc: [email-masked]; [email-masked];
[email-masked]
> Subject: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15:
(withDISCUSS
> and COMMENT)
> Please refer to
http://www.ietf.org/iesg/statement/discuss-criteria.html
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Aug 2011 10:52:24 -0400

>>>>> "Ralph" == Ralph Droms <[email-masked]> writes:
    Ralph> 5. In section 4.2.1, what does it mean to "validate a
    Ralph> router"?  Why would a router that passes validation
    Ralph> ("succeeded that validation process") only be "preferable"?

I think, it refers to rpl-19 section 3.2.3, to the "authenticated" mode.
This mode is completely unworkable with asymmetric crypto.   I guess I
need to write an ID that explains this better.

The reason why an authenticated router is only preferred is because the
node might need to get online in order to actually validate things.  Any
node which will pass enough traffic so that a new node can validate some
certificate chain is good enough.  

While a new node can do all manner of DOS attacks to prevent the
prospective node from validating some security properties, none of them
(if you trust your crypto) are worse than having the prospective node
find itself without any network.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 9 Aug 2011 12:08:54 -0400

Pascal...

> interpret as Stewart did that mixing OFs could create loops.

I think the issue is sufficiently clarified in the RPL spec and need not be revisited here.  

> did not foresee at the time.

Do I have it right, then, that OF0 sidesteps the WG decision for a single OF throughout a RPL Instance by allowing each node to compute its rank increase using whatever mechanism it chooses?

I know the document has gone through last call but I don't think I saw that this specific point was discussed.

If it is the case that OF0 allows each node to choose its own computation, why not simplify the OF0 spec to state "OF0 allows a node to choose any value for rank_increase, subject to the specified constraints" , along with whatever constraints are required on the value of the rank increase to ensure loop-free operation?  Those constraints may already exist in the RPL spec, in which case the OF0 spec can simply cite a reference to the constraints in the RPL spec.

> will not form, but the cars will not necessarily get the connectivity

But "not necessarily get the connectivity they expect" doesn't sound like a particularly useful characteristic of an OF ... especially if node A uses OFi, expecting one kind of connectivity, and node B uses OFj, optimizing for a different kind of connectivity, and A has no way to know what OF B is using.  How can A make any informed choice about what RPL Instance to join?

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Tue, 9 Aug 2011 12:23:14 -0400

> need to write an ID that explains this better.

Pascal - can you confirm that section 4.2.1 refers to rpl-19 section 3.2.3?

- Ralph

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 9 Aug 2011 18:44:14 +0200

Hello Ralph;
> I think the issue is sufficiently clarified in the RPL spec and need
not be
> revisited here.

[Pascal] Fine then.
I think what you're pointing out is compatible with Stewart's proposed
change.

> Do I have it right, then, that OF0 sidesteps the WG decision for a
single OF
> throughout a RPL Instance by allowing each node to compute its rank
> increase using whatever mechanism it chooses?
> 
[Pascal] I do not think so. The spirit of the law is conserved.
There is room in OF0  for implementation to bring in some variations.
This is needed because OF0 may make different computations of different
links.
But the variations are normalized from excellent (1) to worst acceptable
(9) with normal (3) in the middle.
That, plus the fact that the Goal (G) is specified, makes it so that OF0
stays within the spirit of a single OF.

> I know the document has gone through last call but I don't think I saw
that
> this specific point was discussed.
> 
[Pascal] It was, at least with Phil Levis. 

> If it is the case that OF0 allows each node to choose its own
computation,
> why not simplify the OF0 spec to state "OF0 allows a node to choose
any
> value for rank_increase, subject to the specified constraints" , along
with
> whatever constraints are required on the value of the rank increase to
> ensure loop-free operation?  Those constraints may already exist in
the RPL
> spec, in which case the OF0 spec can simply cite a reference to the
> constraints in the RPL spec.
> 
[Pascal] This is looser than what OF0 does. 
OF0 ranks the step of rank from 0 to 9 based on implementation
preference but an average like should be 3.
The rest of the computation (G bit, rank factor) is imposed by OF0.

> But "not necessarily get the connectivity they expect" doesn't sound
like a
> particularly useful characteristic of an OF ... especially if node A
uses OFi,
> expecting one kind of connectivity, and node B uses OFj, optimizing
for a
> different kind of connectivity, and A has no way to know what OF B is
using.
> How can A make any informed choice about what RPL Instance to join?

[Pascal] Exactly. Different OFs provide loop avoidance but no other
guarantee. 
Further guidance might relate different OFs that share a same goal in
which case we'd get something workable.
That is barred in RPL so there is no point discussing it in OF0. 
I'd like to convey somewhere why we made that decision, what the
consequences are, etc...
and in particular that it is not to avoid loops. But OF0 is probably not
the right place for that...

I'll answer all the other points separately.

Cheers,

> >>   Each instance is associated with a specialized Objective
Function.
> > A

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 9 Aug 2011 18:48:12 +0200

Hi Ralph;

I agree with you that this text would benefit from being more specific.
RPL requires a number of validations to happen. A deployment might
require additional policies, and use for instance L2 crypto to enforce
them. So validating a router involves security concerns, like link
access, and/or RPL security as Michael indicates. Additionally, RPL
section 13 requires a continuous link quality validation. So this refers
but is not limited to RPL sections 3.2.3 and 13.

Suggestion:

2.   An implementation SHOULD validate a router prior to selecting it
        as preferred.  This validation process is implementation and
        link type dependent, and is out of scope.  A router that
        succeeded that validation process is preferable.

=>

2.   An implementation SHOULD validate a router prior to selecting it
        as preferred.  This validation process is implementation and
        link type dependent, and is out of scope.  The validation
involves
        but is not limited to application of [RPL] sections 3.2.3 and 13
as 
        appropriate, and may involve deployment specific policies
        as well. A router that succeeded that validation process is
       preferable. 

What do you think?

Pascal

Of
> Ralph Droms
> Sent: Tuesday, August 09, 2011 6:23 PM
> To: [email-masked]
> Cc: [email-masked]; The IESG; [email-masked]
> Subject: Re: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15:
> (withDISCUSS and COMMENT)
> 
> 
> >   Kyoto Plus: watch the video
> <http://www.youtube.com/watch?v=kzx1ycLXQSE>
> > 	               then sign the petition.
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Aug 2011 09:29:42 -0400

>>>>> "Michael" == Michael Richardson <[email-masked]> writes:

    Michael> I think, it refers to rpl-19 section 3.2.3, to the
    Michael> "authenticated" mode.  This mode is completely unworkable
    Michael> with asymmetric crypto.  I guess I need to write an ID that
    Michael> explains this better.

Should read:
       This mode is completely unworkable *without* asymmetric crypto.

---

From: "Tsao, Tzeta" <[email-masked]>
Date: Wed, 10 Aug 2011 11:03:18 -0400

Hi Michael,

I have tried to find your previous comments on the issue of using
symmetric key for authentication but could still not quite understand.
Could you give a summary here before the ID is available?

Thanks,
Tzeta

Of
> Michael Richardson
> Sent: Wednesday, August 10, 2011 9:30 AM
> Cc: [email-masked]; [email-masked]; roll-
> [email-masked]; The IESG