Subject: [6lowpan] draft-kelsey-intarea-mesh-link-establishment-03.txt

From: Michael Richardson <[email-masked]>
Date: Thu, 14 Jun 2012 16:13:20 -0400

In draft-kelsey-intarea-mesh-link-establishment-03.txt it says that 
   MLE messages are sent using UDP.

I want to suggest that MLE messages should be sent at least as IPv6
ICMP messages.  

Further, I think that it could use the RPL type 155, and RPL would
allocate a new "code" codepoint.

There would be some preference to have the general structure of MLE
match that of RPL, but I think that this isn't particularly a strong
requirement.   Allocating a new ICMP type code for MLE alone might be
seen as excessive, but I can not speak for the folks in 6man.

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

---

From: Don Sturek <[email-masked]>
Date: Thu, 14 Jun 2012 16:43:36 -0700

All sounds fantastic but we don't have time for all these changes so will
opt to use MLE as written using UDP ( at least for our application....)

Don

On 6/14/12 1:13 PM, "Michael Richardson" <[email-masked]> wrote:

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

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 15 Jun 2012 12:32:17 +0200

Not sure how fantastic (or not) it is - it is not immediately clear to me how tied MLE should be to RPL - if it truly aims at being for _MESH_ link establishment, then it would appear to be a much larger scope, and should not be tied narrowly to a special-purpose protocol's type-space (& conventions etc., that do not apply universally).

I guess I'm expressing some sort of support for Don's position...

-- 
Thomas Heide Clausen
http://www.thomasclausen.org/

"Any simple problem can be made insoluble if enough meetings are held to
 discuss it."
   -- Mitchell's Law of Committees

On 15 Jun 2012, at 01:43, Don Sturek <[email-masked]> wrote:

> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 15 Jun 2012 12:43:38 +0200

> we don't have time for all these changes

It's likely that the next question that will come up is:

Should this be published as an informational RFC called "ZigBee's MLE protocol" because the protocol is no longer really meant to be modified in the process or should it be pursued as a standards track document?

(Don't get me wrong, I'm all for stability of protocols when there is running code.
Stability against gratuitous change and Brownian motion, that is.  
But not when there are good technical reasons to have the change.
We should be having the discussion on whether that's the case, I think.
And how the encapsulation of MLE works in the first place, something I don't understand yet.)

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Jun 2012 09:12:13 -0400

>>>>> "Thomas" == Thomas Heide Clausen <[email-masked]> writes:
    Thomas> Not sure how fantastic (or not) it is - it is not
    Thomas> immediately clear to me how tied MLE should be to RPL - if
    Thomas> it truly aims at being for _MESH_ link establishment, then
    Thomas> it would appear to be a much larger scope, and should not be
    Thomas> tied narrowly to a special-purpose protocol's type-space (&
    Thomas> conventions etc., that do not apply universally). 

Thomas, you will note that:
  1) I suggested it go under IPv6 ICMP first, and if there was such push
     back about allocating a new type, that RPL could allocate a type/code.
  2) ZigBee alliance (the proposal), *IS* using RPL.

I see running it over UDP very architecturally strange.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 15 Jun 2012 15:15:36 +0200

>  2) ZigBee alliance (the proposal), *IS* using RPL.

In that case, the draft must be very narrowly scoped and written such that it's clear that it's applicable _only_ to that context (special-purpose deployments of a special-purpose protocol), and specifically to not pretend to do general mesh link establishment.

> I see running it over UDP very architecturally strange.

I don't.

Thomas

---

From: Don Sturek <[email-masked]>
Date: Fri, 15 Jun 2012 06:57:38 -0700

Hi Thomas (and Michael),

I don't agree that MLE targets only RPL.  The draft was written carefully
to avoid having a narrow focus around RPL.  That said, the deployment we
are using this draft for uses 6LoWPAN, 6LoWPAN ND, ROLL RPL (non-storing)
and I think many others will find the information exchanged between
neighbors using MLE as useful.

Don

On 6/15/12 6:15 AM, "Thomas Heide Clausen" <[email-masked]> wrote:

>In that case, the draft must be very narrowly scoped and written such
>that it's clear that it's applicable _only_ to that context
>(special-purpose deployments of a special-purpose protocol), and
>specifically to not pretend to do general mesh link establishment.
>

---

From: Don Sturek <[email-masked]>
Date: Fri, 15 Jun 2012 06:59:50 -0700

Hi Michael,

We believe UDP makes the most sense as a transport for MLE.  ICMP will
take entirely too long and will end up being a maintenance issue if there
are additional information exchanges needed using MLE.

