Subject: [Roll] Closing on Ticket #10

From: JP Vasseur <[email-masked]>
Date: Thu, 12 Nov 2009 20:50:32 +0100

Dear all,

As a reminder Ticket #10 is related to a node behavior when receiving  
a DIO with an OF that it does not understand / support.

There was a strong consensus for the following option:
>> Option 1: The node simply joins the DAG as a leaf. In order words,  
>> the node has connectivity since it joins the DAG but will not act  
>> as a router for others since it does not understand the OF. Parent  
>> selection could be a simply a "random".

Now the question is whether or not RPL mandates the support of OF0.

Again two options:

1) We remove OF0 from the core spec. And nodes are free to implement  
the OF that they want

2) We do mandate for each node to support OF0

Pros/Cons:

If the support of OF0 in no longer mandatory, nodes operating in an  
environment requiring a specific OF just have to implement that OF.
On the other hand, when mixing nodes that do not support the same OF,  
they do not interoperate.

An alternative if we decide to make OF0 non mandatory is to indicate  
in some applicability statement the applications that would require  
the support of OF0.

Opinion ?

Thanks.

JP.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Nov 2009 21:10:43 -0500

>>>>> "JP" == JP Vasseur <[email-masked]> writes:
    JP> Now the question is whether or not RPL mandates the support of
    JP> OF0.

    JP> Again two options:

    JP> 1) We remove OF0 from the core spec. And nodes are free to
    JP> implement the OF that they want

    JP> 2) We do mandate for each node to support OF0

...

    JP> If the support of OF0 in no longer mandatory, nodes operating in
    JP> an environment requiring a specific OF just have to implement
    JP> that OF.  On the other hand, when mixing nodes that do not
    JP> support the same OF, they do not interoperate.

What is the real code complexity of an OF?
My impression is that it is not a lot of code. 

My opinion is that without a mandatory to implement set of options in
the core specification, it is not a standard.  There is ample experience
within the IETF (and even more outside the IETF) with what happens when
you do not have a mandatory to implement subset to guarantee
interoperability.  

There will be many implementations which are created and sold as
libraries and as part of commodity operating systems which will
implement only the minimal subset. If OF0 is not required, it won't be
there.  

If there is a subset of RPL use cases that do not need OF0, and for whom
having that code present is make or break, then that group should write
a standards track document which says what they need to implement. Those
products will not declare themselves as "RFC1234"(RPL) compliant, but
instead as "RFC2345"(pool-shed-light-switch-only).

- -- 
]       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: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 Nov 2009 11:33:28 +0100

Complete agreement with Michael. 

RPL abstracts the OCP and enables a lot of freedom in supporting many of
them.

Consequently, a reasonable implementation will enable the
additions/deletion of OCPs unless that's really impossible for that
platform.
Like a plugin in a web browser if you wish. So adding and removing OCP
code should be similar to reconfiguring the device.

If OCP0 (and/or whatever OCPs we place in the minimum Interop set) is
not needed in a given deployment, it could be uninstalled by conscious
choice.
If devices are delivered partially preconfigured without OCP0 for a
given application that does not require OCP0, I'd be fine, but:

* the possibility to reinstall it on the device must exist.
* standard devices with no configuration must work and interoperate out
of the box (right now that means that OCP0 is the default OCP)

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Richardson
>Sent: vendredi 13 novembre 2009 03:11
>To: roll WG
>Subject: Re: [Roll] Closing on Ticket #10
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>   Kyoto Plus: watch the video
<http://www.youtube.com/watch?v=kzx1ycLXQSE>
>	               then sign the petition.
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.9 (GNU/Linux)
>Comment: Finger me for keys
>
>iQEVAwUBSvzAIYCLcPvd0N1lAQJ6XAf/bwBVAnKJYc+U4IRAdIfqve9H8NAYwM//
>248uvPfPb+IbBGblUO7EXOqw40RIj8nksJ0kEWKeZ6aH8OgAoew82KGxpRDEz8wD
>iOmjILPu1Vn+TUOw3hksoQB1ueIiZLAHJxOKhPudWGqOSjM5+ixiefVZ28bRAcgZ
>OI8mZtjnBa3+HUeBjXkALFvWRL9ifhzo3CebZs/YlyngtkJEIQLNxu3o2waCeANl
>VLyD+FFtJeal9P4et6J8200Q9BZ0D+uRDd1h5vRkXVogFLwq6OV7Yn0PwaZg4w2X
>dM9/u7lzCb3XL5KpBPp+k4Z+KogrN9T6nlIl39GycTABneUXIf/CWQ==
>=ddwI
>-----END PGP SIGNATURE-----
>_______________________________________________
>Roll mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/roll

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 13 Nov 2009 10:22:10 -0500

