Subject: [Roll] I-D ACTION:draft-ietf-roll-protocols-survey-05.txt

From: [email-masked]
Date: Mon, 26 Jan 2009 16:00:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF.

	Title		: Overview of Existing Routing Protocols for Low Power and Lossy Networks
	Author(s)	: A. Tavakoli, S. Dawson-Haggerty, P. Levis
	Filename	: draft-ietf-roll-protocols-survey-05.txt
	Pages		: 26
	Date		: 2009-1-26
	
Networks of low power wireless devices introduce novel IP routing
   issues.  Low-power wireless devices, such as sensors, actuators and
   smart objects, have difficult constraints: very limited memory,
   little processing power, and long sleep periods.  As most of these
   devices are battery-powered, energy efficiency is critically
   important.  Wireless link qualities can vary significantly over time,
   requiring protocols to make agile decisions yet minimize topology
   change energy costs.  Routing over such low power and lossy networks
   has novel requirements that existing protocols may not address.  This
   document provides a brief survey of the strengths and weaknesses of
   existing protocols with respect to this class of networks.  From this
   survey it examines whether existing and mature IETF protocols can be
   used without modification in these networks, or whether further work
   is necessary.
   is necessary.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Philip Levis <[email-masked]>
Date: Mon, 26 Jan 2009 16:16:36 -0800

> 	Filename	: draft-ietf-roll-protocols-survey-05.txt

Edits:

Fixed all editorial nits (spelling, etc.) from Thomas and Ulrich.

Fixed incorrect table values for OLSRv2. Triggered updates are  
optional, so loss is a ?.

Changed "Suitability Summary" to "Criteria"

Fixed O(R + e) to O(R) + e.

Removed redundant paragraph in 4.4 "The control cost criterion is a  
necessary but not..."