While the ZigBee Alliance is using ROLL RPL and 6LoWPAN, the information
exchanged in MLE is not tied specifically to those protocols (however,
those implementing will find the exchange useful......)

Don

---

From: Don Sturek <[email-masked]>
Date: Fri, 15 Jun 2012 07:12:58 -0700

Hi Carsten,

I answered a similar note privately from Michael.  Let me share part of
that here for everyone:

...... (part of note to Michael deleted....).......

We are just sharing our experience of now 2 years of monthly interops
using 6LoWPAN, ROLL RPL, PANA and now MLE.   Many of us participated in
6LoWPAN ND and ROLL RPL in IETF (including the author of the MLE draft).
We are simply offering up that body of experience to point out the
remaining gaps in deploying these protocols.

We are pretty close to having a sizable number of semiconductor
manufacturers go through commercial certification on these RFCs and
drafts.  We do have a specification but it simply calls out the RFCs and
drafts then provides a baseline configuration used in our commercial
deployment.  We think many other commercial groups will need to do the
same to make interoperability a reality using these protocols.  I do
believe our specification will be made publicly available once our initial
certification is complete (maybe 6 months from now?).  The interesting
part is product developers should have access to IP enabled IEEE 802.15.4
written in such a way to provide multi-vendor interoperability.

One thing though:   We realized we needed MLE rather late in our interop
process so we don't have a lot of time to close on MLE (commercially).
Certainly your ideas to use either ROLL RPL messages or ICMP messages for
MLE would not work for us schedule wise.  We would have to continue using
MLE as written (using UDP) if it goes in another direction within IETF.
That said, if we can find a way to *extend* the protocol using input from
the ROLL WG (or others) in a way that allows us to continue through
certification using MLE (maybe with even some small changes) that would be
a win for everyone.

........  (end of note.....)........

Don

On 6/15/12 3:43 AM, "Carsten Bormann" <[email-masked]> wrote:

>Should this be published as an informational RFC called "ZigBee's MLE
>protocol" because the protocol is no longer really meant to be modified
>in the process or should it be pursued as a standards track document?
>

---

From: Don Sturek <[email-masked]>
Date: Fri, 15 Jun 2012 07:19:53 -0700

Hi Thomas,

Sorry it was late when I wrote that response :-)

We debated a long time on MLE.  We knew we needed a one hop information
exchange between nodes to help with 6LoWPAN ND (eg exchange long address
information), link quality (eg. for creation and maintenance of symmetric
links), etc.   We looked at a lot of transport options and UDP seemed to
make the most sense.  One nice thing about having MLE use UDP:  If someone
wishes to extend MLE they don't need to have work done in ICMP or ROLL to
make it happen. 

I think we arrived at the Internet area for the draft since part of MLE
helps with 6LoWPAN ND, other functions help with ROLL RPL parent
selection.  I think we made these generic so others with similar needs
could make use of MLE without necessarily using either 6LoWPAN ND or ROLL
RPL.  That said, if ROLL is interested in this draft, Richard Kelsey (the
drafts author) has plenty of experience there :-)

Don

On 6/15/12 3:32 AM, "Thomas Heide Clausen" <[email-masked]> wrote:

>Not sure how fantastic (or not) it is - it is not immediately clear to me
>how tied MLE should be to RPL - if it truly aims at being for _MESH_ link
>establishment, then it would appear to be a much larger scope, and should
>not be tied narrowly to a special-purpose protocol's type-space (&
>conventions etc., that do not apply universally).
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Jun 2012 10:30:45 -0400

>>>>> "Don" == Don Sturek <[email-masked]> writes:
    Don> We believe UDP makes the most sense as a transport for MLE.  ICMP will
    Don> take entirely too long and will end up being a maintenance issue if there
    Don> are additional information exchanges needed using MLE.

I can't see a difference myself in "length of time", unless you mean
time to change hardware/firmware/software.

ICMP is even 4 bytes shorter than UDP.

---

From: Don Sturek <[email-masked]>
Date: Fri, 15 Jun 2012 07:45:15 -0700

Hi Michael,

It is the process needed to make additions to ICMP.   We have multiple
implementers using the existing MLE draft so we also are trying to get
closure if we can since we plan to being commercial certification shortly.

To us, MLE provides the features we need and there is ownership that does
not rely on ourside work groups.  If others find use in MLE (and we
believe they will) then it is offered as a draft to the IETF community.
If the protocol fundamentally changes and has dependencies on other
groups, I would doubt it would be ready for implementation in our
timeframe.

Don

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 15 Jun 2012 16:00:47 +0100

+1