> From: Michael Richardson <[email-masked]>
> Date: Thu, 12 Nov 2009 21:10:43 -0500

> My impression is that it is not a lot of code. 

If RPL turns out to be too complex for small devices, it
will be because of lots of little requirements, no one of
which necessitates a lot of code.

> My opinion is that without a mandatory to implement set
> of options in the core specification, it is not a
> standard.  There is ample experience within the IETF (and
> even more outside the IETF) with what happens when you do
> not have a mandatory to implement subset to guarantee
> interoperability.

Yes, but RPL isn't the end of the process.  I can't see a
consumer peering at a label to see if a wireless thermostat
implements a particular RFC.  By the time a thermostat gets
to a shelf in a store a whole mess of protocols and settings
will have been boiled down into one or two logos.  We don't
need to start that process here.

> There will be many implementations which are created and
> sold as libraries and as part of commodity operating
> systems which will implement only the minimal subset. If
> OF0 is not required, it won't be there.
>
> If there is a subset of RPL use cases that do not need
> OF0, and for whom having that code present is make or
> break, then that group should write a standards track
> document which says what they need to implement.

Given ROLL's charter, I think you have this the wrong way
around.  ROLL is intended for use in small devices with
limited resources.  If there is a subset of RPL use cases
that need a generic, configurable implemenation of RPL, and
for whom having that code present is acceptable, then that
group should write a standards track document which says
what they need to implement.

                               -Richard Kelsey

---

From: Michael Richardson <[email-masked]>
Date: Fri, 13 Nov 2009 10:57:33 -0500

>>>>> "Richard" == Richard Kelsey <[email-masked]> writes:
    >> implement only the minimal subset. If OF0 is not required, it
    >> won't be there.
    >> 
    >> If there is a subset of RPL use cases that do not need OF0, and
    >> for whom having that code present is make or break, then that
    >> group should write a standards track document which says what
    >> they need to implement.

    Richard> Given ROLL's charter, I think you have this the wrong way
    Richard> around.  ROLL is intended for use in small devices with
    Richard> limited resources.  If there is a subset of RPL use cases
    Richard> that need a generic, configurable implemenation of RPL, and
    Richard> for whom having that code present is acceptable, then that
    Richard> group should write a standards track document which says
    Richard> what they need to implement.
  
  I hear you.  The generic configurable implementation of RPL that I
speak of will be sold by operating system vendors.  I'm talking QNX,
WindRiver, MonteVista, and a dozen other smaller vendors that sell
toolkits.  
  
  So, which requirement does this document satisfy?
  Is it: - building routing requirements ...
         - home routing requirements   ...
         - indus routing requirements  RFC 5673
         - urban routing requirements  RFC 5548

  I also understand the comment about death by a thousand needle pricks.
Will these four stated things be satisfied by a single OFx?  Will there
be four OFx?  Or will many different ones be required for different
situations? 

  If there is no MUST for OF0, then we do not have anything we can
interoperate with, and so we do not have an IETF standard.   We might
have four standards, and if so, that's fine, then let's be explicit
about this.

  We have not discussed security very much yet.

  If there is not space for two OFx (OF0 and OFx) in the code space,
then I wonder if there will be space for any security.  As far as I can
tell, RPL will suffer from all the constraints that SNMP* experienced
with security.

- --

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 13 Nov 2009 13:13:32 -0500

> Date: Fri, 13 Nov 2009 10:57:33 -0500
>

My hope is that we will need no more than one or two OFxs.
The reason we need to be flexible now is not that we are
likely to need many of them, but that we don't know which
ones are the right ones.

> have four standards, and if so, that's fine, then let's be explicit

Is there a problem with treating RPL and the metrics
document as a single standard for the purposes of
interoperation?  RPL can state that there must be a
single metric in use without saying which metric it is.

>   If there is not space for two OFx (OF0 and OFx) in the code space,

There is space for two OFx if they are needed.  There is no
space for anything that is not needed, big or small.  In the
case of something like a consumer thermostat, I do not see
any need for having both OF0 and a more nuanced metric.

                                  -Richard Kelsey

---

From: Tim Winter <[email-masked]>
Date: Fri, 13 Nov 2009 21:00:01 -0500