Made IETF scope more specific ("any protocol" -> "any protocol outside  
the IETF").

Added errata to terminology section ("NOT RECOMMENDED").

Cleaned up RFC/draft terminology in Section 4.

Clarified "unbounded" control overhead.

Explained 4kB of RAM.

Phil

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 27 Jan 2009 16:12:22 -0000

> Added errata to terminology section ("NOT RECOMMENDED").

That doesn't seem to have actually been done.

I have two nits, one new, one I've only just spotted.

In 3.1 there's a "Thhere".

At the end of the first paragraph in 4 before 4.1, last
line, criterion ought to be criteria.

These, to me, come under the heading of mark for the
future, rather than reason on their own to re-issue.

Personally I still would take "novel" out of the
abstract, and I still think "extenuating" in the
introduction is not the right word. Same heading.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Jan 2009 18:29:04 +0100

> 	Filename	: draft-ietf-roll-protocols-survey-05.txt

Thanks for this new version of the draft!

First: I'm not politicking.
Second: there's apparently a deadline, please respect it.
Third: here are my comments:

I'm not convinced by the NEMO exclusion paragraph:

> This document does not examine the Network Mobility Basic Support 
> Protocol (NEMO RFC 3963 [RFC3963]) because it is not a routing 
> protocol.  It does not examine hierarchical NEMO 
> [I-D.thubert-tree-discovery] as a candidate because it only maintains
>  a default route and so is insufficient for general routing.
> Although NEMO itself is not a suitable routing solution to LLNs, some
> of its mechanisms, such as loop-free tree formation, might be useful
> in an LLN routing protocol.

NEMO could qualify certain characteristics of routing protocols.  I've 
said that already.  Thomas seemed to agree on the general question of 
defining what a routing protocol is, but in another mail JP seemed to 
suggest we shouldn't do that here.  If so - then I disagree.  That's why 
I'm silent.

Also, draft-thubert is a personal proposal, since long (could be said 
'mature') yet I don't consider it a IETF protocol.  Thus I don't 
understand why citing it.

Also, if one disqualifies draft-thubert because of the fact it only 
builds default routes - I agree with the disqualification as such, but 
then there exist another personal draft which could be used in 
conjunction which deals with specific routes as well (not only default 
routes) in the context of NEMO moving networks.  I don't name it in 
order to avoid being qualified as politicizing, pushing own ideas, etc.

Also, 'mobility' appears cited three times in the requirements documents 
and NEMO protocol could be a good candidate to treat some types of 
network mobility.

At least for these four reasons I'm not convinced by this 
protocols-survey NEMO paragraph.

Alex

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 29 Jan 2009 11:47:01 +0100

Hi Alex:

Ideas derived from the work on routing in nested NEMO and MANEMO might apply to ROLL. The study does not rule them out of the solution space once we recharter. The study just did not include them in its scope because they did not achieve the right status, like draft standard.

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>Sent: mardi 27 janvier 2009 18:29
>To: [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: Re: [Roll] I-D ACTION:draft-ietf-roll-protocols-survey-05.txt
>

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 29 Jan 2009 11:58:39 +0100

Hi,

thanks to the authors for this revised version of the ID. It certainly
has improved a lot. All my minor points have been addressed and
included. Some of my general remarks (applicability statement, security
considerations section, split up of criteria and protocol evaluation
into two documents) in my last email have been noted but not included. I
don't have anything new to add.

Best regards,
Ulrich

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Jan 2009 12:15:22 +0100

Hi Pascal,

Pascal Thubert (pthubert) a écrit :
> Hi Alex:
> 
> Ideas derived from the work on routing in nested NEMO and MANEMO 
> might apply to ROLL. The study does not rule them out of the solution
>  space once we recharter. The study just did not include them in its 
> scope because they did not achieve the right status, like draft 
> standard.

But only OSPF and RIP have Draft Standard status, all the others like
MANET routing protocols don't have Draft Standard status either.  The
status level ('maturity'?) does not even figure as a column in the
Figure 1 table.

The study does not talk recharter at all.

I think I don't understand what you mean.

All I see is this:
> protocol.

I have very strong doubts about the validity of this statement.

Not only I think NEMO protocol _does_ satisfy some of the typical
qualifications of a typical routing protocol (e.g. it does exchange
prefixes/subnets in messages, it affects the routing table) but also
I think it may satisfy some of the explicitely mobility requirements in
the reqs documents.

If timeline is an issue, I'm not requesting more detailed examination of
the NEMO protocol, but I suggest for another motivation, like for
example "when we have time we'll look at NEMO too".

All the other motivaitons like "not being a routing protocol" or "not
yet Draft Standard status" are not valid to me, sorry to say so.

If needed, I could contribute better formulate a NEMO paragraph in this
document.

Alex

> 
> Pascal
> 
>> -----Original Message----- From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu 
>> Sent: mardi 27 janvier 2009 18:29 To: [email-masked] Cc: 
>> [email-masked]; [email-masked] Subject: Re: [Roll] I-D 
>> ACTION:draft-ietf-roll-protocols-survey-05.txt
>> 
>>> Title		: Overview of Existing Routing Protocols for Low Power and
>>>  Lossy Networks Author(s)	: A. Tavakoli, S. Dawson-Haggerty, P. 
>>> Levis Filename	: draft-ietf-roll-protocols-survey-05.txt Pages		:
>>>  26 Date		: 2009-1-26
>> First: I'm not politicking. Second: there's apparently a deadline, 
>> please respect it. Third: here are my comments:
>> 
>>> [I-D.thubert-tree-discovery] as a candidate because it only 
>>> maintains a default route and so is insufficient for general 
>>> routing. Although NEMO itself is not a suitable routing solution 
>>> to LLNs, some of its mechanisms, such as loop-free tree 
>>> formation, might be useful in an LLN routing protocol.
>> NEMO could qualify certain characteristics of routing protocols. 
>> I've said that already.  Thomas seemed to agree on the general 
>> question of defining what a routing protocol is, but in another 
>> mail JP seemed to suggest we shouldn't do that here.  If so - then 
>> I disagree.  That's why I'm silent.
>> 
>> Also, draft-thubert is a personal proposal, since long (could be 
>> said 'mature') yet I don't consider it a IETF protocol.  Thus I 
>> don't understand why citing it.
>> 
>>  builds default routes - I agree with the disqualification as such,
>>  but then there exist another personal draft which could be used in
>>  conjunction which deals with specific routes as well (not only 
>> default routes) in the context of NEMO moving networks.  I don't 
>> name it in order to avoid being qualified as politicizing, pushing 
>> own ideas, etc.
>> 
>> Also, 'mobility' appears cited three times in the requirements 
>> documents and NEMO protocol could be a good candidate to treat some
>>  types of network mobility.
>> 
>> _______________________________________________ Roll mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>

---

From: Ian Chakeres <[email-masked]>
Date: Thu, 29 Jan 2009 10:57:57 -0500

Philip, I am glad to see another revision of the protocol-survey - but
I am disappointed to see that many of my comments were ignored and
several errors remain.

I've included the contents of my earlier email about the errors below.

Sincerely,
Ian Chakeres

===START===
I examined draft-ietf-roll-protocol-survey-03. I found most of my
earlier comments addressed, but I believe there are still a few more
items that need to be changed.

DYMO's distance metric allows representation of link and node cost,
along with other cost factors. Although "node" and "link" cost are not
explicitly called out in the DYMO ID, the distance value associated
with routing information can be modified before consideration for
inclusion in the routing table as well as prior to sending routing
information. The roll-protocol-survey document and summary table
should be updated accordingly.

DYMO-16 does not require, but does by default encourage
sending/forwarding of RERR. Please modify Section 12 accordingly. I
believe this change also effects the loss response rating for DYMO in
the summary table.

I think all '-low' should be removed from the protocol-survey.

Finally, I did not see any change in Section 4.2, which I believe
others also agreed was not clear.

Here was my original comment

"""
In Section 4.2, the motivation provided is the possibly large network
size (250-millions) and deep network (20 hops). Network size and
routing information size do not have a direct connection when
hierarchical addressing is used. Perhaps this motivation could be
removed and simply the last sentence kept. Given this change maybe the
suitability metric should become routing table size, instead of table
scalability.
"""
===END===

On Mon, Jan 26, 2009 at 7:16 PM, Philip Levis <[email-masked]> wrote:
> Fixed incorrect table values for OLSRv2. Triggered updates are optional, so
> loss is a ?.
>
> Made IETF scope more specific ("any protocol" -> "any protocol outside the
> IETF").
>

---

From: "David E. Culler" <[email-masked]>
Date: Thu, 29 Jan 2009 20:26:49 -0800

Ian,

It is really not reasonable to expect the authors to rev the document
to track a moving target.  That was precisely the reason that we had a
clear cut off.  Folks, including yourself, complained that it was too
restrictive and we broadened it to include protocols that were still in
draft.  In addition, this concern of the survey never ending because
there is always something new that might be considered, especially
those that are reved in response to the survey analysis, is also why it
is important that we accept the draft and complete the recharter so
that the working group, including folks like yourself, can start the
process of reving protocols or considering new ones.  I have asked the
authors not to consider requests to look at new drafts.

David

Ian Chakeres wrote:

Sincerely,
Ian Chakeres

===START===

"""

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Routing Over Low power and Lossy networks
Working Group of the IETF.

Title : Overview of Existing Routing Protocols for Low
Power and Lossy Networks
Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis
Filename : draft-ietf-roll-protocols-survey-05.txt
Pages : 26
Date : 2009-1-26

Edits:

Explained 4kB of RAM.

Phil

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 30 Jan 2009 10:08:39 +0100

David I thought to propose that comments be tracked, with the Issue
Tracker :

        http://trac.tools.ietf.org/wg/roll/trac/report/1

It could help stabilize the target.  One could select a person to take
care of this.

Alex

David E. Culler a écrit :
> Ian, It is really not reasonable to expect the authors to rev the 
> document to track a moving target.  That was precisely the reason 
> that we had a clear cut off.  Folks, including yourself, complained 
> that it was too restrictive and we broadened it to include protocols 
> that were still in draft.  In addition, this concern of the survey 
> never ending because there is always something new that might be 
> considered, especially those that are reved in response to the survey
>  analysis, is also why it is important that we accept the draft and 
> complete the recharter so that the working group, including folks 
> like yourself, can start the process of reving protocols or 
> considering new ones.  I have asked the authors not to consider 
> requests to look at new drafts.
> 
> David
> 
> Ian Chakeres wrote:
>> Philip, I am glad to see another revision of the protocol-survey - 
>> but I am disappointed to see that many of my comments were ignored 
>> and several errors remain.
>> 
>> Sincerely, Ian Chakeres
>> ===START=== I examined draft-ietf-roll-protocol-survey-03. I found 
>> most of my earlier comments addressed, but I believe there are 
>> still a few more items that need to be changed.
>> 
>>  along with other cost factors. Although "node" and "link" cost are
>>  not explicitly called out in the DYMO ID, the distance value 
>> associated with routing information can be modified before 
>> consideration for inclusion in the routing table as well as prior 
>> to sending routing information. The roll-protocol-survey document 
>> and summary table should be updated accordingly.
>> 
>>  believe this change also effects the loss response rating for DYMO
>>  in the summary table.
>> 
>> """ In Section 4.2, the motivation provided is the possibly large 
>> network size (250-millions) and deep network (20 hops). Network 
>> size and routing information size do not have a direct connection 
>> when hierarchical addressing is used. Perhaps this motivation could
>>  be removed and simply the last sentence kept. Given this change 
>> maybe the suitability metric should become routing table size, 
>> instead of table scalability. """ ===END===
>> 
>>>> A New Internet-Draft is available from the on-line 
>>>> Internet-Drafts directories. This draft is a work item of the 
>>>> Routing Over Low power and Lossy networks Working Group of the 
>>>> IETF.
>>>> 
>>>> Title           : Overview of Existing Routing Protocols for 
>>>> Low Power and Lossy Networks Author(s)       : A. Tavakoli, S. 
>>>> Dawson-Haggerty, P. Levis Filename        : 
>>>> draft-ietf-roll-protocols-survey-05.txt Pages           : 26 
>>>> Date            : 2009-1-26
>>>> 
>>> Edits:
>>> 
>>> Removed redundant paragraph in 4.4 "The control cost criterion is
>>>  a necessary but not..."
>>> 
>>> Made IETF scope more specific ("any protocol" -> "any protocol 
>>> outside the IETF").
>>> 
> ------------------------------------------------------------------------
> 
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 30 Jan 2009 10:45:14 +0100

Ian Chakeres a écrit :
[...]
> hierarchical addressing is used.

Ian, I agree with the above - network size and routing information size
are not directly related - it largely depends on how the subnet
structure and the addressing architecture are conceived.

> Perhaps this motivation could be removed and simply the last sentence
>  kept. Given this change maybe the suitability metric should become 
> routing table size, instead of table scalability. """ ===END===

I'm not sure I understand which 'last sentence' to be kept?

Alex

>>> Power and Lossy Networks Author(s)       : A. Tavakoli, S. 
>>> draft-ietf-roll-protocols-survey-05.txt Pages           : 26 Date
>>>  : 2009-1-26
>> Edits:
>>

---

From: Ian Chakeres <[email-masked]>
Date: Fri, 30 Jan 2009 09:26:17 -0500

I respectfuly disagree.

I think it a mistake to attempt to publish this document when it
contains information that is clearly inaccurate.

Sincerely,
Ian Chakeres

On Thu, Jan 29, 2009 at 11:26 PM, David E. Culler
<[email-masked]> wrote:
> Ian,
>   It is really not reasonable to expect the authors to rev the document to
> track a moving target.  That was precisely the reason that we had a clear
> cut off.  Folks, including yourself, complained that it was too restrictive
> and we broadened it to include protocols that were still in draft.  In
> addition, this concern of the survey never ending because there is always
> something new that might be considered, especially those that are reved in
> response to the survey analysis, is also why it is important that we accept
> the draft and complete the recharter so that the working group, including
> folks like yourself, can start the process of reving protocols or
> considering new ones.  I have asked the authors not to consider requests to
> look at new drafts.
>
> David
>
> Ian Chakeres wrote:
>

---

From: Philip Levis <[email-masked]>
Date: Fri, 30 Jan 2009 08:01:59 -0800

>> considering new ones.  I have asked the authors not to consider  

We have two options:

1) consider DYMO as of its stable state (-15), or
2) remove DYMO from the document because it is not stable.

The reason behind 2) is that the specification has not been  
implemented, tested, nor does it have any running code that indicates  
the specification is sound. Imagine delaying ROLL for a year because a  
protocol looks promising but turns out to not work. *That* would make  
the document inaccurate in a meaningful way.