AB

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 15 Jun 2012 18:28:16 +0200

> neighbors using MLE as useful.

Hi Don,

Note that I was replying to Michael's suggestions that MLE be married to RPL.

If you think it's not, then MLE should neither be developed in ROLL nor be constrained by RPL code-points, messages or principles.

Thomas

---

From: Don Sturek <[email-masked]>
Date: Fri, 15 Jun 2012 09:41:32 -0700

Hi Thomas,

I think our plan was to submit it to the Internet Area directly (Richard:
That is from memory, am I correct?)

Don

On 6/15/12 9:28 AM, "Thomas Heide Clausen" <[email-masked]> wrote:

>If you think it's not, then MLE should neither be developed in ROLL nor
>be constrained by RPL code-points, messages or principles.
>
>
>Thomas
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 15 Jun 2012 18:59:18 +0200

Hi Don,

> That is from memory, am I correct?)

If that's the case, then I think that it needs to be scoped carefully: the design and direction of the work required would (IMO) be very different if it aims narrowly for RPL, or broadly for "MESH", and the text in the specification should be very very clear as to this.

If an AD sponsored submission is the intend, then I do honestly not know what the proper way of shaping the process / forum for discussions / framing of the specification would be, but I would hope that an AD could chirp in (as you say INT, have you discussed this with Brian or Ralph, and could you or either of them let us know?)

Note, I am not taking position for or against MLE at all - I just want to ensure that a specification published be scoped so as to not be constraining for domains for which it hasn't been discussed.

Thomas

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 15 Jun 2012 13:38:10 -0400

Hi Thomas,

As Don said, the intent is that MLE not be tied to RPL and that
it be submitted as an AD-sponsored submission.  I have spoken
with Ralph about it on several occasions.  We both would have
preferred that MLE go through a WG, but there doesn't seem to be
an appropriate one.  If MLE were intended for use exclusively
with ROLL (or MANET or 6LoWPAN), this wouldn't be an issue.

Ralph and I discussed it again yesterday, and decided to go with
an AD-sponsored submission.  My plan was to add some clarifications
to the draft before announcing it to the usual suspects (6lowpan,
MANET, ROLL).  This thread jumped the gun by a day or two.

                                  -Richard Kelsey

> From: Thomas Heide Clausen <[email-masked]>
> Date: Fri, 15 Jun 2012 18:59:18 +0200
> 
> Hi Don,
> 
> If that's the case, then I think that it needs to be scoped
> carefully: the design and direction of the work required would
> (IMO) be very different if it aims narrowly for RPL, or broadly
> for "MESH", and the text in the specification should be very
> very clear as to this.
> 
> If an AD sponsored submission is the intend, then I do honestly
> not know what the proper way of shaping the process / forum for
> discussions / framing of the specification would be, but I
> would hope that an AD could chirp in (as you say INT, have you
> discussed this with Brian or Ralph, and could you or either of
> them let us know?)
> 
> Note, I am not taking position for or against MLE at all - I
> just want to ensure that a specification published be scoped so
> as to not be constraining for domains for which it hasn't been
> discussed.
> 
> Thomas

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 15 Jun 2012 19:50:41 +0200

Dear Richard,

Thank you for the clarifications, I appreciate it.

I look forward to the next version, which I will endeavor to review carefully with what you state below in mind.

Best,

Thomas

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Jun 2012 22:04:40 -0400

>>>>> "Thomas" == Thomas Heide Clausen <[email-masked]> writes:
    Thomas> If an AD sponsored submission is the intend, then I do
    Thomas> honestly not know what the proper way of shaping the process
    Thomas> / forum for discussions / framing of the specification would
    Thomas> be, but I would hope that an AD could chirp in (as you say
    Thomas> INT, have you discussed this with Brian or Ralph, and could
    Thomas> you or either of them let us know?)

AD sponsored submission is more than enough process.
(it could go via independent submission easily too)

Unless I missed something, the only proceedural thing MLE needs is a UDP
port number, which is available via Expert Review.  
Zigbee could publish MLE itself if it wanted to, but I understand that
it may have application beyond the links defined/used by Zigbee.

---

From: Don Sturek <[email-masked]>
Date: Thu, 21 Jun 2012 19:13:56 -0700

We (the ZigBee Alliance) will request a port number to use with MLE.

After discussion this week at the ZigBee Alliance members meeting, we will
follow the AD sponsored draft route.  We will elicit input from as many
related IETF WG's who might be interested in MLE>  We look forward to
comments from 6LoWPAN, ROLL and others on the draft (including Thomas who
has generously provided input already).

Don