My opinion is for Option 1.  I think that the applicability statements are
the right place to start pinning down interoperability w.r.t. OFs - as
appropriate to each application space.  This may also include
interoperability between application spaces.

-Tim

JP Vasseur wrote:
> Dear all,
> 
> As a reminder Ticket #10 is related to a node behavior when receiving a
> DIO with an OF that it does not understand / support.
> 
>>> the node has connectivity since it joins the DAG but will not act as
>>> a router for others since it does not understand the OF. Parent
> 1) We remove OF0 from the core spec. And nodes are free to implement the
> OF that they want
> 
> An alternative if we decide to make OF0 non mandatory is to indicate in
> some applicability statement the applications that would require the
> support of OF0.
> 
> Opinion ?
> 
> Thanks.
> 
> JP.
> 
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 13 Nov 2009 22:08:59 -0500

>>>>> "Tim" == Tim Winter <[email-masked]> writes:
    Tim> My opinion is for Option 1.  I think that the applicability
    Tim> statements are the right place to start pinning down
    Tim> interoperability w.r.t. OFs - as appropriate to each
    Tim> application space.  This may also include interoperability
    Tim> between application spaces.

I'm fine with that. The applicability statements will be the main anchor
into the standard, that's fine.   My concern is that it appeared that
some wanted to leave to do other industry "fora" to declare.  As long as
there is an IETF standards track document that says what is what, then
I'm happy.

--

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Sat, 14 Nov 2009 11:36:24 +0100

Hi Richard, 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Richard Kelsey
> Sent: vendredi 13 novembre 2009 19:14
> To: Michael Richardson
> Cc: [email-masked]
> > Will these four stated things be satisfied by a single OFx?  Will 
> > there be four OFx?  Or will many different ones be required for 
> > different situations?
> 
> Is there a problem with treating RPL and the metrics document 
> as a single standard for the purposes of interoperation?  RPL 
> can state that there must be a single metric in use without 
> saying which metric it is.
> 
100% agree, RPL+metric+OF should be treated as a single standard. This
is nothing new. What is the point of SNMP if you do not implement MIBs
RFCs? None. A standard does not need to be one RFC. Interoperability was
never met between two device simply because they implement one RFC,
rather that they implement a set of L1/2 standards, L3, L4, L5. 
Julien

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Sat, 14 Nov 2009 11:38:41 +0100

+1.
Julien 

> Behalf Of Tim Winter
> Sent: samedi 14 novembre 2009 03:00
> To: ROLL WG
> My opinion is for Option 1.  I think that the applicability 
> statements are the right place to start pinning down 
> interoperability w.r.t. OFs - as appropriate to each 
> application space.  This may also include interoperability 
> between application spaces.
> 
> 
> -Tim
> 
> 
> JP Vasseur wrote:
> > Dear all,
> >

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 17 Nov 2009 12:38:52 +0100

Hi Richard

>likely to need many of them, but that we don't know which

We disagree on this. There might be one or 2 OCPs coming out with for
RPL for this round of specification, OK. Probably more if we really need
to meet all the requirement drafts. But there could be many different
sorts of deployments that we do not cover here, and thus many OCPs, some
defined in some future at the IETF, some designed by other SDOs like of
ETSI, ISA or IEC, and some proprietary value-added proposals. As long as
the OCP conform the general rules in RPL, that should be fine, and the
generic part of the wheel does not have to be reinvented each time.

My hope when I designed the plugins in MANEMO was to build a generic DV
platform that could be instantiated for many specific environments, just
like SIP can.
RPL inherited the concept, though it lost/barred the capability to mix
OCPs and degrade to OCP0 at the edges. 
Still, the loop avoidance remains totally generic, based on an abstract
rank, so RPL retains the capability to be instantiated in many fashions.
I think that is a powerful idea.

Pascal

---

From: JP Vasseur <[email-masked]>
Date: Thu, 19 Nov 2009 09:22:37 +0100

> there is an IETF standards track document that says what is what, then

Excellent. Issue resolved. Just note that applicability statements are  
part of our charter
and will be informational.

Thanks.

JP.

>   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE 
> >
> 	               then sign the petition.
>

---

From: JP Vasseur <[email-masked]>
Date: Thu, 19 Nov 2009 09:52:54 +0100

> OCPs and degrade to OCP0 at the edges.

Yes, pretty old concept used for many protocols indeed. Issue is closed.

JP.