I'd much rather give DYMO the credit and relevance it is due and go  
with 1).

Phil

---

From: Ian Chakeres <[email-masked]>
Date: Fri, 30 Jan 2009 11:12:26 -0500

How about another option - update the document based on the current
specification?

I believe that the recent changes have been relatively minor. They
mainly explain and indicate to an implementer where added flexibility
exists. I even brought several of these items to your attention during
a face-to-face discussion in Dublin about the protocol-survey.

Ian Chakeres

On Fri, Jan 30, 2009 at 11:01 AM, Philip Levis <[email-masked]> wrote:
> The reason behind 2) is that the specification has not been implemented,
> tested, nor does it have any running code that indicates the specification
> is sound. Imagine delaying ROLL for a year because a protocol looks
> promising but turns out to not work. *That* would make the document
> inaccurate in a meaningful way.
>
> I'd much rather give DYMO the credit and relevance it is due and go with 1).
>
> Phil
>

---

From: David Ward <[email-masked]>
Date: Fri, 30 Jan 2009 10:26:21 -0600

All -

If there are gross errors in any specification, the ADs and then the  
IESG will send a doc back to the WG to correct them.  The best a doc  
can do with a moving target is cite specific revisions of specs and  
call out "as of ZZZZ/YY/XX date" but, the data has to be correctly  
reflecting the cited material. In addition,  the protocol survey can  
make it clear that the ROLL WG is engaging with other WGs based upon  
the analysis performed and that other protocols are changing based on  
the outcome and cite where to go and find the latest and greatest  
information.

HIH

-DWard

On Jan 30, 2009, at 8:26 AM, Ian Chakeres wrote:

>> but
>> not
>> Low
>> optional, so
>> outside the

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 30 Jan 2009 11:30:46 -0500

I would vote to limit the scope of the ROLL document to the -15 version
of DYMO and proceed. As was noted earlier, this could lead to an
unending churn of the document. While differences in the -15 to -16
version of DYMO may be manageable, this creates a precedent that IMO
would lead to stalling the effort due to document churn. It's just not
workable in the general case.  

Regards,
Stan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ian Chakeres
Sent: Friday, January 30, 2009 11:12 AM
To: Philip Levis
Cc: Ross Callon; ROLL WG; David E. Culler
Subject: Re: [Roll] I-D ACTION:draft-ietf-roll-protocols-survey-05.txt

I believe that the recent changes have been relatively minor. They
mainly explain and indicate to an implementer where added flexibility
exists. I even brought several of these items to your attention during a
face-to-face discussion in Dublin about the protocol-survey.

Ian Chakeres

On Fri, Jan 30, 2009 at 11:01 AM, Philip Levis <[email-masked]>
wrote:
>>>  It is really not reasonable to expect the authors to rev the 

>>> considered, especially those that are reved in response to the 
>>> survey analysis, is also why it is important that we accept the 
>>> draft and complete the recharter so that the working group, 
>>> including folks like yourself, can start the process of reving 
>>> protocols or considering new ones.  I have asked the authors not to 
>>> consider requests to look at new drafts.
>
> We have two options:
>

with 1).

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 30 Jan 2009 16:31:10 -0000

> 1) consider DYMO as of its stable state (-15), or

Surely the stable state is -16, that's the latest published
version, -15 is superseded. If you quote and use -15 I think
you ought to add a date to the ROLL report indicating when
you froze consideration.

> Imagine delaying ROLL for a year because a  

> the document inaccurate in a meaningful way.

That strikes me as a straw man. Is anyone suggesting this -15/-16
issue is going to delay ROLL a year? That could only be the case
if -16 were suddenly getting Pass across the table, which I don't
think is the case.

Note: I see, just as I was about to send this, that David Ward has
just suggested the date approach.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 30 Jan 2009 17:32:44 +0100

I would like to second Ian on this front.

I believe that, for one thing, the DYMO distance metric is something  
which goes way back -- at least, I remember having discussed it with  
respect to "node cost" in OLSR and how it maps into DYMO.AODV a long  
while back, only to realize what Ian also points out in this email:  
the distance metric can be set to consider both "link cost" and "node  
cost". As such, and on that front, I do not thing that this is a  
"moving target" but rather is something that should be corrected.

As for the rest of Ian's comments, I agree with those.

I also respectfully suggest that we not publish a document containing  
inaccurate information -- especially when such is pointed out on the  
list.

Note, I have reviewing the -05 version of this I-D high on my todo  
list, but other IETF matters have kept me busy these past days. I'll  
try to get through it over the weekend, and will post my comments  
here (despite those in the past having been explicitly qualified as  
"disruptive").

Sincerely,

Thomas

On Jan 30, 2009, at 15:26 PM, Ian Chakeres wrote:

>> document to

---

From: "David E. Culler" <[email-masked]>
Date: Fri, 30 Jan 2009 09:47:36 -0800

Absolutely agree that it should be as accurate as possible.  If the 
changes were minor then it should not matter much if the snapshot were 
dymo -15 or dymo -16.  But my understanding is that these changes are 
not minor.  They reflect significant protocol enhancements in part to 
address the observations that arose as part of doing the survey.  This 
is wonderful progress.  We'd love to have a better dymo and we'd love to 
have a better dymo provide a roll solution, should that come to pass.  
But the point is that ROLL cannot consider enhancements to anything, 
much less any new starts, until the survey document and the recharter is 
completed.  It seems that many communities have good ideas to bring to 
the table as that process starts, and we welcome that and look forward 
to that exciting technical work. 

Not passing the ROLL criteria is in no way a negative judgment on any of 
the protocols.  None of them were designed with this particular set of 
concerns first and foremost.  In fact, having more passes and fewer 
fails does not necessarily mean a particular protocol is better suited 
to be adapted to this regime - although there is likely to be some 
correlation.  It is conceivable that a single facet of a protocol design 
may be a huge show stopper, while redesign of another may solve several 
concerns.  The document is a matter of due digilence, not a beauty contest.

To have any one candidate protocol progressively tuning its design in 
response to an on-going assessment process and holding the completion of 
that assessment process hostage would be unfair to all the other 
candidates and communities.  They have good ideas to bring to the table 
too, but are patiently waiting for the process to move to the next step 
as was agreed upon in the initial workgroup formation and in every 
meeting since.

So I love that dymo -16 has all sorts of wonderful improvements and that 
members of MANET feel strongly that their ideas apply to ROLL - even 
where there is no mobility involved.  This is all wonderful and we look 
forward to working together.  So help us complete the survey and the 
recharter so that together, and with the broader set of interested 
parties, we can consider forward going technical work.  To date, our 
charter only permits us to survey a well defined universe of existing 
protocols and to provide a well-defined set of requirements documents 
and make a call as to whether there is work to be done.  You clearly 
agree that there is work to be done.  That is the ONLY bit that really 
matters.  If there is any technical inaccuracies relative to DYMO -15 
then by all means suggest a change to the text of the draft.  We would 
like that to be a useful a guide as possible.   But, the purpose of the 
draft is to make a single binary decision.  Is there an established 
protocol that exists today and satisfies all the requirements or not.  
If the answer is YES, we are done.  The WG shuts down.  If the answer is 
NO.  The working group recharters and we get to actual work.

Everything you have said reflects that the answer is NO.  Clearly you 
believe that additional work on dymo may be a possible solution.  Wonderful

Rough consensus to that is unequivocal.  So let's stop equivocating and 
get to work  - together.

---

From: Ian Chakeres <[email-masked]>
Date: Fri, 30 Jan 2009 13:14:44 -0500

I believe the changes made to DYMO were relatively minor and largely
explanatory. The revised text mainly calls attention to DYMO's ability
to handle several of the criteria from the protocol-survey explicitly.

I feel that previous versions and the current version of the
protocol-survey do contain some misunderstandings about the
capabilities of DYMO and other protocols. Note that, many of these
errors have been resolved.

Please feel free to examine the documents and provide your opinion on
whether the changes being discussed were major or minor.

IMHO I think the easiest/fastest/fairest way to complete this document
is to get it up-to-date, as I do not think there is any disagreement
that the document is inaccurate/incorrect in its current state.

Ian Chakeres

On Fri, Jan 30, 2009 at 12:47 PM, David E. Culler
<[email-masked]> wrote:
> Absolutely agree that it should be as accurate as possible.  If the changes
> were minor then it should not matter much if the snapshot were dymo -15 or
> dymo -16.  But my understanding is that these changes are not minor.  They
> reflect significant protocol enhancements in part to address the
> observations that arose as part of doing the survey.  This is wonderful
> progress.  We'd love to have a better dymo and we'd love to have a better
> dymo provide a roll solution, should that come to pass.  But the point is
> that ROLL cannot consider enhancements to anything, much less any new
> starts, until the survey document and the recharter is completed.  It seems
> that many communities have good ideas to bring to the table as that process
> starts, and we welcome that and look forward to that exciting technical
> work.
> Not passing the ROLL criteria is in no way a negative judgment on any of the
> protocols.  None of them were designed with this particular set of concerns
> first and foremost.  In fact, having more passes and fewer fails does not
> necessarily mean a particular protocol is better suited to be adapted to
> this regime - although there is likely to be some correlation.  It is
> conceivable that a single facet of a protocol design may be a huge show
> stopper, while redesign of another may solve several concerns.  The document
> is a matter of due digilence, not a beauty contest.
>
> that assessment process hostage would be unfair to all the other candidates
> and communities.  They have good ideas to bring to the table too, but are
> patiently waiting for the process to move to the next step as was agreed
> upon in the initial workgroup formation and in every meeting since.
>
> members of MANET feel strongly that their ideas apply to ROLL - even where
> there is no mobility involved.  This is all wonderful and we look forward to
> working together.  So help us complete the survey and the recharter so that
> together, and with the broader set of interested parties, we can consider
> forward going technical work.  To date, our charter only permits us to
> survey a well defined universe of existing protocols and to provide a
> well-defined set of requirements documents and make a call as to whether
> there is work to be done.  You clearly agree that there is work to be done.
>  That is the ONLY bit that really matters.  If there is any technical
> inaccuracies relative to DYMO -15 then by all means suggest a change to the
> text of the draft.  We would like that to be a useful a guide as possible.
> But, the purpose of the draft is to make a single binary decision.  Is there
> an established protocol that exists today and satisfies all the requirements
> or not.  If the answer is YES, we are done.  The WG shuts down.  If the
> answer is NO.  The working group recharters and we get to actual work.
>
> Rough consensus to that is unequivocal.  So let's stop equivocating and get
> to work  - together.
>
>
>
> Ian Chakeres wrote:
>>
>>>>> to
>>>>> requests
>>>>> to

---

From: "David E. Culler" <[email-masked]>
Date: Fri, 30 Jan 2009 10:41:16 -0800

> I would like to second Ian on this front.
Of course.  We already know that you are interested in working on 
protocols for ROLL - once we recharter.  But, we cannot do any work on 
any protocols until the survey document is complete.  The issue is not 
whether there is a little tweaking and beautifying here or there.  The 
issue is YES or NO.  Is there an existing IETF routing protocol that 
satisfies the requirement.

You have clearly indicated that you believe that there is work that must 
be done to achieve a ROLL solution.  Perhaps that work may even be done 
relative to dymo.  That is wonderful, but irrelevant at this time.  Only 
once we all come together and say "we have done the survey and the 
answer is NO" can we even begin to think about solutions.  This is why I 
am asking you and Ian to allow us to finally make that step and move 
forward.  We should not hold the due-diligence process hostage.  There 
is a huge industry out there waiting for an IETF standard to emerge for 
links such as IEEE 802.15.4.  There are already multiple industrial 
forums producing incompatible standards, including HART, SP100, and 
Zigbee, even for this one specific link.  There are innumerable 
proprietary solutions and open, incompatible solutions for this same 
link.  There is an active effort to move the link forward with IEEE 
802.15.4e.  There are low power enhancements to 802.11.  All this is 
moving forward into an incompatible morass while we debate niceties 
about where we must include rev -15 or rev -16 or rev -17 of one of the 
many candidate solutions.  That is not the point.  The point is to get 
on with doing the real work to solve this real problem.  And by the way, 
there are many many other candidates that have been out there delivering 
in this space for years - but they are not holding the process back.  
Each day we continue this deliberation is another day we fall farther 
behind and the world moves on without an open standard solution in this 
space.

So, I respectfully request that you limit your concerns at this time to 
whether there are any major errors in the analysis of dymo -15 and 
please provide specific suggestions for wording changes.  Once we 
recharter, we can happily consider -16 or any other rev as a potential 
solution. 
> try to get through it over the weekend, and will post my comments here 
> (despite those in the past having been explicitly qualified as 
> "disruptive").
>
> Sincerely,
>
> Thomas
>

---

From: Philip Levis <[email-masked]>
Date: Fri, 30 Jan 2009 09:27:03 -0800

On Jan 30, 2009, at 8:32 AM, Thomas Heide Clausen wrote:

> the distance metric can be set to consider both "link cost" and  
> "node cost". As such, and on that front, I do not thing that this is  
> a "moving target" but rather is something that should be corrected.

Ah -- I was talking about loss response. That was an actual change in  
the specification, not just a clarification.

I think there's a misunderstanding here. Please note that "node cost"  
is actually more than a simple scalar value:

" However, in low power networks it is also desirable to account for
    the cost of forwarding through particular routers.  Applications
    require node or parameter constrained routing, which takes into
    account node properties and attributes such as power, memory, and
    battery life that dictate a router's willingness or ability to route
    other packets."

It was my understanding that "parameter constrained routing" as a term  
represents concerns that cannot be simply merged with a scalar notion  
of cost. That's why DYMO has a fail. The draft had node cost for DYMO  
as a "?" until it went from a personal draft to a WG draft. As DYMO  
does not specify the calculation of the distance metric (besides the  
hopcount inequality), clearly nodes can incorporate local costs into  
advertisements.

The the entry in the table changed from "?" to "fail" based on  
feedback made in Dublin at the WG meeting.

Does that make sense? Do you agree that DYMO's scalar cost cannot  
express predicates?

Phil

---

From: Ian Chakeres <[email-masked]>
Date: Fri, 30 Jan 2009 14:06:49 -0500

DYMO can take these properties/attributes into account using the
(dimension-less) distance metric.

I am guessing that we may have different opinions about how these
constraints can/should be conveyed to a routing protocol.

Ian

On Fri, Jan 30, 2009 at 12:27 PM, Philip Levis <[email-masked]> wrote:
<snip>
>   battery life that dictate a router's willingness or ability to route
<snip>