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

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 2 Feb 2009 19:26:48 +0100

But wait, Ian, either my [now dated] implementation of an early  
version of DYMO (-06, I think?) was wrong, or this has been possible  
since at least then -- although maybe not at the time spelled out  
explicitly?

Thomas

On Jan 30, 2009, at 8:06 PM, Ian Chakeres wrote:

> 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>
>> " 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."
> <snip>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

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

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 2 Feb 2009 19:37:27 +0100

All,

I promised a review, and I apologize that I wasn't able to do so  
before the weekend as originally projected.

Other than some typos that Chris and others have pointed out, I'll  
try to offer my understanding of the problem space and suggest some  
ways of addressing my main concerns....

My first main concern remain that it is not clear, still, how ROLL  
positions itself with respect to MANET, 6LOW et. al, all of which  
appear to be within the same space and within the IETF. This I-D sees  
ROLL as presented with entirely new problems (the use of "novel" in  
the abstract, the statement that "existing protocols were not  
designed with these requirements in mind" seem to confirm this).

Looking at the  requirements listed, including "low power, low  
bandwidth, low footprint", these appear similar to those which are  
also brought forward in e.g. MANET and 6LOW. Reading (quickly, I  
confess) the various requirements documents  of the draft-ietf-roll  
series present scenarios which are similar to those where MANETs are  
deployed, and are thought deployed, as well.

I also note that many additional (and unstated) characteristics  
between ROLL and e.g. MANET are the same: mobile, wireless,  
fragility, auto-configuration, IP routing, interface/link issues...

Arguing that, as does this I-D, despite the above impression "ROLL is  
novel and different" invites asking "how, exactly?" I think that this  
question is valid, and merits being answered, before the evaluations  
in this I-D can be judged fairly.

Note that I come from a MANET background, and so I *could* interpret  
from the ROLL discussion that where MANETs may aim for "low power,  
low bandwidth, ....", ROLL may be able to quantify these as "below  
this firm threshold" -- i.e. as a sort of "extreme" or "constrained"  
MANET.

This is a personal observation, I note, which would allow me to  
comprehend how ROLL and MANET are positioned relative to one another  
-- but one which neither this I-D nor the requirements document spell  
out or quantify -- or, for that matter, debunk.

I think it's critical to understand this, in order to understand the  
need for a new protocol development. I think it is important to  
document this understanding in something with more persistency.

If what I suggest above makes sense as a way of positioning ROLL and  
MANET relative to one another, I'd suggest including something to  
this effect in the survey I-D, as this I-D is the one making a  
*direct* reference to the applicability of MANET protocols to ROLL.

If what I suggest doesn't make sense at all, then I'd be happy to  
have it debunked and, hopefully, through that debunking a positioning/ 
description that does ring true with us all can be produced?

My second main concern is, that I still think that the choice of  
criteria is unfortunate (not the word, Phill has me convinced on that  
front, but the actual criteria). Control cost is, by all means, a  
rather meaningless criteria when taken in isolation. I've sketched a  
"zero-control-cost" routing protocol (flood all data - say use SMF,  
also a MANET protocol, and also a rather "mature" I-D and wg item)  
which would score well on the control cost criteria, but would likely  
be an extremely bad choice for delivering unicast data.

The metric which matters, and which should matter to ROLL in  
particular, is "the total cost of getting user data through the  
network, including control cost necessary to set up paths" -- as we  
know, every packet sent and received costs bandwidth, energy and  
cycles -- user data no different from contro.

According to the criterions as set up by this I-D, a protocol  
producing "longer than shortest paths" at the benefit of slightly  
lower control cost would score better than a protocol producing  
"shortest paths" with slightly higher control cost. This is not  
hypothetical, btw., there are plenty of studies observing and  
reflecting upon this regarding the different MANET protocols, in  
academic literature -- and observed in real networks as well.

I note that this trade-off (slightly longer paths for lower control  
cost) may be perfectly fair, assuming that very low amounts of user  
data traffic transit through the network. However, I do not see this  
assumption mentioned as a justification for focusing on the control  
cost metric and discarding the "path length" or the "total cost of  
getting user data through the network".

I believe that either these assumptions should be made explicit  
("there's so little user data traffic in a ROLL network that we do  
not care about shortest paths") or -- if these assumptions do not  
hold, that the evaluation criteria are incomplete.

I note that it's true that we can always add another criteria ad  
infinitum, and that's CLEARLY not what we want to do. However when I  
say "incomplete" in the above, I simply suggest that based on what is  
presented one cannot draw conclusions based on the evaluation  
criteria....or, worse, that one draws the wrong conclusions based on  
the information presented.

So, in a nutshell, I suggest that we address (i) the positioning  
issue and (ii) the criteria issue thus:

	o	Describe as I proposed above if ROLL and MANETs position  
themselves as I
		have deducted. If my deduction is incorrect, then let's quickly  
iterate on the list
		as to understand how to do produce an alternative description. If  
we can't do this,
		then the conclusion can be that "we do not know how ROLL and MANET  
position
		themselves wrt each other", and we could then state that clearly?
		
		It *should* not be more than a couple of paragraphs worth of text  
to add, I gather?

	o	To the criteria, either of:

			-	Add the assumption that "user data traffic is so low that path  
lengths do not
				matter nor does the cost of carrying user data traffice"

			-	Add a criteria & evaluation of "path length"

			-	Add a criteria & evaluation of "total cost for getting user data  
through the network"

This would make a large chunk of my concerns and issues vanish, and  
allow correctly interpreting and evaluating the rest of the document.

How does that sound as an approach forward?

Cheers,

Thomas

On Jan 27, 2009, at 1:00 AM, [email-masked] wrote:

> 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.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>

---

From: Ian Chakeres <[email-masked]>
Date: Mon, 2 Feb 2009 17:33:34 -0500

Thomas as you pointed out, it has been possible for quite some time.
Recently, I did edit the document to call more attention to this
feature.

Ian

On Mon, Feb 2, 2009 at 1:26 PM, Thomas Heide Clausen
<[email-masked]> wrote:
> But wait, Ian, either my [now dated] implementation of an early version of
> DYMO (-06, I think?) was wrong, or this has been possible since at least
> then -- although maybe not at the time spelled out explicitly?
>
> Thomas
>
>> 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
>>>  other packets."
>>
>> <snip>

---

From: Mischa Dohler <[email-masked]>
Date: Mon, 02 Feb 2009 23:33:37 +0100

Thomas, all,

I have not been part of the decade design efforts of MANET but here some high-level differences which had been circulating before and which triggered the birth of ROLL:

6LoWPAN: 
- mainly specifies IPv6 header compression but not (optimized) routing per se;
- is stuck to IEEE 802.15.4 radios.

MANET:
- design paradigm is to offer certain QoS and see how long we can run the network, whereas in ROLL we are likely to go the other way, ie optimize the longevity/energy efficiency and see what we can offer (maybe a hybrid of both);
- properties of data contents is not (or in limited form) used to facilitate protocol designs, whereas in ROLL this is likely going to be central to the routing protocol design (example is the convergecast traffic pattern where not every node wishes to communicate with any other node, etc).

As for your proposition, I have another one: Why don't we stop here and get on with the actual protocol design stage, knowing that some criteria may not be ideal or not applicable or of little use. Having a set of protocols at hand gives us a much clearer idea which parameters are of real key importance. I guess the discussion on the criteria could potentially last some more months - a time we cannot afford. The WSN market is different from the MANET market - it is very much alive and it is moving quickly. I know of at least two WSN companies who make good money with their networks but which have not gone for any MANET routing protocol - there must have been a reasoning behind this design choice. ROLL hopes to make companies choose its routing protocol(s) in the near future.

Thanks for your support,
Mischa.

Thomas Heide Clausen wrote:
> All,
> 
> I promised a review, and I apologize that I wasn't able to do so before 
> the weekend as originally projected.
> 
> Other than some typos that Chris and others have pointed out, I'll try 
> to offer my understanding of the problem space and suggest some ways of 
> addressing my main concerns....
> 
> positions itself with respect to MANET, 6LOW et. al, all of which appear 
> to be within the same space and within the IETF. This I-D sees ROLL as 
> presented with entirely new problems (the use of "novel" in the 
> abstract, the statement that "existing protocols were not designed with 
> these requirements in mind" seem to confirm this).
> 
> bandwidth, low footprint", these appear similar to those which are also 
> brought forward in e.g. MANET and 6LOW. Reading (quickly, I confess) the 
> various requirements documents  of the draft-ietf-roll series present 
> scenarios which are similar to those where MANETs are deployed, and are 
> thought deployed, as well.
> 
> I also note that many additional (and unstated) characteristics between 
> ROLL and e.g. MANET are the same: mobile, wireless, fragility, 
> auto-configuration, IP routing, interface/link issues...
> 
> question is valid, and merits being answered, before the evaluations in 
> this I-D can be judged fairly.
> 
> from the ROLL discussion that where MANETs may aim for "low power, low 
> bandwidth, ....", ROLL may be able to quantify these as "below this firm 
> threshold" -- i.e. as a sort of "extreme" or "constrained" MANET.
> 
> comprehend how ROLL and MANET are positioned relative to one another -- 
> but one which neither this I-D nor the requirements document spell out 
> or quantify -- or, for that matter, debunk.
> 
> need for a new protocol development. I think it is important to document 
> this understanding in something with more persistency.
> 
> MANET relative to one another, I'd suggest including something to this 
> effect in the survey I-D, as this I-D is the one making a *direct* 
> reference to the applicability of MANET protocols to ROLL.
> 
> If what I suggest doesn't make sense at all, then I'd be happy to have 
> it debunked and, hopefully, through that debunking a 
> positioning/description that does ring true with us all can be produced?
> 
> front, but the actual criteria). Control cost is, by all means, a rather 
> meaningless criteria when taken in isolation. I've sketched a 
> "zero-control-cost" routing protocol (flood all data - say use SMF, also 
> a MANET protocol, and also a rather "mature" I-D and wg item) which 
> would score well on the control cost criteria, but would likely be an 
> extremely bad choice for delivering unicast data.
> 
> The metric which matters, and which should matter to ROLL in particular, 
> is "the total cost of getting user data through the network, including 
> control cost necessary to set up paths" -- as we know, every packet sent 
> and received costs bandwidth, energy and cycles -- user data no 
> different from contro.
> 
> According to the criterions as set up by this I-D, a protocol producing 
> "longer than shortest paths" at the benefit of slightly lower control 
> cost would score better than a protocol producing "shortest paths" with 
> slightly higher control cost. This is not hypothetical, btw., there are 
> plenty of studies observing and reflecting upon this regarding the 
> different MANET protocols, in academic literature -- and observed in 
> real networks as well.
> 
> cost) may be perfectly fair, assuming that very low amounts of user data 
> traffic transit through the network. However, I do not see this 
> assumption mentioned as a justification for focusing on the control cost 
> metric and discarding the "path length" or the "total cost of getting 
> user data through the network".
> 
> ("there's so little user data traffic in a ROLL network that we do not 
> care about shortest paths") or -- if these assumptions do not hold, that 
> the evaluation criteria are incomplete.
> 
> infinitum, and that's CLEARLY not what we want to do. However when I say 
> "incomplete" in the above, I simply suggest that based on what is 
> criteria....or, worse, that one draws the wrong conclusions based on the 
> information presented.
> 
> So, in a nutshell, I suggest that we address (i) the positioning issue 
> and (ii) the criteria issue thus:
> 
>         as to understand how to do produce an alternative description. 
> If we can't do this,
>         then the conclusion can be that "we do not know how ROLL and 
> MANET position
>         It *should* not be more than a couple of paragraphs worth of 
> text to add, I gather?
> 
>             -    Add the assumption that "user data traffic is so low 
> that path lengths do not
>             -    Add a criteria & evaluation of "total cost for getting 
> user data through the network"
> 
>>     Title        : Overview of Existing Routing Protocols for Low 
>> Power and Lossy Networks
>>    important.  Wireless link qualities can vary significantly over time,
>>    change energy costs.  Routing over such low power and lossy networks
>>    has novel requirements that existing protocols may not address.  This
>>    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.
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-05.txt 
>>
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 00:21:39 +0100

Mischa Dohler a écrit :
[...]
> As for your proposition, I have another one: Why don't we stop here
> and get on with the actual protocol design stage,

Sorry, which protocol do we mean to go on to protocol design stage?

Could one imagine starting from scratch designing a new protocol?

Alex

  knowing that some
> criteria may not be ideal or not applicable or of little use. Having
> a set of protocols at hand gives us a much clearer idea which
> parameters are of real key importance. I guess the discussion on the
> criteria could potentially last some more months - a time we cannot
> afford. The WSN market is different from the MANET market - it is
> very much alive and it is moving quickly. I know of at least two WSN
> companies who make good money with their networks but which have not
> gone for any MANET routing protocol - there must have been a
> reasoning behind this design choice. ROLL hopes to make companies
> choose its routing protocol(s) in the near future.
> 
> Thanks for your support, Mischa.
> 
> 
> 
> 
>>  appear to be within the same space and within the IETF. This I-D
>> sees ROLL as presented with entirely new problems (the use of
>> "novel" in the abstract, the statement that "existing protocols
>> were not designed with these requirements in mind" seem to confirm
>> this).
>> 
>>  series present scenarios which are similar to those where MANETs
>> are deployed, and are thought deployed, as well.
>> 
>> Arguing that, as does this I-D, despite the above impression "ROLL
>> is novel and different" invites asking "how, exactly?" I think that
>> this question is valid, and merits being answered, before the
>> evaluations in this I-D can be judged fairly.
>> 
>> Note that I come from a MANET background, and so I *could*
>> interpret from the ROLL discussion that where MANETs may aim for
>> "low power, low bandwidth, ....", ROLL may be able to quantify
>> these as "below this firm threshold" -- i.e. as a sort of "extreme"
>> or "constrained" MANET.
>> 
>> comprehend how ROLL and MANET are positioned relative to one
>> another -- but one which neither this I-D nor the requirements
>> document spell out or quantify -- or, for that matter, debunk.
>> 
>> I think it's critical to understand this, in order to understand
>> the need for a new protocol development. I think it is important to
>> If what I suggest above makes sense as a way of positioning ROLL
>> and MANET relative to one another, I'd suggest including something
>> to this effect in the survey I-D, as this I-D is the one making a
>> have it debunked and, hopefully, through that debunking a 
>> criteria is unfortunate (not the word, Phill has me convinced on
>> that front, but the actual criteria). Control cost is, by all
>> means, a rather meaningless criteria when taken in isolation. I've
>> sketched a "zero-control-cost" routing protocol (flood all data -
>> say use SMF, also a MANET protocol, and also a rather "mature" I-D
>> and wg item) which would score well on the control cost criteria,
>> but would likely be an extremely bad choice for delivering unicast
>> data.
>> 
>>  cost) may be perfectly fair, assuming that very low amounts of
>> user data traffic transit through the network. However, I do not
>> see this assumption mentioned as a justification for focusing on
>> the control cost metric and discarding the "path length" or the
>> "total cost of getting user data through the network".
>> 
>> infinitum, and that's CLEARLY not what we want to do. However when
>> I say "incomplete" in the above, I simply suggest that based on
>> what is presented one cannot draw conclusions based on the
>> evaluation criteria....or, worse, that one draws the wrong
>> conclusions based on the information presented.
>> 
>> themselves as I have deducted. If my deduction is incorrect, then
>> let's quickly iterate on the list as to understand how to do
>> produce an alternative description. If we can't do this, then the
>> conclusion can be that "we do not know how ROLL and MANET position 
>> lengths do not matter nor does the cost of carrying user data
>> traffice"
>> 
>> -    Add a criteria & evaluation of "total cost for getting user
>> data through the network"
>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>>  Internet-Draft. Content-Type: text/plain Content-ID:
>>> <[email-masked]>
>>> 
>>> _______________________________________________ Roll mailing list
>>>  [email-masked] https://www.ietf.org/mailman/listinfo/roll
>> 
>> _______________________________________________ Roll mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________ Roll mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 01:02:36 +0100

Mischa Dohler a écrit :
[...]
> 6LoWPAN: - mainly specifies IPv6 header compression but not
> (optimized) routing per se;

Not only Header Compression, 6lowpan WG seems to also be looking at
Neighbor Discovery for 802.15.4, which is quite relevant here I believe,
because ZigBee was mentioned recently here.

> - [6lowpan] is stuck to IEEE 802.15.4 radios.

I think it is good to list the radios ROLL looks at:

IEEE 802.15.4
SP100 http://tinyurl.com/4d3j64
ZigBee
HART http://tinyurl.com/4d3j64

Alex

> 
> MANET: - design paradigm is to offer certain QoS and see how long we
> can run the network, whereas in ROLL we are likely to go the other
> way, ie optimize the longevity/energy efficiency and see what we can
> offer (maybe a hybrid of both); - properties of data contents is not
> (or in limited form) used to facilitate protocol designs, whereas in
> ROLL this is likely going to be central to the routing protocol
> design (example is the convergecast traffic pattern where not every
> node wishes to communicate with any other node, etc).
> 
> and get on with the actual protocol design stage, knowing that some

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 01:22:30 +0100

Arsalan Tavakoli a écrit :
> As was discussed earlier, at the protocol design stage, the group 
> will be soliciting specifications for a protocol that meets the ROLL
>  requirements, whether it is an extension/modification of an existing
>  protocol, or a specification written from scratch.  Advancing to
> that stage simply implies that no such specification (in its current
> form) presently exists.

The protocol-survey draft wouldn't impede going to the next
stage, were it silently updated every 6 months, away from LastCall.

We could probably then discuss requirements.

Let me humbly propose a 're-usability' requirement, common: "an 
important requirement is to identify and reuse as much as
possible an existing protocol that pertains to this application domain;
this has the immediate advantage of software availability for first
prototypes".

What do you think?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 08:24:29 +0100

Arsalan Tavakoli a écrit :
> On Mon, Feb 2, 2009 at 4:22 PM, Alexandru Petrescu 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>>>  will be soliciting specifications for a protocol that meets the 
>>> ROLL requirements, whether it is an extension/modification of an
>>>  existing protocol, or a specification written from scratch. 
>>> Advancing to that stage simply implies that no such specification
>>>  (in its current form) presently exists.
>> 
>> The protocol-survey draft wouldn't impede going to the next stage, 
>> were it silently updated every 6 months, away from LastCall.
> 
> I don't particularly understand the need for such a move.  By 
> definition, holding up the protocol-survey draft IS holding up going 
> to the next stage.

I don't understand this definition at all.  I think we could very well
go to the next stage without necessarily LC'ing the protocol-survey
draft.  In this way we could avoid deep controversion about which
existing protocol is better.

If protocol-survey sets some conclusions - I think they will constrain
the next stage more than the requirements drafts.  Don't you think so?

I think each item in the Charter's timeline is completely independent, 
no? (they're not sequentially dependent).

Alex

   The purpose of the protocol survey draft is to
> determine whether an existing specification, again in current form, 
> satisfies the set of criteria.  Our current charter is limited to 
> answering this question.  In order to move to the design stage, at 
> which point we start discussing actual protocol and design, we need 
> to recharter, and we can not do that until this draft is finalized, 
> hence why this draft impedes us from moving on.  By definition, the 
> protocol specified during the next stage will satisfy the ROLL 
> requirements, and changes to existing protocol specifications (for 
> those evaluated in the draft) to allow them to pass ROLL criteria, 
> can be presented during the next stage, which would make an update of
>  the document a moot point.
> 
> 
> 
> 
> important requirement is to identify and reuse as much as possible an
>  existing protocol that pertains to this application domain; this has
>  the immediate advantage of software availability for first 
> prototypes".
> 
> 
> Again, as David has written frequently, these are all very important 
> issues that will need to be discussed when we move to the protocol 
> and design stage.  However, this is completely outside the scope of 
> the protocol survey draft, and hence I believe should not be 
> discussed in the draft.  The draft takes no position on such a 
> requirement.  If we can close on this draft, then we can recharter, 
> and move on to the next stage, at which point all these issues that 
> everybody is so anxious to get to can be discussed, rather than 
> having to continually to postpone them as we block on this document.
> 
> 
> 
> 
> What do you think?
> 
> Alex _______________________________________________ Roll mailing 
> list [email-masked] <mailto:[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 10:04:19 +0100

Arsalan Tavakoli a écrit :
 > A. Petrescu wrote:
>> important requirement is to identify and reuse as much as possible
>> an existing protocol that pertains to this application domain; this
>> has the immediate advantage of software availability for first 
>> prototypes".
> 
> requirement.

Sorry, I meant the reusability requirement proposal for the 4 
requirements drafts, not for the protocols-survey draft.

What do you think?

Alex

---

From: JP Vasseur <[email-masked]>
Date: Tue, 3 Feb 2009 13:19:18 +0100

OK Thanks.

JP.

On Jan 29, 2009, at 11:58 AM, Ulrich Herberg wrote:

> 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
>
> Philip Levis wrote:
>> On Jan 26, 2009, at 4:00 PM, [email-masked] wrote:
>>
>> 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: JP Vasseur <[email-masked]>
Date: Tue, 3 Feb 2009 13:20:52 +0100

Hi Alex,

> Could one imagine starting from scratch designing a new protocol?

We have detailed routing requirements documents. Should we re-charter,  
the process gets quite simple. Look at different candidates and
how close they are to the requirements. Then select one or two (in  
which case we need clear applicability statement). And yes if we can
use an adapted existing protocol, then great. Note that this is no  
different than what is done with many other WGs. Let me quickly share
some experience here. In the PCE WG that I'm co-chairing for several  
years we faced a very similar situations. Several application
specific requirements and about 7 protocol proposals on the table  
including existing protocols (BGP, RSVP, SIP, ...) to be considered
and new ones. It took *one* WG meeting to draw a consensus: yes that  
was difficult but we managed to get a consensus. Bottom line?
About 1 year to stabilize the protocol, now 10 implementations :-) Why  
should it be different here ?

Cheers.

Thanks.

JP.

>>>> 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/
>>> _______________________________________________ Roll mailing list [email-masked] 
>> _______________________________________________ Roll mailing list [email-masked]

---

From: JP Vasseur <[email-masked]>
Date: Tue, 3 Feb 2009 13:20:58 +0100

> because ZigBee was mentioned recently here.

HOLD-ON ... We are NOT working on ZIGBEE here. Let's not go there.  
This is the IETF, we work on IP.

> HART http://tinyurl.com/4d3j64

There is quite a bit of confusion. Zigbee is non-IP and build above  
15.4.
We are designing IP-solution and indeed 15.4 is one of the PHY/MAC LLN  
may run onto.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Tue, 3 Feb 2009 13:21:04 +0100

On Feb 3, 2009, at 8:24 AM, Alexandru Petrescu wrote:

>> On Mon, Feb 2, 2009 at 4:22 PM, Alexandru Petrescu <[email-masked] 
>>  <mailto:[email-masked]>> wrote:
>> definition, holding up the protocol-survey draft IS holding up  
>> going to the next stage.
>

Ah you missed something here, glad you raise the point. The *only* aim  
of the protocol survey is to see whether
an existing protocol (with no change) can be used, that's it. Once re- 
chartered we will go back to the requirements
documents.

>
>
> I think each item in the Charter's timeline is completely  
> independent, no? (they're not sequentially dependent).
>

That depends ... in this case, we want the question answered.

Thanks.

JP.

>> Again, as David has written frequently, these are all very  
>> important issues that will need to be discussed when we move to the  
>> protocol and design stage.  However, this is completely outside the  
>> scope of the protocol survey draft, and hence I believe should not  
>> be discussed in the draft.  The draft takes no position on such a  
>> list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Arsalan Tavakoli <[email-masked]>
Date: Mon, 2 Feb 2009 15:35:42 -0800

As was discussed earlier, at the protocol design stage, the group will be
soliciting specifications for a protocol that meets the ROLL requirements,
whether it is an extension/modification of an existing protocol, or a
specification written from scratch.  Advancing to that stage simply implies
that no such specification (in its current form) presently exists.
- Arsalan

On Mon, Feb 2, 2009 at 3:21 PM, Alexandru Petrescu <
[email-masked]> wrote:

>>> Looking at the  requirements listed, including "low power, low bandwidth,
>>> low footprint", these appear similar to those which are
>>> ROLL and e.g. MANET are the same: mobile, wireless,
>>> My second main concern is, that I still think that the choice of criteria
>>> is unfortunate (not the word, Phill has me convinced on
>>> control cost necessary to set up paths" -- as we
>>>  know, every packet sent and received costs bandwidth, energy and cycles
>>> -- user data no different from contro.
>>>
>>> "longer than shortest paths" at the benefit of slightly lower control cost
>>> would score better than a protocol producing "shortest paths" with slightly
>>> higher control cost. This is not hypothetical, btw., there are plenty of
>>> studies observing and reflecting upon this regarding the different MANET
>>> protocols, in academic literature -- and observed in real networks as well.
>>>
>>> I believe that either these assumptions should be made explicit ("there's
>>> so little user data traffic in a ROLL network that we do
>>> o    Describe as I proposed above if ROLL and MANETs position themselves
>>> as I have deducted. If my deduction is incorrect, then
>>> themselves wrt each other", and we could then state that clearly? It
>>> *should* not be more than a couple of paragraphs worth of text
>>> to add, I gather?
>>>
>>>> Lossy Networks Author(s)    : A. Tavakoli, S.
>>>> protocols with respect to this class of networks.  From this survey it
>>>> examines whether existing and mature IETF protocols can

---

From: Arsalan Tavakoli <[email-masked]>
Date: Mon, 2 Feb 2009 16:53:04 -0800

Comments Inline.

On Mon, Feb 2, 2009 at 4:22 PM, Alexandru Petrescu <
[email-masked]> wrote:

>> soliciting specifications for a protocol that meets the ROLL

I don't particularly understand the need for such a move.  By definition,
holding up the protocol-survey draft IS holding up going to the next stage.
 The purpose of the protocol survey draft is to determine whether an
existing specification, again in current form, satisfies the set of
criteria.  Our current charter is limited to answering this question.  In
order to move to the design stage, at which point we start discussing actual
protocol and design, we need to recharter, and we can not do that until this
draft is finalized, hence why this draft impedes us from moving on.  By
definition, the protocol specified during the next stage will satisfy the
ROLL requirements, and changes to existing protocol specifications (for
those evaluated in the draft) to allow them to pass ROLL criteria, can be
presented during the next stage, which would make an update of the document
a moot point.

> Let me humbly propose a 're-usability' requirement, common: "an important
> requirement is to identify and reuse as much as

Again, as David has written frequently, these are all very important issues
that will need to be discussed when we move to the protocol and design
stage.  However, this is completely outside the scope of the protocol survey
draft, and hence I believe should not be discussed in the draft.  The draft
takes no position on such a requirement.  If we can close on this draft,
then we can recharter, and move on to the next stage, at which point all
these issues that everybody is so anxious to get to can be discussed, rather
than having to continually to postpone them as we block on this document.

---

From: JP Vasseur <[email-masked]>
Date: Tue, 3 Feb 2009 13:19:59 +0100

Dear WG and ADs,

Two issues are raised here for which we would appreciate ADs' point of  
view and feed-back from the WG. Please see in line.

Dear Thomas,

At the risk of repeating myself, I'd like to make a few important  
statements before *hopefully* come to a closure ;-)

-> As you know, many of the ROLL WG active participants have been  
working quite hard to produce a detailed set of requirements, discuss  
how to proceed on the protocol survey document, and other ID are in  
the works.
-> We managed to get highly experienced contributors in the field that  
have designed and deployed solutions so they not only have an  
excellent expertise of the requirements but also on solutions,
-> Yes we need to rush out. Why ? Because proprietary or semi-closed  
non-IP solutions are being deployed at a fairly large scale. I do not  
think that I have to convince anybody on this list that this is the  
WRONG approach for a number of reasons. The industry is asking for an  
IP solution *now*.
-> No we do not want to re-invent the wheel (see our presentation at  
the routing plenary in Chicago). Anything that already exists MUST  
(rfc2119 ;-)) be used provided that it meets our requirements. And if  
we can adapt an existing protocol, we are all for it !
-> Yes these requirements are quite specifics and this is precisely  
why ROLL has been formed, 4 application-specific routing requirements  
have been produced (to reduce the scope). Even if at a first sight, it  
looks very much similar to a MANET issue (and there ARE similarities  
but also very different requirements), having to deal with a highly  
static network of hundreds of thousands of battery operated sleeping  
nodes with 4K of RAM is quite specific. Note that this is not a random  
example, but an on-going non-IP deployed network.

And to conclude on this introduction ... after an outstanding progress  
on the WG during the first 6-8 months, we have been slowed down  
dramatically for the last 2 months, thus it is time to close and move  
on to quickly re-charter and start the protocol work (hopefully as  
light as possible) to see IP-based solution deployed. I know that we  
are on the same page, we just need to find a good compromise on both  
"sides".

Nothing new so far, let's move to a proposed resolution - See in line,

On Feb 2, 2009, at 7:37 PM, Thomas Heide Clausen wrote:

> "novel" in the abstract, the statement that "existing protocols were  
> not designed with these requirements in mind" seem to confirm this).
>
> -- but one which neither this I-D nor the requirements document  
> spell out or quantify -- or, for that matter, debunk.
>
> that front, but the actual criteria). Control cost is, by all means,  
> a rather meaningless criteria when taken in isolation. I've sketched  
> a "zero-control-cost" routing protocol (flood all data - say use  
> SMF, also a MANET protocol, and also a rather "mature" I-D and wg  
> item) which would score well on the control cost criteria, but would  
> likely be an extremely bad choice for delivering unicast data.
>
> say "incomplete" in the above, I simply suggest that based on what  
> is presented one cannot draw conclusions based on the evaluation  

It is not easy to answer each of your point without running the risk  
to start a debate that will never end. You raised some excellent  
points that I agree with and others that I firmly disagree with ... So  
let me try to make a few observations:
1) As pointed out earlier, yes there are similarities between MANET  
and ROLL. I do not see this as an issue.
2) The aim of the protocol survey IS NOT to exclude MANET protocols.  
As mentioned many times on the list, we *only* wanted to show that  
existing protocols, with no change, could not be used in LLNs. This  
has been clarified in the document as your request and it HAD to be  
clarified.
3) We could have used two different approaches for the survey:
	- Look at all MUST from the requirements documents
	- Try to derive a subset of necessary but not sufficient criteria,  
which the WG chose to do (consensus). Yes this list is not perfect,
	criteria could be changed, removed or added but looked good enough  
with excellent consensus until LC.
4) With regards to 6lowpan (I copy the chair), I do not see any  
overlap at all. Please refer to their charter and WG items. The only  
place that required clarification was the routing requirements and I  
was personally opposed to it but this was adopted as a 6lowpan WG item  
by consensus. We're are working together and managed to sort this out.  
This document will be 6lowpan specific.

What I want to avoid is an endless discussion on the positioning of  
ROLL, MANET, 6lowpan and quite frankly we could add other WGs to the  
list.

So what is the bottom line ?

We just need to agree on the fact that there is no existing protocol  
that meets the ROLL requirements and move to the next step (re- 
chartering) to select one (hopefully not two) routing protocols in  
light of the routing requirement (NOT the protocol survey), which can  
either be an adapted MANET protocol or a new protocol.

Now moving to your proposed resolution.

> 		It *should* not be more than a couple of paragraphs worth of text  

If you find a way to word this, please feel free and I'd be happy to  
help but feel it as necessary ... Any opinion from our RTG and INT ADs ?

> 				matter nor does the cost of carrying user data traffice"

The motivation for selecting a longer path is not tied to the amount  
of traffic here but the level of constraints. Note that this is also  
true for several other technologies such as MPLS-TE. You may have  
large amount of traffic and still require to follow a non-shortest  
path (constrained based routing). This is detailed in several  
requirements IDs. Criticality of data is of course different, thus the  
requirements for potentially different data paths according to packet  
marking using DSCP.

> data through the network"

And we can add many more but if the current protocol do not satisfy  
existing requirements, isn't it sufficient to answer the question on  
whether one can find an existing protocol?

> allow correctly interpreting and evaluating the rest of the document.

That said, question for the WG. Who think that such criteria should be  
added to move forward ? Please reply.

> How does that sound as an approach forward?

Thanks for helping out.

Cheers.

JP.

>> be

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 3 Feb 2009 14:19:12 +0100

Dear JP, dear ADs, dear WG,

For the record, I am not arguing that MANET protocols should be  
applied or be applicable -- as you seem to suggest in your email. I  
believe that I have stated so repeatedly.

I submit, however, that as it is currently exposed, ROLL, MANET and  
6LOW seem to be operating within the same space -- to the untrained  
eye, in exactly the same space. My position is that it would be very  
unfortunate having one WG creating confusion on the applicability of  
the work of itself and of other IETF wg's, by simple omission of  
suitable perimeter definitions.

In that sort of situation, the IETF needs to be extra prudent to make  
sure to clearly spell out suitable perimeter definitions prior to, or  
conjointly with, the first publication cycle. In this case, before or  
with the survey I-D.

Sincerely,

Thomas

On Feb 3, 2009, at 1:19 PM, JP Vasseur wrote:

> Dear WG and ADs,
>
> Two issues are raised here for which we would appreciate ADs' point  
> of view and feed-back from the WG. Please see in line.
>
>
> Dear Thomas,
>
> working quite hard to produce a detailed set of requirements,  
> discuss how to proceed on the protocol survey document, and other  
> ID are in the works.
> -> We managed to get highly experienced contributors in the field  
> that have designed and deployed solutions so they not only have an  
> -> Yes we need to rush out. Why ? Because proprietary or semi- 
> closed non-IP solutions are being deployed at a fairly large scale.  
> I do not think that I have to convince anybody on this list that  
> this is the WRONG approach for a number of reasons. The industry is  
> asking for an IP solution *now*.
> -> No we do not want to re-invent the wheel (see our presentation  
> at the routing plenary in Chicago). Anything that already exists  
> MUST (rfc2119 ;-)) be used provided that it meets our requirements.  
> And if we can adapt an existing protocol, we are all for it !
> why ROLL has been formed, 4 application-specific routing  
> requirements have been produced (to reduce the scope). Even if at a  
> first sight, it looks very much similar to a MANET issue (and there  
> ARE similarities but also very different requirements), having to  
> deal with a highly static network of hundreds of thousands of  
> battery operated sleeping nodes with 4K of RAM is quite specific.  
> Note that this is not a random example, but an on-going non-IP  
> deployed network.
>
> And to conclude on this introduction ... after an outstanding  
> progress on the WG during the first 6-8 months, we have been slowed  
> down dramatically for the last 2 months, thus it is time to close  
> and move on to quickly re-charter and start the protocol work  
> (hopefully as light as possible) to see IP-based solution deployed.  
> I know that we are on the same page, we just need to find a good  
> compromise on both "sides".
>
>> try to offer my understanding of the problem space and suggest  
>> some ways of addressing my main concerns....
>>
>> confess) the various requirements documents  of the draft-ietf- 
>> roll series present scenarios which are similar to those where  
>> MANETs are deployed, and are thought deployed, as well.
>>
>> is novel and different" invites asking "how, exactly?" I think  
>> that this question is valid, and merits being answered, before the  
>> these as "below this firm threshold" -- i.e. as a sort of  
>> "extreme" or "constrained" MANET.
>>
>> the need for a new protocol development. I think it is important  
>> to document this understanding in something with more persistency.
>>
>> network, including control cost necessary to set up paths" -- as  
>> we know, every packet sent and received costs bandwidth, energy  
>> and cycles -- user data no different from contro.
>>
>> I note that this trade-off (slightly longer paths for lower  
>> control cost) may be perfectly fair, assuming that very low  
>> amounts of user data traffic transit through the network. However,  
>> I do not see this assumption mentioned as a justification for  
>> focusing on the control cost metric and discarding the "path  
>> length" or the "total cost of getting user data through the network".
>>
> It is not easy to answer each of your point without running the  
> risk to start a debate that will never end. You raised some  
> excellent points that I agree with and others that I firmly  
> disagree with ... So let me try to make a few observations:
> 2) The aim of the protocol survey IS NOT to exclude MANET  
> protocols. As mentioned many times on the list, we *only* wanted to  
> show that existing protocols, with no change, could not be used in  
> LLNs. This has been clarified in the document as your request and  
> it HAD to be clarified.
> overlap at all. Please refer to their charter and WG items. The  
> only place that required clarification was the routing requirements  
> and I was personally opposed to it but this was adopted as a  
> 6lowpan WG item by consensus. We're are working together and  
> managed to sort this out. This document will be 6lowpan specific.
>
> ROLL, MANET, 6lowpan and quite frankly we could add other WGs to  
> the list.
>
> We just need to agree on the fact that there is no existing  
> protocol that meets the ROLL requirements and move to the next step  
> (re-chartering) to select one (hopefully not two) routing protocols  
> in light of the routing requirement (NOT the protocol survey),  
> which can either be an adapted MANET protocol or a new protocol.
>
> If you find a way to word this, please feel free and I'd be happy  
> to help but feel it as necessary ... Any opinion from our RTG and  
> INT ADs ?
>
>> 			-	Add the assumption that "user data traffic is so low that  
>> path lengths do not
> The motivation for selecting a longer path is not tied to the  
> amount of traffic here but the level of constraints. Note that this  
> is also true for several other technologies such as MPLS-TE. You  
> may have large amount of traffic and still require to follow a non- 
> shortest path (constrained based routing). This is detailed in  
> several requirements IDs. Criticality of data is of course  
> different, thus the requirements for potentially different data  
> paths according to packet marking using DSCP.
>
> existing requirements, isn't it sufficient to answer the question  
> on whether one can find an existing protocol?
>
>> This would make a large chunk of my concerns and issues vanish,  
>> and allow correctly interpreting and evaluating the rest of the  
>> document.
>
> That said, question for the WG. Who think that such criteria should  
> be added to move forward ? Please reply.
>
>>
>>
>>> 	Title		: Overview of Existing Routing Protocols for Low Power  
>>> and Lossy Networks

---

From: JP Vasseur <[email-masked]>
Date: Tue, 3 Feb 2009 14:40:22 +0100

Hi Thomas,

On Feb 3, 2009, at 2:19 PM, Thomas Heide Clausen wrote:

> eye, in exactly the same space.

We sort of operating in the same space, which is fine as long as we do  
*not* duplicate the work, do *not* overlap, do *not* reinvent the  
wheel. I think that we are on the same page.

>  My position is that it would be very unfortunate having one WG  
> creating confusion on the applicability of the work of itself and of  
> other IETF wg's, by simple omission of suitable perimeter definitions.
>

Quite frankly I do not see any confusion.
* 6lowpan has a clear charter - no overlap with ROLL and we work well  
together
* MANET works on several well defined protocols
* ROLL has also a clear charter with a narrow scope: routing for LLN  
for which we have defined detailed requirements. Our next step is to  
have a routing protocol for LLN according to the requirements, which  
may or may not be a MANET protocol. I do not see any confusion.

> In that sort of situation, the IETF needs to be extra prudent to  
> make sure to clearly spell out suitable perimeter definitions prior  
> to, or conjointly with, the first publication cycle. In this case,  
> before or with the survey I-D.
>

Are we back in sync ?

Thanks.

JP.

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 3 Feb 2009 15:11:27 +0100

Dear all,
I have remained silent since others have been echoing the concerns I had
pointed out earlier, about the survey document. I want nevertheless to
reinforce Thomas' point of view now, since I think it is insightful and
useful in order to move on constructively.

Basically, everybody agrees that something special must be done for sensor
ad hoc connectivity with IP, and everybody wants to reach the next phase
ASAP (i.e. work on solutions).

However, the lack of consensus on the precise space addressed by ROLL is
backlashing lately, with the survey document. The blur indeed had a huge
impact on the document so far, forcing the use of a too broad set of goals
and evaluation criterias, and endless discussions about the scope of the
survey.

This lack of definition will continue to plague ROLL and the other WGs in
the same field down the line if it is not addressed upfront, i.e. now. I
thus also encourage everyone to participate in this urgent and needed
effort.

If the scope of the WG is clearly defined, it should be straightforward to
write a couple of paragraphs that will get us out of this mess. So let's
just do it!

Cheers
Emmanuel

On Tue, Feb 3, 2009 at 2:19 PM, Thomas Heide Clausen <[email-masked]

> For the record, I am not arguing that MANET protocols should be applied or
> be applicable -- as you seem to suggest in your email. I believe that I have
> stated so repeatedly.
>
> I submit, however, that as it is currently exposed, ROLL, MANET and 6LOW
> seem to be operating within the same space -- to the untrained eye, in
> exactly the same space. My position is that it would be very unfortunate
> having one WG creating confusion on the applicability of the work of itself
> and of other IETF wg's, by simple omission of suitable perimeter
> definitions.
>
> In that sort of situation, the IETF needs to be extra prudent to make sure
> to clearly spell out suitable perimeter definitions prior to, or conjointly
> with, the first publication cycle. In this case, before or with the survey
> I-D.
>
> Sincerely,
>
> Thomas
>
>
> Two issues are raised here for which we would appreciate ADs' point of view
> and feed-back from the WG. Please see in line.
>
>
> Dear Thomas,
> -> As you know, many of the ROLL WG active participants have been working
> quite hard to produce a detailed set of requirements, discuss how to proceed
> on the protocol survey document, and other ID are in the works.
> have designed and deployed solutions so they not only have an excellent
> expertise of the requirements but also on solutions,
> *-> Yes we need to rush out. Why ? Because proprietary or semi-closed
> non-IP solutions are being deployed at a fairly large scale. I do not think
> that I have to convince anybody on this list that this is the WRONG approach
> for a number of reasons. The industry is asking for an IP solution *now*.*
> -> No we do not want to re-invent the wheel (see our presentation at the
> routing plenary in Chicago). Anything that already exists MUST (rfc2119 ;-))
> be used provided that it meets our requirements. And if we can adapt an
> existing protocol, we are all for it !
> -> Yes these requirements are quite specifics and this is precisely why
> ROLL has been formed, 4 application-specific routing requirements have been
> produced (to reduce the scope). Even if at a first sight, it looks very much
> similar to a MANET issue (and there ARE similarities but also very different
> requirements), having to deal with a highly static network of hundreds of
> thousands of battery operated sleeping nodes with 4K of RAM is quite
> specific. Note that this is not a random example, but an on-going non-IP
> deployed network.
>
> And to conclude on this introduction ... after an outstanding progress on
> the WG during the first 6-8 months, we have been slowed down dramatically
> for the last 2 months, thus it is time to close and move on to quickly
> re-charter and start the protocol work (hopefully as light as possible) to
> see IP-based solution deployed. I know that we are on the same page, we just
> need to find a good compromise on both "sides".
>
> I promised a review, and I apologize that I wasn't able to do so before the
> weekend as originally projected.
>
> Other than some typos that Chris and others have pointed out, I'll try to
> offer my understanding of the problem space and suggest some ways of
> positions itself with respect to MANET, 6LOW et. al, all of which appear to
> be within the same space and within the IETF. This I-D sees ROLL as
> presented with entirely new problems (the use of "novel" in the abstract,
> the statement that "existing protocols were not designed with these
> requirements in mind" seem to confirm this).
>
> low footprint", these appear similar to those which are also brought forward
> in e.g. MANET and 6LOW. Reading (quickly, I confess) the various
> requirements documents  of the draft-ietf-roll series present scenarios
> which are similar to those where MANETs are deployed, and are thought
> deployed, as well.
>
> Arguing that, as does this I-D, despite the above impression "ROLL is novel
> and different" invites asking "how, exactly?" I think that this question is
> valid, and merits being answered, before the evaluations in this I-D can be
> judged fairly.
>
> Note that I come from a MANET background, and so I *could* interpret from
> the ROLL discussion that where MANETs may aim for "low power, low bandwidth,
> ....", ROLL may be able to quantify these as "below this firm threshold" --
> i.e. as a sort of "extreme" or "constrained" MANET.
>
> This is a personal observation, I note, which would allow me to comprehend
> how ROLL and MANET are positioned relative to one another -- but one which
> neither this I-D nor the requirements document spell out or quantify -- or,
> for that matter, debunk.
>
> I think it's critical to understand this, in order to understand the need
> for a new protocol development. I think it is important to document this
> understanding in something with more persistency.
>
> If what I suggest above makes sense as a way of positioning ROLL and MANET
> relative to one another, I'd suggest including something to this effect in
> the survey I-D, as this I-D is the one making a *direct* reference to the
> applicability of MANET protocols to ROLL.
>
> If what I suggest doesn't make sense at all, then I'd be happy to have it
> debunked and, hopefully, through that debunking a positioning/description
> that does ring true with us all can be produced?
>
> is unfortunate (not the word, Phill has me convinced on that front, but the
> actual criteria). Control cost is, by all means, a rather meaningless
> criteria when taken in isolation. I've sketched a "zero-control-cost"
> routing protocol (flood all data - say use SMF, also a MANET protocol, and
> also a rather "mature" I-D and wg item) which would score well on the
> control cost criteria, but would likely be an extremely bad choice for
> delivering unicast data.
>
> The metric which matters, and which should matter to ROLL in particular, is
> "the total cost of getting user data through the network, including control
> cost necessary to set up paths" -- as we know, every packet sent and
> received costs bandwidth, energy and cycles -- user data no different from
> contro.
>
> I note that this trade-off (slightly longer paths for lower control cost)
> may be perfectly fair, assuming that very low amounts of user data traffic
> transit through the network. However, I do not see this assumption mentioned
> as a justification for focusing on the control cost metric and discarding
> the "path length" or the "total cost of getting user data through the
> network".
>
> so little user data traffic in a ROLL network that we do not care about
> shortest paths") or -- if these assumptions do not hold, that the evaluation
> criteria are incomplete.
>
> I note that it's true that we can always add another criteria ad infinitum,
> and that's CLEARLY not what we want to do. However when I say "incomplete"
> in the above, I simply suggest that based on what is presented one cannot
> draw conclusions based on the evaluation criteria....or, worse, that one
> draws the wrong conclusions based on the information presented.
>
>
> It is not easy to answer each of your point without running the risk to
> start a debate that will never end. You raised some excellent points that I
> agree with and others that I firmly disagree with ... So let me try to make
> a few observations:
> 1) As pointed out earlier, yes there are similarities between MANET and
> ROLL. I do not see this as an issue.
> 2) The aim of the protocol survey IS NOT to exclude MANET protocols. As
> mentioned many times on the list, we *only* wanted to show that existing
> protocols, with no change, could not be used in LLNs. This has been
> clarified in the document as your request and it HAD to be clarified.
> - Try to derive a subset of necessary but not sufficient criteria, which
> the WG chose to do (consensus). Yes this list is not perfect,
> criteria could be changed, removed or added but looked good enough with
> excellent consensus until LC.
> 4) With regards to 6lowpan (I copy the chair), I do not see any overlap at
> all. Please refer to their charter and WG items. The only place that
> required clarification was the routing requirements and I was personally
> opposed to it but this was adopted as a 6lowpan WG item *by consensus*.
> We're are working together and managed to sort this out. This document will
> be 6lowpan specific.
>
> What I want to avoid is an endless discussion on the positioning of ROLL,
> MANET, 6lowpan and quite frankly we could add other WGs to the list.
>
> *So what is the bottom line ?*
>
> We just need to agree on the fact that there is no existing protocol that
> meets the ROLL requirements and move to the next step (re-chartering) to
> select one (hopefully not two) routing protocols in light of the routing
> requirement (NOT the protocol survey), which can either be an adapted MANET
> protocol or a new protocol.
>
> So, in a nutshell, I suggest that we address (i) the positioning issue and
> (ii) the criteria issue thus:
>
> o Describe as I proposed above if ROLL and MANETs position themselves as I
>  have deducted. If my deduction is incorrect, then let's quickly iterate
> on the list
>  as to understand how to do produce an alternative description. If we
> can't do this,
>  It *should* not be more than a couple of paragraphs worth of text to add,
> I gather?
>
>
> If you find a way to word this, please feel free and I'd be happy to help
> but feel it as necessary ... Any opinion from our RTG and INT ADs ?
>
>  - Add the assumption that "user data traffic is so low that path lengths
> do not
> The motivation for selecting a longer path is not tied to the amount of
> traffic here but the level of constraints. Note that this is also true for
> several other technologies such as MPLS-TE. You may have large amount of
> traffic and still require to follow a non-shortest path (constrained based
> routing). This is detailed in several requirements IDs. Criticality of data
> is of course different, thus the requirements for potentially different data
> existing requirements, isn't it sufficient to answer the question on whether
> one can find an existing protocol?
>
> This would make a large chunk of my concerns and issues vanish, and allow
> correctly interpreting and evaluating the rest of the document.
>
>
> 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
>
On Tue, Feb 3, 2009 at 2:19 PM, Thomas Heide Clausen <[email-masked]

> For the record, I am not arguing that MANET protocols should be applied or
> be applicable -- as you seem to suggest in your email. I believe that I have
> stated so repeatedly.
>
> I submit, however, that as it is currently exposed, ROLL, MANET and 6LOW
> seem to be operating within the same space -- to the untrained eye, in
> exactly the same space. My position is that it would be very unfortunate
> having one WG creating confusion on the applicability of the work of itself
> and of other IETF wg's, by simple omission of suitable perimeter
> definitions.
>
> In that sort of situation, the IETF needs to be extra prudent to make sure
> to clearly spell out suitable perimeter definitions prior to, or conjointly
> with, the first publication cycle. In this case, before or with the survey
> I-D.
>
> Sincerely,
>
> Thomas
>
>
> Two issues are raised here for which we would appreciate ADs' point of view
> and feed-back from the WG. Please see in line.
>
>
> Dear Thomas,
> -> As you know, many of the ROLL WG active participants have been working
> quite hard to produce a detailed set of requirements, discuss how to proceed
> on the protocol survey document, and other ID are in the works.
> have designed and deployed solutions so they not only have an excellent
> expertise of the requirements but also on solutions,
> *-> Yes we need to rush out. Why ? Because proprietary or semi-closed
> non-IP solutions are being deployed at a fairly large scale. I do not think
> that I have to convince anybody on this list that this is the WRONG approach
> for a number of reasons. The industry is asking for an IP solution *now*.*
> -> No we do not want to re-invent the wheel (see our presentation at the
> routing plenary in Chicago). Anything that already exists MUST (rfc2119 ;-))
> be used provided that it meets our requirements. And if we can adapt an
> existing protocol, we are all for it !
> -> Yes these requirements are quite specifics and this is precisely why
> ROLL has been formed, 4 application-specific routing requirements have been
> produced (to reduce the scope). Even if at a first sight, it looks very much
> similar to a MANET issue (and there ARE similarities but also very different
> requirements), having to deal with a highly static network of hundreds of
> thousands of battery operated sleeping nodes with 4K of RAM is quite
> specific. Note that this is not a random example, but an on-going non-IP
> deployed network.
>
> And to conclude on this introduction ... after an outstanding progress on
> the WG during the first 6-8 months, we have been slowed down dramatically
> for the last 2 months, thus it is time to close and move on to quickly
> re-charter and start the protocol work (hopefully as light as possible) to
> see IP-based solution deployed. I know that we are on the same page, we just
> need to find a good compromise on both "sides".
>
> I promised a review, and I apologize that I wasn't able to do so before the
> weekend as originally projected.
>
> Other than some typos that Chris and others have pointed out, I'll try to
> offer my understanding of the problem space and suggest some ways of
> positions itself with respect to MANET, 6LOW et. al, all of which appear to
> be within the same space and within the IETF. This I-D sees ROLL as
> presented with entirely new problems (the use of "novel" in the abstract,
> the statement that "existing protocols were not designed with these
> requirements in mind" seem to confirm this).
>
> low footprint", these appear similar to those which are also brought forward
> in e.g. MANET and 6LOW. Reading (quickly, I confess) the various
> requirements documents  of the draft-ietf-roll series present scenarios
> which are similar to those where MANETs are deployed, and are thought
> deployed, as well.
>
> Arguing that, as does this I-D, despite the above impression "ROLL is novel
> and different" invites asking "how, exactly?" I think that this question is
> valid, and merits being answered, before the evaluations in this I-D can be
> judged fairly.
>
> Note that I come from a MANET background, and so I *could* interpret from
> the ROLL discussion that where MANETs may aim for "low power, low bandwidth,
> ....", ROLL may be able to quantify these as "below this firm threshold" --
> i.e. as a sort of "extreme" or "constrained" MANET.
>
> This is a personal observation, I note, which would allow me to comprehend
> how ROLL and MANET are positioned relative to one another -- but one which
> neither this I-D nor the requirements document spell out or quantify -- or,
> for that matter, debunk.
>
> I think it's critical to understand this, in order to understand the need
> for a new protocol development. I think it is important to document this
> understanding in something with more persistency.
>
> If what I suggest above makes sense as a way of positioning ROLL and MANET
> relative to one another, I'd suggest including something to this effect in
> the survey I-D, as this I-D is the one making a *direct* reference to the
> applicability of MANET protocols to ROLL.
>
> If what I suggest doesn't make sense at all, then I'd be happy to have it
> debunked and, hopefully, through that debunking a positioning/description
> that does ring true with us all can be produced?
>
> is unfortunate (not the word, Phill has me convinced on that front, but the
> actual criteria). Control cost is, by all means, a rather meaningless
> criteria when taken in isolation. I've sketched a "zero-control-cost"
> routing protocol (flood all data - say use SMF, also a MANET protocol, and
> also a rather "mature" I-D and wg item) which would score well on the
> control cost criteria, but would likely be an extremely bad choice for
> delivering unicast data.
>
> The metric which matters, and which should matter to ROLL in particular, is
> "the total cost of getting user data through the network, including control
> cost necessary to set up paths" -- as we know, every packet sent and
> received costs bandwidth, energy and cycles -- user data no different from
> contro.
>
> I note that this trade-off (slightly longer paths for lower control cost)
> may be perfectly fair, assuming that very low amounts of user data traffic
> transit through the network. However, I do not see this assumption mentioned
> as a justification for focusing on the control cost metric and discarding
> the "path length" or the "total cost of getting user data through the
> network".
>
> so little user data traffic in a ROLL network that we do not care about
> shortest paths") or -- if these assumptions do not hold, that the evaluation
> criteria are incomplete.
>
> I note that it's true that we can always add another criteria ad infinitum,
> and that's CLEARLY not what we want to do. However when I say "incomplete"
> in the above, I simply suggest that based on what is presented one cannot
> draw conclusions based on the evaluation criteria....or, worse, that one
> draws the wrong conclusions based on the information presented.
>
>
> It is not easy to answer each of your point without running the risk to
> start a debate that will never end. You raised some excellent points that I
> agree with and others that I firmly disagree with ... So let me try to make
> a few observations:
> 1) As pointed out earlier, yes there are similarities between MANET and
> ROLL. I do not see this as an issue.
> 2) The aim of the protocol survey IS NOT to exclude MANET protocols. As
> mentioned many times on the list, we *only* wanted to show that existing
> protocols, with no change, could not be used in LLNs. This has been
> clarified in the document as your request and it HAD to be clarified.
> - Try to derive a subset of necessary but not sufficient criteria, which
> the WG chose to do (consensus). Yes this list is not perfect,
> criteria could be changed, removed or added but looked good enough with
> excellent consensus until LC.
> 4) With regards to 6lowpan (I copy the chair), I do not see any overlap at
> all. Please refer to their charter and WG items. The only place that
> required clarification was the routing requirements and I was personally
> opposed to it but this was adopted as a 6lowpan WG item *by consensus*.
> We're are working together and managed to sort this out. This document will
> be 6lowpan specific.
>
> What I want to avoid is an endless discussion on the positioning of ROLL,
> MANET, 6lowpan and quite frankly we could add other WGs to the list.
>
> *So what is the bottom line ?*
>
> We just need to agree on the fact that there is no existing protocol that
> meets the ROLL requirements and move to the next step (re-chartering) to
> select one (hopefully not two) routing protocols in light of the routing
> requirement (NOT the protocol survey), which can either be an adapted MANET
> protocol or a new protocol.
>
> So, in a nutshell, I suggest that we address (i) the positioning issue and
> (ii) the criteria issue thus:
>
> o Describe as I proposed above if ROLL and MANETs position themselves as I
>  have deducted. If my deduction is incorrect, then let's quickly iterate
> on the list
>  as to understand how to do produce an alternative description. If we
> can't do this,
>  It *should* not be more than a couple of paragraphs worth of text to add,
> I gather?
>
>
> If you find a way to word this, please feel free and I'd be happy to help
> but feel it as necessary ... Any opinion from our RTG and INT ADs ?
>
>  - Add the assumption that "user data traffic is so low that path lengths
> do not
> The motivation for selecting a longer path is not tied to the amount of
> traffic here but the level of constraints. Note that this is also true for
> several other technologies such as MPLS-TE. You may have large amount of
> traffic and still require to follow a non-shortest path (constrained based
> routing). This is detailed in several requirements IDs. Criticality of data
> is of course different, thus the requirements for potentially different data
> existing requirements, isn't it sufficient to answer the question on whether
> one can find an existing protocol?
>
> This would make a large chunk of my concerns and issues vanish, and allow
> correctly interpreting and evaluating the rest of the document.
>
>
> 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
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 15:40:04 +0100

JP Vasseur a écrit :
>> Mischa Dohler a écrit : [...]
>>  Neighbor Discovery for 802.15.4, which is quite relevant here I 
>> believe, because ZigBee was mentioned recently here.
> 

I think it is good to mention all link-layers which are addressed by
ROLL.  The link layer characteristics are of paramount importance on the
subnetting and addressing architecture, and thus on the kind of protocol
needed.

(I agree though at IETF we work on IP, independently of the link-layer,
and some times dependently on the link-layer: IP-over-foo are typical.)

>> IEEE 802.15.4 SP100 http://tinyurl.com/4d3j64 ZigBee HART 
>> http://tinyurl.com/4d3j64
>> 
> 
> 15.4. We are designing IP-solution and indeed 15.4 is one of the 
> PHY/MAC LLN may run onto.

I think in the cases a wireless network is made of ZigBee nodes, or
802.15.4 nodes, the entire network is actually a single subnet.  And in
these cases Neighbor Discovery protocol is very pertinent for ROLL.

This would contradict all the inconvenients cited in section 8.1. "IPv6
ND" of protocols-survey draft.  HEnce I disagree with this section.  I
disagree with it for more reasons, one being:

protocols-survey draft:
> The fact that all routers must respond to a Router Solicitation 
> requires that the number of routers with a 1-hop neighborhood is 
> small, or there will be a reply implosion.

Such reply implosion is avoided by the IPv6 ND spec, because it requires
the RAs responding to an RS are spaced randomly in time:

RFC4861 "ND for IPv6":
> 6.2.6.  Processing Router Solicitations
[...]
> In all cases, Router Advertisements sent in response to a Router 
> Solicitation MUST be delayed by a random time between 0 and 
> MAX_RA_DELAY_TIME seconds.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 15:51:59 +0100

JP Vasseur a écrit :
[...]
>  have been produced (to reduce the scope).

Good complete requirements lists == good engineering approach, I agree.

Side note, in MEXT WG there are also 3 sets of requirements, for three
different spaces (automotive, aeronautics and consumer electronics).  We
have not yet embarked on designing that Mobile IP or ND extension for
dealing with Route Optimization for NEMO-based moving networks.

Alex

  Even if at a first sight, it looks
> very much similar to a MANET issue (and there ARE similarities but 
> also very different requirements), having to deal with a highly 
> nodes with 4K of RAM is quite specific. Note that this is not a 
> random example, but an on-going non-IP deployed network.
> 
> down dramatically for the last 2 months, thus it is time to close and
>  move on to quickly re-charter and start the protocol work (hopefully
>  as light as possible) to see IP-based solution deployed. I know that
>  we are on the same page, we just need to find a good compromise on 
> both "sides".
> 
>> have it debunked and, hopefully, through that debunking a
positioning/description that does ring true with us all can be
>> produced?
>> The metric which matters, and which should matter to ROLL in
particular, is "the total cost of getting user data through the network,
including control cost necessary to set up paths" -- as we
>> According to the criterions as set up by this I-D, a protocol
producing "longer than shortest paths" at the benefit of slightly lower
control cost would score better than a protocol producing "shortest
paths" with slightly higher control cost. This is not hypothetical,
btw., there are plenty of studies observing and reflecting upon this
regarding the different MANET protocols, in academic literature -- and
observed in real networks as well.
> points that I agree with and others that I firmly disagree with ... 
> So let me try to make a few observations: 1) As pointed out earlier, 
> yes there are similarities between MANET and ROLL. I do not see this 
> as an issue. 2) The aim of the protocol survey IS NOT to exclude 
> MANET protocols. As mentioned many times on the list, we *only* 
> wanted to show that existing protocols, with no change, could not be 
> used in LLNs. This has been clarified in the document as your request
>  and it HAD to be clarified. 3) We could have used two different 
> approaches for the survey: - Look at all MUST from the requirements 
> documents - Try to derive a subset of necessary but not sufficient 
> criteria, which the WG chose to do (consensus). Yes this list is not 
> perfect, criteria could be changed, removed or added but looked good 
> enough with excellent consensus until LC. 4) With regards to 6lowpan 
> (I copy the chair), I do not see any overlap at all. Please refer to 
> their charter and WG items. The only place that required 
> clarification was the routing requirements and I was personally
opposed to it but this was adopted as a 6lowpan WG item *by
> consensus*. We're are working together and managed to sort this out. 
> list.
> 
> /So what is the bottom line ?/
> 
> that meets the ROLL requirements and move to the next step
> in light of the routing requirement (NOT the protocol survey), which 
> can either be an adapted MANET protocol or a new protocol.
> 
> requirements IDs. Criticality of data is of course different, thus 
> the requirements for potentially different data paths according to 
> packet marking using DSCP.
> 
>> On Jan 27, 2009, at 1:00 AM, [email-masked]
<mailto:[email-masked]> wrote:
>>> 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
>>> 
>>>  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 
>>> survey
it examines whether existing and mature IETF protocols can
>>> <[email-masked]
>>> <mailto:[email-masked]>>
>>> 
>>>  [email-masked] <mailto:[email-masked]>
>> _______________________________________________ Roll mailing list
[email-masked] <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll
> 
> 
> ------------------------------------------------------------------------
> 
> 
>

---

From: JP Vasseur <[email-masked]>
Date: Tue, 3 Feb 2009 15:55:18 +0100

> and some times dependently on the link-layer: IP-over-foo are  

I do not think that this is the appropriate ML to have such  
discussion. But no we are not here to list
all possible link layers (glad we did not do this 20 years ago !). New  
link layers will be designed in a
near future (especially true for LLN). And by the way Zigbee is not a  
PHY/MAC ...

>>> IEEE 802.15.4 SP100 http://tinyurl.com/4d3j64 ZigBee HART http://tinyurl.com/4d3j64

Sorry Alex but there is a lot of confusion. Zigbee nodes are NOT  
running IP.
Out of context here.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 16:02:09 +0100

JP, in previous messages you're suggesting my text about link-layers are 
out of context.

But I consider perfectly legitimate the following questions: which 
link-layers are considered for ROLL WG?  How do they present themselves 
to the IP stack?  Do they all use the typical Ethernet MAC interface? 
Or point-to-point links?

Do these link-layer offer hints for defining ROLL energy-oriented metrics?

Alex

JP Vasseur a écrit :
> I do not think that this is the appropriate ML to have such discussion. 
> But no we are not here to list
> Sorry Alex but there is a lot of confusion. Zigbee nodes are NOT running 
> IP.
> Out of context here.
> 
>>
>>

---

From: JP Vasseur <[email-masked]>
Date: Tue, 3 Feb 2009 16:20:32 +0100

Hi Alex,

See how easy to get off-track ... still enjoying the discussion but I  
would like to stay a bit focussed on closing the protocol survey ID.

On Feb 3, 2009, at 4:02 PM, Alexandru Petrescu wrote:

> JP, in previous messages you're suggesting my text about link-layers  
> are out of context.
>
> link-layers are considered for ROLL WG?  How do they present  
> themselves to the IP stack?  Do they all use the typical Ethernet  
> MAC interface? Or point-to-point links?
>

Look at what I wrote below ... no we do not want to become dependent  
of a specific layer of course and list all layers, otherwise why IP ?
That said, yes we do want to take into account some of their  
properties in routing, the abstraction being performed thanks to  
routing metrics.
I'm co-authoring this draft to be posted soon, comment welcome.

JP.

>>>> HOLD-ON ... We are NOT working on ZIGBEE here. Let's not go  
>>>> there. This is the IETF, we work on IP.
>>>
>> all possible link layers (glad we did not do this 20 years ago !).  
>> New link layers will be designed in a
>> near future (especially true for LLN). And by the way Zigbee is not  
>> a PHY/MAC ...
>>>
>>>
>>>> There is quite a bit of confusion. Zigbee is non-IP and build  
>>>> above 15.4. We are designing IP-solution and indeed 15.4 is one  
>>>> of the PHY/MAC LLN may run onto.
>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 15:42:22 +0100

Emmanuel, +1 here.

Alex

Emmanuel Baccelli a écrit :
> Basically, everybody agrees that something special must be done for 
> sensor ad hoc connectivity with IP, and everybody wants to reach the 
> next phase ASAP (i.e. work on solutions). 
> 
> impact on the document so far, forcing the use of a too broad set of 
> goals and evaluation criterias, and endless discussions about the scope 
> of the survey.
> 
> This lack of definition will continue to plague ROLL and the other WGs 
> in the same field down the line if it is not addressed upfront, i.e. 
> now. I thus also encourage everyone to participate in this urgent and 
> needed effort.
> 
> If the scope of the WG is clearly defined, it should be straightforward 
> to write a couple of paragraphs that will get us out of this mess. So 
> let's just do it!
> 
> Cheers
> Emmanuel
> 
> 
> 
> 
> On Tue, Feb 3, 2009 at 2:19 PM, Thomas Heide 
> Clausen <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>     Two issues are raised here for which we would appreciate ADs'
>>     point of view and feed-back from the WG. Please see in line.
>>
>>
>>     Dear Thomas,
>>
>>     *-> Yes we need to rush out. Why ? Because proprietary or
>>     semi-closed non-IP solutions are being deployed at a fairly large
>>     scale. I do not think that I have to convince anybody on this list
>>     that this is the WRONG approach for a number of reasons. The
>>     industry is asking for an IP solution *now*.*
>>     MUST (rfc2119 ;-)) be used provided that it meets our
>>     requirements. And if we can adapt an existing protocol, we are all
>>     for it !
>>     -> Yes these requirements are quite specifics and this is
>>     precisely why ROLL has been formed, 4 application-specific routing
>>     requirements have been produced (to reduce the scope). Even if at
>>     a first sight, it looks very much similar to a MANET issue (and
>>     there ARE similarities but also very different requirements),
>>     having to deal with a highly static network of hundreds of
>>     thousands of battery operated sleeping nodes with 4K of RAM is
>>     quite specific. Note that this is not a random example, but an
>>     on-going non-IP deployed network.
>>
>>     progress on the WG during the first 6-8 months, we have been
>>     slowed down dramatically for the last 2 months, thus it is time to
>>     close and move on to quickly re-charter and start the protocol
>>     work (hopefully as light as possible) to see IP-based solution
>>     deployed. I know that we are on the same page, we just need to
>>     find a good compromise on both "sides".
>>
>>>     Other than some typos that Chris and others have pointed out,
>>>     I'll try to offer my understanding of the problem space and
>>>     suggest some ways of addressing my main concerns....
>>>
>>>     My first main concern remain that it is not clear, still, how
>>>     ROLL positions itself with respect to MANET, 6LOW et. al, all of
>>>     which appear to be within the same space and within the IETF.
>>>     This I-D sees ROLL as presented with entirely new problems (the
>>>     use of "novel" in the abstract, the statement that "existing
>>>     protocols were not designed with these requirements in mind" seem
>>>     to confirm this).
>>>
>>>     bandwidth, low footprint", these appear similar to those which
>>>     are also brought forward in e.g. MANET and 6LOW. Reading
>>>     (quickly, I confess) the various requirements documents  of the
>>>     draft-ietf-roll series present scenarios which are similar to
>>>     those where MANETs are deployed, and are thought deployed, as well.
>>>
>>>     Arguing that, as does this I-D, despite the above impression
>>>     "ROLL is novel and different" invites asking "how, exactly?" I
>>>     think that this question is valid, and merits being answered,
>>>     before the evaluations in this I-D can be judged fairly.
>>>
>>>     and MANET relative to one another, I'd suggest including
>>>     something to this effect in the survey I-D, as this I-D is the
>>>     one making a *direct* reference to the applicability of MANET
>>>     protocols to ROLL.
>>>
>>>     means, a rather meaningless criteria when taken in isolation.
>>>     I've sketched a "zero-control-cost" routing protocol (flood all
>>>     data - say use SMF, also a MANET protocol, and also a rather
>>>     "mature" I-D and wg item) which would score well on the control
>>>     cost criteria, but would likely be an extremely bad choice for
>>>     delivering unicast data.
>>>
>>>     amounts of user data traffic transit through the network.
>>>     However, I do not see this assumption mentioned as a
>>>     justification for focusing on the control cost metric and
>>>     discarding the "path length" or the "total cost of getting user
>>>     data through the network".
>>>
>>>     ("there's so little user data traffic in a ROLL network that we
>>>     do not care about shortest paths") or -- if these assumptions do
>>>     not hold, that the evaluation criteria are incomplete.
>>>
>>>     infinitum, and that's CLEARLY not what we want to do. However
>>>     when I say "incomplete" in the above, I simply suggest that based
>>>     on what is presented one cannot draw conclusions based on the
>>     1) As pointed out earlier, yes there are similarities between
>>     MANET and ROLL. I do not see this as an issue.
>>     protocols. As mentioned many times on the list, we *only* wanted
>>     to show that existing protocols, with no change, could not be used
>>     in LLNs. This has been clarified in the document as your request
>>     and it HAD to be clarified.
>>     only place that required clarification was the routing
>>     requirements and I was personally opposed to it but this was
>>     adopted as a 6lowpan WG item *by consensus*. We're are working
>>     together and managed to sort this out. This document will be
>>     6lowpan specific.
>>
>>     What I want to avoid is an endless discussion on the positioning
>>     of ROLL, MANET, 6lowpan and quite frankly we could add other WGs
>>     to the list.
>>
>>     protocol that meets the ROLL requirements and move to the next
>>     step (re-chartering) to select one (hopefully not two) routing
>>     protocols in light of the routing requirement (NOT the protocol
>>     survey), which can either be an adapted MANET protocol or a new
>>     protocol.
>>
>>     amount of traffic here but the level of constraints. Note that
>>     this is also true for several other technologies such as MPLS-TE.
>>     You may have large amount of traffic and still require to follow a
>>     non-shortest path (constrained based routing). This is detailed in
>>     And we can add many more but if the current protocol do not
>>     satisfy existing requirements, isn't it sufficient to answer the
>>     question on whether one can find an existing protocol?
>>
>>     That said, question for the WG. Who think that such criteria
>>     should be added to move forward ? Please reply.
>>
>>>
>>>
>>>>     This draft is a work item of the Routing Over Low power and
>>>>     Lossy networks Working Group of the IETF.
>>>>
>>>>     Content-ID: <[email-masked]
> On Tue, Feb 3, 2009 at 2:19 PM, Thomas Heide Clausen 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>     Two issues are raised here for which we would appreciate ADs'
>>     point of view and feed-back from the WG. Please see in line.
>>
>>
>>     Dear Thomas,
>>
>>     *-> Yes we need to rush out. Why ? Because proprietary or
>>     semi-closed non-IP solutions are being deployed at a fairly large
>>     scale. I do not think that I have to convince anybody on this list
>>     that this is the WRONG approach for a number of reasons. The
>>     industry is asking for an IP solution *now*.*
>>     MUST (rfc2119 ;-)) be used provided that it meets our
>>     requirements. And if we can adapt an existing protocol, we are all
>>     for it !
>>     -> Yes these requirements are quite specifics and this is
>>     precisely why ROLL has been formed, 4 application-specific routing
>>     requirements have been produced (to reduce the scope). Even if at
>>     a first sight, it looks very much similar to a MANET issue (and
>>     there ARE similarities but also very different requirements),
>>     having to deal with a highly static network of hundreds of
>>     thousands of battery operated sleeping nodes with 4K of RAM is
>>     quite specific. Note that this is not a random example, but an
>>     on-going non-IP deployed network.
>>
>>     progress on the WG during the first 6-8 months, we have been
>>     slowed down dramatically for the last 2 months, thus it is time to
>>     close and move on to quickly re-charter and start the protocol
>>     work (hopefully as light as possible) to see IP-based solution
>>     deployed. I know that we are on the same page, we just need to
>>     find a good compromise on both "sides".
>>
>>>     Other than some typos that Chris and others have pointed out,
>>>     I'll try to offer my understanding of the problem space and
>>>     suggest some ways of addressing my main concerns....
>>>
>>>     My first main concern remain that it is not clear, still, how
>>>     ROLL positions itself with respect to MANET, 6LOW et. al, all of
>>>     which appear to be within the same space and within the IETF.
>>>     This I-D sees ROLL as presented with entirely new problems (the
>>>     use of "novel" in the abstract, the statement that "existing
>>>     protocols were not designed with these requirements in mind" seem
>>>     to confirm this).
>>>
>>>     bandwidth, low footprint", these appear similar to those which
>>>     are also brought forward in e.g. MANET and 6LOW. Reading
>>>     (quickly, I confess) the various requirements documents  of the
>>>     draft-ietf-roll series present scenarios which are similar to
>>>     those where MANETs are deployed, and are thought deployed, as well.
>>>
>>>     Arguing that, as does this I-D, despite the above impression
>>>     "ROLL is novel and different" invites asking "how, exactly?" I
>>>     think that this question is valid, and merits being answered,
>>>     before the evaluations in this I-D can be judged fairly.
>>>
>>>     and MANET relative to one another, I'd suggest including
>>>     something to this effect in the survey I-D, as this I-D is the
>>>     one making a *direct* reference to the applicability of MANET
>>>     protocols to ROLL.
>>>
>>>     means, a rather meaningless criteria when taken in isolation.
>>>     I've sketched a "zero-control-cost" routing protocol (flood all
>>>     data - say use SMF, also a MANET protocol, and also a rather
>>>     "mature" I-D and wg item) which would score well on the control
>>>     cost criteria, but would likely be an extremely bad choice for
>>>     delivering unicast data.
>>>
>>>     amounts of user data traffic transit through the network.
>>>     However, I do not see this assumption mentioned as a
>>>     justification for focusing on the control cost metric and
>>>     discarding the "path length" or the "total cost of getting user
>>>     data through the network".
>>>
>>>     ("there's so little user data traffic in a ROLL network that we
>>>     do not care about shortest paths") or -- if these assumptions do
>>>     not hold, that the evaluation criteria are incomplete.
>>>
>>>     infinitum, and that's CLEARLY not what we want to do. However
>>>     when I say "incomplete" in the above, I simply suggest that based
>>>     on what is presented one cannot draw conclusions based on the
>>     1) As pointed out earlier, yes there are similarities between
>>     MANET and ROLL. I do not see this as an issue.
>>     protocols. As mentioned many times on the list, we *only* wanted
>>     to show that existing protocols, with no change, could not be used
>>     in LLNs. This has been clarified in the document as your request
>>     and it HAD to be clarified.
>>     only place that required clarification was the routing
>>     requirements and I was personally opposed to it but this was
>>     adopted as a 6lowpan WG item *by consensus*. We're are working
>>     together and managed to sort this out. This document will be
>>     6lowpan specific.
>>
>>     What I want to avoid is an endless discussion on the positioning
>>     of ROLL, MANET, 6lowpan and quite frankly we could add other WGs
>>     to the list.
>>
>>     protocol that meets the ROLL requirements and move to the next
>>     step (re-chartering) to select one (hopefully not two) routing
>>     protocols in light of the routing requirement (NOT the protocol
>>     survey), which can either be an adapted MANET protocol or a new
>>     protocol.
>>
>>     amount of traffic here but the level of constraints. Note that
>>     this is also true for several other technologies such as MPLS-TE.
>>     You may have large amount of traffic and still require to follow a
>>     non-shortest path (constrained based routing). This is detailed in
>>     And we can add many more but if the current protocol do not
>>     satisfy existing requirements, isn't it sufficient to answer the
>>     question on whether one can find an existing protocol?
>>
>>     That said, question for the WG. Who think that such criteria
>>     should be added to move forward ? Please reply.
>>
>>>
>>>
>>>>     This draft is a work item of the Routing Over Low power and
>>>>     Lossy networks Working Group of the IETF.
>>>>
>>>>     Content-ID: <[email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 15:20:53 +0100

JP Vasseur a écrit :
>>> As for your proposition, I have another one: Why don't we stop 
>>> here and get on with the actual protocol design stage,
>> 
> We have detailed routing requirements documents. Should we 
> re-charter, the process gets quite simple. Look at different 
> candidates and how close they are to the requirements. Then select 
> one or two (in which case we need clear applicability statement). And
>  yes if we can use an adapted existing protocol, then great.

I agree in principle.

But what's then the implication of of the protocols-survey draft on the 
next-stage developments?

The protocols-survey draft clearly puts NEMO protocol out of scope:
> This document does not examine the Network Mobility Basic Support 
> Protocol (NEMO RFC 3963 [RFC3963]) because it is not a routing 
> protocol.

If protocols-survey draft gets published as is, now, this means NEMO 
protocol is not going to be considered.  Regardless of the mentioning of 
the "mobility" aspects in the requirements.

Alex

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 03 Feb 2009 16:38:03 +0100

Hi,

I agree with Emmanuel and Alex. I think it is very important to define
the "role of ROLL" with respect to similar working groups such as
6lowpan and MANET. If this is delayed, it might backfire very soon when
going into the protocol design phase. As said in one of my former
emails, it is possible that the protocol survey ID is not the right
place, but somewhere -- either in another document or in the charter --
ROLL should place itself (before the protocol survey is published)

Cheers,
Ulrich

Alexandru Petrescu wrote:
>> I have remained silent since others have been echoing the concerns I
>> had pointed out earlier, about the survey document. I want
>> nevertheless to reinforce Thomas' point of view now, since I think it
>> is insightful and useful in order to move on constructively.
>>
>> However, the lack of consensus on the precise space addressed by ROLL
>> is backlashing lately, with the survey document. The blur indeed had
>> a huge impact on the document so far, forcing the use of a too broad
>> set of goals and evaluation criterias, and endless discussions about
>> the scope of the survey.
>>
>> This lack of definition will continue to plague ROLL and the other
>> WGs in the same field down the line if it is not addressed upfront,
>> i.e. now. I thus also encourage everyone to participate in this
>> urgent and needed effort.
>>
>> If the scope of the WG is clearly defined, it should be
>> straightforward to write a couple of paragraphs that will get us out
>> of this mess. So let's just do it!
>>
>> Cheers
>> Emmanuel
>>
>>
>>
>>
>>>>> Internet-Drafts
>>>>> Internet-Drafts

---

From: Arsalan Tavakoli <[email-masked]>
Date: Tue, 3 Feb 2009 07:42:16 -0800

>> This document does not examine the Network Mobility Basic Support Protocol
>> (NEMO RFC 3963 [RFC3963]) because it is not a routing protocol.
>>
>
> protocol is not going to be considered.  Regardless of the mentioning of the
> "mobility" aspects in the requirements.
>
> Alex

No, it doesn't mean that at all.  The protocol survey picked a set of
candidates to evaluate (which was agreed upon on the mailing list and at
IETF meetings), which only serve to answer the basic question: does any
protocol currently exist that satisfies all requirements.  When we move to
the next stage, specifications for protocols outside of those considered,
including NEMO, are certainly more than welcome.

- Arsalan

---

From: JP Vasseur <[email-masked]>
Date: Tue, 3 Feb 2009 16:48:28 +0100

On Feb 3, 2009, at 3:20 PM, Alexandru Petrescu wrote:

>> We have detailed routing requirements documents. Should we re- 
>> charter, the process gets quite simple. Look at different  
> But what's then the implication of of the protocols-survey draft on  
> the next-stage developments?
>
> protocol is not going to be considered.

Why ? if we get rechartered NEMO WILL be considered as part of the  
candidates among others pieces of the solution,

>  Regardless of the mentioning of the "mobility" aspects in the  
> requirements.
>
> Alex
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 16:51:20 +0100

Arsalan Tavakoli a écrit :
>         This document does not examine the Network Mobility Basic
>         Support Protocol (NEMO RFC 3963 [RFC3963]) because it is not a
>         routing protocol.
> 
> 
>     protocol is not going to be considered.  Regardless of the
>     mentioning of the "mobility" aspects in the requirements.
> 
>     Alex
> 
> 
> protocol currently exist that satisfies all requirements.  When we move 
> to the next stage, specifications for protocols outside of those 
> considered, including NEMO, are certainly more than welcome.

In this case the entire protocols-survey draft looks superfluous: its 
statements aren't of any use because in the next stage we ignore its advice.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 16:52:27 +0100

JP Vasseur a écrit :
>>> Protocol (NEMO RFC 3963 [RFC3963]) because it is not a routing protocol.
>>

Why don't we write precisely that in some draft text?  Why not in the 
protocols-survey draft?

Alex

---

From: Arsalan Tavakoli <[email-masked]>
Date: Tue, 3 Feb 2009 08:03:30 -0800

> statements aren't of any use because in the next stage we ignore its advice.

How are we ignoring it's advice?  While it might seem superfluous or a
formality to you, one of the real questions that we needed to answer before
moving on to protocol design (if necessary mind you), was what are the base
set of necessary but sufficient requirements for this design space, and do
any existing protocol specifications meet these requirements.  This protocol
survey allowed us to answer this question 'No', and now move on to the
actual protocol design space.  As we have repeatedly said, this document
does NOT serve as an advisory to which protocol or protocols should be
selected for ROLL.  It does highlight what are the areas that need
modification for a set of existing protocols, but this in no way inhibits
the presentation of any other protocols in the next stage.
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Arsalan Tavakoli <[email-masked]>
Date: Tue, 3 Feb 2009 08:06:07 -0800

> Why don't we write precisely that in some draft text?  Why not in the

This IS in the protocols-survey draft.  While we don't highlight NEMO
specifically, the document makes very clear its purpose is only to determine
if an existing specification meets all the requirements, and in the case
that it doesn't, it makes no claim on whether a new protocol design will be
presented, or an existing specification will be modified (and it does not
imply that existing is limited to those in the document).  Either way, NEMO
is included in this space.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 17:16:42 +0100

Arsalan Tavakoli a écrit :
>  specifically,

It's not that NEMO is not specifically highlighted, it's that it's not
> Protocol (NEMO RFC 3963 [RFC3963]) because it is not a routing 

Later phrases sound better, but I think the above could be better 
formulated to reflect better what you're saying.  I could suggest text 
if you wish, instead of crossing swords :-)

Alex

  the document makes very clear its purpose is only to
> determine if an existing specification meets all the requirements,
> and in the case that it doesn't, it makes no claim on whether a new
> protocol design will be presented, or an existing specification will
> be modified (and it does not imply that existing is limited to those
> in the document).  Either way, NEMO is included in this space.
> 
> 
> 
> 
> 
>

---

From: "M. B. Anand" <[email-masked]>
Date: Tue, 03 Feb 2009 11:45:28 -0500

JP Vasseur wrote:
> IP solution *now*.*
Indeed. And the bold letters are quite warranted. As we speak, actual 
legislation is moving through Congress in the US that specifies 
"Internet-enabled technologies" as a condition for grants in smart grid 
applications. Who knows what such technologies are ? There is no routing 
standard, there is no standard on any number of other things although 
there are bits and pieces of standards here and there. Billions of 
dollars are about to be handed out in the very near future and in the 
absence of any standards, practically everything is going to get claimed 
to be IP. The window is closing very, very fast.

While all this is surely not an excuse to produce shoddy work, it is 
certainly a tremendous driver to move. The sole reason for those of us 
engaged in the application space to be involved and contribute actively 
here is that there is a group of experts who having been doing 
networking for decades and there is an unrivaled body of knowledge at 
IETF on how to do networking correctly. That includes all the working 
groups. It needs to be done here and it needs to be done soon.
> added to move forward ? Please reply.
As has been said here many times, the purpose of this document is to 
evaluate the suitability of existing IETF protocols for their 
suitability for intersection of ROLL requirements. The document itself 
is very clear and states: "this document simply seeks to answer the 
question: do LLNs require a new protocol specification document at 
all?"  So, no, it is not superfluous, because this question needed to be 
answered. It is expressly not the purpose of this document to decide 
what is a useful approach or a starting point for any new protocol. It 
seems to get interpreted that way in many of these discussions and that 
is not its purpose.

In a recent email, Emmanuel states:
"Basically, everybody agrees that something special must be done for 
sensor ad hoc connectivity with IP, and everybody wants to reach the 
next phase ASAP (i.e. work on solutions). "

If everybody agrees on this, then this document should close without 
needing any further discussion. The whole purpose of the document is to 
document what everyone seems to agree on. Then, what is the disagreement ?

I suggest we restrict the discussion to the following:
1. Are there any disagreements on the analysis ?  - Seems not at the 
present time, or any such issues have already been addressed.
2. Should any criteria be removed and if so why ? - Again, I haven't 
seen anyone state this.
3. Let's not add any criteria - because that is not going to magically 
make the conclusion - i.e., the fact no existing protocol, unchanged, 
suits the requirements (which, BTW, everyone agrees on) change.

All the other discussions on ROLL, MANET, 6LoW etc. are perhaps valuable 
and there is a time and place for those, but it has little to do with 
this draft.

Best regards,
Anand.

---

From: <[email-masked]>
Date: Tue, 3 Feb 2009 17:42:57 +0100

Dear all,

I fully support Anand's comments - it's time to move on and work on WG rechartering to ignite the specification effort. 

Cheers,

Christian.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de M. B. Anand
Envoyé : mardi 3 février 2009 17:45
À : ROLL WG
Objet : Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt

> WRONG approach for a number of reasons. The industry is asking for an 
Indeed. And the bold letters are quite warranted. As we speak, actual legislation is moving through Congress in the US that specifies "Internet-enabled technologies" as a condition for grants in smart grid applications. Who knows what such technologies are ? There is no routing standard, there is no standard on any number of other things although there are bits and pieces of standards here and there. Billions of dollars are about to be handed out in the very near future and in the absence of any standards, practically everything is going to get claimed to be IP. The window is closing very, very fast.

While all this is surely not an excuse to produce shoddy work, it is certainly a tremendous driver to move. The sole reason for those of us engaged in the application space to be involved and contribute actively here is that there is a group of experts who having been doing networking for decades and there is an unrivaled body of knowledge at IETF on how to do networking correctly. That includes all the working groups. It needs to be done here and it needs to be done soon.
> added to move forward ? Please reply.
As has been said here many times, the purpose of this document is to evaluate the suitability of existing IETF protocols for their suitability for intersection of ROLL requirements. The document itself is very clear and states: "this document simply seeks to answer the
question: do LLNs require a new protocol specification document at all?"  So, no, it is not superfluous, because this question needed to be answered. It is expressly not the purpose of this document to decide what is a useful approach or a starting point for any new protocol. It seems to get interpreted that way in many of these discussions and that is not its purpose.

In a recent email, Emmanuel states:
"Basically, everybody agrees that something special must be done for sensor ad hoc connectivity with IP, and everybody wants to reach the next phase ASAP (i.e. work on solutions). "

If everybody agrees on this, then this document should close without needing any further discussion. The whole purpose of the document is to document what everyone seems to agree on. Then, what is the disagreement ?

I suggest we restrict the discussion to the following:
1. Are there any disagreements on the analysis ?  - Seems not at the present time, or any such issues have already been addressed.
2. Should any criteria be removed and if so why ? - Again, I haven't seen anyone state this.
3. Let's not add any criteria - because that is not going to magically make the conclusion - i.e., the fact no existing protocol, unchanged, suits the requirements (which, BTW, everyone agrees on) change.

All the other discussions on ROLL, MANET, 6LoW etc. are perhaps valuable and there is a time and place for those, but it has little to do with this draft.

Best regards,
Anand.

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Arsalan Tavakoli <[email-masked]>
Date: Tue, 3 Feb 2009 08:43:58 -0800

On Tue, Feb 3, 2009 at 8:16 AM, Alexandru Petrescu <
[email-masked]> wrote:

> formulated to reflect better what you're saying.  I could suggest text if
> you wish, instead of crossing swords :-)
>
> Alex

Let me rephrase this.  Are you implying that within the NEMO RFC exists a
routing protocol (which Phil, among others, has defined on this list
numerous times) that meets all the ROLL requirements as defined in the
protocol survey draft?

If the answer is yes, then terrific, we're done.  If however, the answer is
no, as we and you have postulated on this mailing list before, then in my
opinion this debate is an exercise in futility.  To gain the benefit of
having NEMO appear in the draft (which again it does not because of the
statement above which we stand by), we have prolonged last call on this
draft, which impedes our ability to move on to the actual protocol design,
as JP and others have been pleading on the list because if we don't have an
IP-based IETF ROLL protocol soon, we risk being bypassed by those looking to
adopt a standardized protocol.  I understand that you feel NEMO is a good
candidate that shouldn't be slighted; my point is that once we move beyond
this draft, that text in the draft excluding NEMO becomes moot; you will
have all the opportunity to present NEMO, or rather a NEMO-modification as a
candidate to become the ROLL standardized protocol.  But again, by
definition of our charter, we can NOT do that until this draft is last
called and finalized.

---

From: Mischa Dohler <[email-masked]>
Date: Tue, 03 Feb 2009 17:40:28 +0100

I am also in favor. Thanks, Mischa.

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 3 Feb 2009 11:52:21 -0500

Ditto. Let's wrap this up and move on to the next challenge. 

Regards,
Stan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mischa Dohler
Sent: Tuesday, February 03, 2009 11:40 AM
To: [email-masked]; M. B. Anand; ROLL WG
Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt

[email-masked] wrote:
> De : [email-masked] [mailto:[email-masked]] De la part 
> de M. B. Anand Envoyé : mardi 3 février 2009 17:45 À : ROLL WG Objet : 
> Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re: Review 
> andcomments draft-ietf-roll-protocols-survey-05.txt
> 
> JP Vasseur wrote:

---

From: "David E. Culler" <[email-masked]>
Date: Tue, 03 Feb 2009 09:02:49 -0800

Thomas,

1. The charter of MANET 
(http://www.ietf.org/html.charters/manet-charter.html) does not even 
contain the word POWER - nor should it.  MANET does not demand the 
intense focus on power that arises with embedded devices with no human 
being attached to them.  Yes, "mobile" does imply that protocols should 
be "relatively lightweight in nature", but living for three hours on a 
monstrous laptop battery is rather different from living for 3 years on 
a pair of AAs.  A few (like 5) orders of magnitude do make a 
difference.  Similarly, loss does occur in the context of mobility, but 
it is of an entirely different nature to that they arises with low power 
wireless in embedded environment.

2. The charter of ROLL 
(http://www.ietf.org/html.charters/roll-charter.html) only mentions the 
word MOBILE in making clear that it must be considered as part of the 
due diligence associated with the routing requirements.  If the process 
of turning over all the stones should bring mobility to the surface as a 
primary issue, then it would make sense to consider the overlap 
carefully.  They don't.  All the requirements are stationary.  Mobility 
within them is extremely constrained.

3. The charter of 6LoWPAN 
(http://www.ietf.org/html.charters/6lowpan-charter.html) does not 
include pursuing routing because it is in the Internet area.  That is 
one of the key reasons for ROLL, so that there could be work in the 
"routing" area.

So, the answer to the interminable questions about whether there is some 
procedural matter than might be used to derail the technical progress 
toward the goal of ROLL is NO.    We should stop wasting everyone's time 
with such efforts. 

The common issue is wireless.  The underlying argument that you seem to 
be making is that if it has anything to do with wireless belongs to 
MANET.  There is no question that the answer to that is also NO.

Thomas Heide Clausen wrote:
> to offer my understanding of the problem space and suggest some ways 
> of addressing my main concerns....
>
> the abstract, the statement that "existing protocols were not designed 
> with these requirements in mind" seem to confirm this).
>
> between ROLL and e.g. MANET are the same: mobile, wireless, fragility, 
> bandwidth, ....", ROLL may be able to quantify these as "below this 
> firm threshold" -- i.e. as a sort of "extreme" or "constrained" MANET.
>
> care about shortest paths") or -- if these assumptions do not hold, 
> that the evaluation criteria are incomplete.
>
>         have deducted. If my deduction is incorrect, then let's 
> quickly iterate on the list
>             -    Add a criteria & evaluation of "total cost for 
> getting user data through the network"
>

---

From: JP Vasseur <[email-masked]>
Date: Tue, 3 Feb 2009 18:03:10 +0100

Hi Alex,

On Feb 3, 2009, at 4:51 PM, Alexandru Petrescu wrote:

>> No, it doesn't mean that at all.  The protocol survey picked a set  
>> of candidates to evaluate (which was agreed upon on the mailing  
>> list and at IETF meetings), which only serve to answer the basic  
>> question: does any protocol currently exist that satisfies all  
>> requirements.  When we move to the next stage, specifications for  
>> protocols outside of those considered, including NEMO, are  
>> certainly more than welcome.
>
> In this case the entire protocols-survey draft looks superfluous:  
> its statements aren't of any use because in the next stage we ignore  
> its advice.
>

I understand that it is difficult to follow all the traffic *but* we  
said many times that the objective of the survey was to determine  
whether or not
we could find an existing protocol (with no change) satisfying the  
requirements, that's it.
On your recommendation to explicitly indicate that NEMO will be looked  
at, we will add it to the protocol survey. Does that satisfy your  
requirement ?

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Tue, 3 Feb 2009 18:04:04 +0100

Sorry Arsalan I replied before seeing your reply, which was  
identical ;-)

On Feb 3, 2009, at 5:03 PM, Arsalan Tavakoli wrote:

> of candidates to evaluate (which was agreed upon on the mailing list  
> and at IETF meetings), which only serve to answer the basic  
> protocols outside of those considered, including NEMO, are certainly  
> more than welcome.
>
> How are we ignoring it's advice?  While it might seem superfluous or  
> a formality to you, one of the real questions that we needed to  
> answer before moving on to protocol design (if necessary mind you),  
> was what are the base set of necessary but sufficient requirements  
> for this design space, and do any existing protocol specifications  
> meet these requirements.  This protocol survey allowed us to answer  
> this question 'No', and now move on to the actual protocol design  
> space.  As we have repeatedly said, this document does NOT serve as  
> an advisory to which protocol or protocols should be selected for  
> ROLL.  It does highlight what are the areas that need modification  
> for a set of existing protocols, but this in no way inhibits the  
> presentation of any other protocols in the next stage.
>

---

From: JP Vasseur <[email-masked]>
Date: Tue, 3 Feb 2009 18:05:15 +0100

Arsalan,

Let's wait until we get all final comment and if OK with Alex we'll  
add an explicit short section related to NEMO.

Thanks.

JP.

On Feb 3, 2009, at 5:06 PM, Arsalan Tavakoli wrote:

> Why don't we write precisely that in some draft text?  Why not in  
> the protocols-survey draft?
>
>
> Alex
>
> This IS in the protocols-survey draft.  While we don't highlight  
> NEMO specifically, the document makes very clear its purpose is only  
> to determine if an existing specification meets all the  
> requirements, and in the case that it doesn't, it makes no claim on  
> whether a new protocol design will be presented, or an existing  
> specification will be modified (and it does not imply that existing  
> is limited to those in the document).  Either way, NEMO is included  
> in this space.
>
>
>
>
>

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Tue, 3 Feb 2009 18:18:20 +0100

Hi all,

I also support this.

Best,
Julien

---

From: David Ward <[email-masked]>
Date: Tue, 3 Feb 2009 10:52:11 -0600

All -

We debated the delta between these three WGs when chartering ROLL for  
a considerable period of time. I do not want to revisit that debate  
but, I will quickly summarize here

- 6LOWPAN is not working at the IP layer so, the overlap here is  
really not an issue.
- MANET is and has been working on routing protocols for mobile, ad  
hoc networks with specific requirements and use cases. Some of those  
use cases may or may not overlap with ROLL. There will be lessons to  
be learned but, the primary use cases being worked on appeared by all  
the chairs and ADs involved to be different enough to warrant a new WG  
in this area.
- ROLL was originally chartered to write the requirements and evaluate  
existing protocols for low power, lossy networks running over IP (some  
call these  "sensor networks"). ROLL is only chartered to work on the  
routing protocol portion. Not the transport, encap or other topics at  
this time. Also note that mobility is not under consideration at this  
time.

ROLL WG appears to have come to consensus on the requirement docs that  
state specific functions, attributes, power/memory envelope and  
algorithmic considerations that must be "in the routing protocol" for  
these networks. The survey ID (which is of course a snapshot at one  
point in time) puts some bounds on mapping the required functions,  
attributes and other considerations into protocols available *today.*

Given the real work of designing a protocol hasn't begun by the ROLL  
WG participants; holding up the WG to begin taking what they currently  
defined as a very complex, multivariate problem and begin whittling it  
down to something solvable via theoretical and hypothetical exercises  
seems like an unwise use of time given the experience and energy of  
the WG in this problem space.  The WG must move beyond the moderately  
high-level boundary setting exercise (which I believe there is  
consensus) and move onto the more challenging work of defining the  
objects, algorithms, semantics, state machines and functionality of  
the protocol.  In the design phase (vs the survey phase) a better  
evaluation can be made of the ease or difficulty of "from scratch" or  
"modify what we have" can be made. I expect "wild swings" of the  
design pattern of the protocol during the first year of the design  
effort. I attempted to make this clear at the mic in Minneapolis that  
the current trajectory is very complex problem domain that hasn't born  
a lot of fruit but, that in the design phase reducing the complexity  
must occur. Members of the WG who have vast experience in these types  
of networks and have widely deployed products have stated that the  
routing protocol issues are solvable problems with some simplifying  
assumptions. I look forward to the WG making these design decisions  
and tradeoffs and debating the structure of the protocol. Any protocol  
reuse, experience, etc will be critical at this point to make the  
correct choices and I look to MANET, ROLL, MEXT, 6LOWPAN and other  
IETF'ers with routing protocol experience to contribute. This is an  
industry important juncture and moving LPLN to IP is a critical change.

I am looking to the WG chairs to declare loose consensus on the  
documents  (when appropriate) so that the rechartering of the WG to  
enter the design phase can occur. WIthout a doubt, the requirements as- 
is have defined the boundary of the work effort and I believe it is  
clear what is the difference between the WGs.

HIH

-DWard

On Feb 3, 2009, at 7:14 AM, Thomas Heide Clausen wrote:

> (I Cc the other INT chair, as he's following 6lowpan)
>
>>>> and

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 18:27:17 +0100

JP Vasseur a écrit :
[...]
> On your recommendation to explicitly indicate that NEMO will be
> looked at, we will add it to the protocol survey. Does that satisfy
> your requirement ?

YEs, I agree.  Do you want me to fork a separate thread with the NEMO text?

And let me take advantage of this opening by re-suggesting the 
correction of the protocols-survey ND text.  There is an error here:

Such reply implosion is avoided by the IPv6 ND spec, because it requires
the RAs responding to an RS be spaced randomly in time:

[...]
> MAX_RA_DELAY_TIME seconds.

In this sense, do you want me to make a separate thread regarding this 
ND text?

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 3 Feb 2009 17:31:19 -0000

I think this posting has taken a reasonable point and greatly
overstated it. If it were in the draft, I'd certainly want it
changed.

> contain the word POWER

True, but as you go on to point out, it contains other phrases that
equate to that limiting power is a good thing (to be balanced with
other good things).

> living for three hours on a monstrous laptop battery is rather
> different from living for 3 years on a pair of AAs.

True. And most MANETs don't have to live for 3 years on a pair of
AAs - though I don't know any that wouldn't like to. But neither
is 3 hours on a laptop battery the universal state of affairs either.

> All the requirements are stationary.

Really MANET should have been named DANET (dynamic, not mobile)
but there wasn't a French impressionist painter of that name.
Stationary (not physically moving) does not imply static, and
many MANETs use their dynamism to cope with other forms of
dynamism - node loss (power exhaustion, damage, theft etc.)
and propagation changes (opening a door in a building can
necessitate a reconfiguration, especially if the door is
metal). Generally a slower timescale (but doors can open
quite quickly).

As I would see it, there is MANET, the concept. Everything ROLL
is doing is within that space. But then there's MANET the WG,
creating some general purpose protocols covering much of that
space - not all, but more than (for example) earlier drafts of
this document recognised. Do those protocols "as is" cover ROLL's
space? No. So there's the justification for ROLL. But it does no
one any favours to claim ROLL is "other" and totally different
(and I still don't like "novel" in the abstract). It's an extreme
case, but part of a continuum. Which leads to some people's issues.

********************************************************************
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: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 3 Feb 2009 17:31:21 -0000

M.B. Anand
> document what everyone seems to agree on. Then, what is the
disagreement ?

That is a little simplistic. Let's suppose that the document said
that protocol X is a bad protocol, totally unsuited for ROLL or any
other work. Now suppose the authors of protocol X agreed it was
unsuited for ROLL, but thought it was a highly valuable protocol
for other work. Now as far as ROLL is concerned, there may be no
difference. But if the document proceeded, there would then be an
RFC saying protocol X is a bad protocol. It may get quoted in
non-ROLL contexts. This would not be good.

Now the ROLL document doesn't say protocol X is a bad protocol for
any X. Some people however aren't entirely happy with some details
the document includes, and would view this as a more limited case
of such a problem. Maybe they are right, maybe they are wrong, maybe
the best solution is a small change. (Some such small changes have
already taken place.) The point is if this is going to be an RFC,
it's not just the internal purposes of ROLL that matter.

Note that I'm not saying I have such an issue (I think the document
could be better, but am not sure it's worth the effort, and as I'm
not volunteering the effort, that's a pass). But it's worth
understanding why some people may have problems, as, if nothing else,
that way you can reach agreement more easily.

---

From: "David E. Culler" <[email-masked]>
Date: Tue, 03 Feb 2009 09:39:53 -0800

Absolutely.  The survey is not a beauty context.  Nor does it pas
judgment on the value of any piece of work.  It in no way suggest that
anything that is considered is "Bad".  It merely does the due diligence
to determine if there is any work to be done.  And while we might
quibble about the 3rd order or 4th order bit, the high order bit is
unequivocally YES.  There is work to be done.

However, the recondition for doing that work is that the survey is
done.

Dearlove, Christopher (UK) wrote:

M.B. Anand

If everybody agrees on this, then this document should close without
needing any further discussion. The whole purpose of the document is

to

document what everyone seems to agree on. Then, what is the

disagreement ?

---

From: JP Vasseur <[email-masked]>
Date: Tue, 3 Feb 2009 18:40:25 +0100

Hi Christopher,

On Feb 3, 2009, at 6:31 PM, Dearlove, Christopher (UK) wrote:

> other work.

I hope that you do not interpret the conclusion on the suitability of a
protocol to a specific issue as "this protocol is BAD".

> Now suppose the authors of protocol X agreed it was
> difference.

There is a difference. We say:
* This protocol does not (in ITS CURRENT STATE) meet the requirements.
* The authors are welcome to propose a modified version in the next  
step !

> But if the document proceeded, there would then be an

It will not, the survey is quite clear on this. We can make sure to  
add 1-2 sentences
very explicitly if you will.

> it's not just the internal purposes of ROLL that matter.

Informational RFC with limited scope (very explicitly pointed out in  
the I-D).

> that way you can reach agreement more easily.

Sure, thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Tue, 3 Feb 2009 18:36:27 +0100

Thanks Dave for AD's feed-back.

We *are* making progress and looking at all the interest that we are  
gathering from many participants, this is a good sign of strong  
participation for the next phase, a key of success.

First of all, I would like to remind that all the routing requirements  
documents are finalized. I asked for a last revision of the building  
routing requirements documents before publication request. And then we  
will be done for this part. Lot of work.

Here is what I propose:

1) I guess that things have been clarified on the WG positioning issue.
2) Many supportive request to close on this and move forward.
3) Still there are a few requests that have been made by Thomas,  
Alex, ... that we should try to address.
May I ask you to try to limit as much as possible your request and we  
will do everything possible to address them.
4) End of this week, we will close on the protocol survey.
5) Right after we'll propose you a new charter (one week discussion)  
before IESG submission.
6) If/once re-chartered, we count on everybody's help to continue the  
good work.

Thanks.

JP.

On Feb 3, 2009, at 5:52 PM, David Ward wrote:

> All -
>
> We debated the delta between these three WGs when chartering ROLL  
> for a considerable period of time. I do not want to revisit that  
> debate but, I will quickly summarize here
>
> be learned but, the primary use cases being worked on appeared by  
> all the chairs and ADs involved to be different enough to warrant a  
> new WG in this area.
> - ROLL was originally chartered to write the requirements and  
> evaluate existing protocols for low power, lossy networks running  
> over IP (some call these  "sensor networks"). ROLL is only chartered  
> to work on the routing protocol portion. Not the transport, encap or  
> other topics at this time. Also note that mobility is not under  
> consideration at this time.
>
> ROLL WG appears to have come to consensus on the requirement docs  
> that state specific functions, attributes, power/memory envelope and  
> algorithmic considerations that must be "in the routing protocol"  
> for these networks. The survey ID (which is of course a snapshot at  
> one point in time) puts some bounds on mapping the required  
> functions, attributes and other considerations into protocols  
> available *today.*
>
> WG participants; holding up the WG to begin taking what they  
> currently defined as a very complex, multivariate problem and begin  
> whittling it down to something solvable via theoretical and  
> hypothetical exercises seems like an unwise use of time given the  
> experience and energy of the WG in this problem space.  The WG must  
> move beyond the moderately high-level boundary setting exercise  
> (which I believe there is consensus) and move onto the more  
> challenging work of defining the objects, algorithms, semantics,  
> state machines and functionality of the protocol.  In the design  
> phase (vs the survey phase) a better evaluation can be made of the  
> ease or difficulty of "from scratch" or "modify what we have" can be  
> made. I expect "wild swings" of the design pattern of the protocol  
> during the first year of the design effort. I attempted to make this  
> clear at the mic in Minneapolis that the current trajectory is very  
> complex problem domain that hasn't born a lot of fruit but, that in  
> the design phase reducing the complexity must occur. Members of the  
> WG who have vast experience in these types of networks and have  
> widely deployed products have stated that the routing protocol  
> issues are solvable problems with some simplifying assumptions. I  
> look forward to the WG making these design decisions and tradeoffs  
> and debating the structure of the protocol. Any protocol reuse,  
> experience, etc will be critical at this point to make the correct  
> choices and I look to MANET, ROLL, MEXT, 6LOWPAN and other IETF'ers  
> with routing protocol experience to contribute. This is an industry  
> important juncture and moving LPLN to IP is a critical change.
>
> enter the design phase can occur. WIthout a doubt, the requirements  
> as-is have defined the boundary of the work effort and I believe it  
> is clear what is the difference between the WGs.
>
>
> HIH
>
> -DWard
>
>
>
>
>> eye, in exactly the same space. My position is that it would be  
>> very unfortunate having one WG creating confusion on the  
>> applicability of the work of itself and of other IETF wg's, by  
>> simple omission of suitable perimeter definitions.
>>
>>> closed non-IP solutions are being deployed at a fairly large  
>>> industry is asking for an IP solution *now*.
>>> quite specific. Note that this is not a random example, but an on- 
>>> going non-IP deployed network.
>>>
>>> 	- Try to derive a subset of necessary but not sufficient  
>>> criteria, which the WG chose to do (consensus). Yes this list is  
>>> not perfect,
>>> 	criteria could be changed, removed or added but looked good  
>>> enough with excellent consensus until LC.
>>> adopted as a 6lowpan WG item by consensus. We're are working

---

From: JP Vasseur <[email-masked]>
Date: Tue, 3 Feb 2009 18:43:13 +0100

Please do ... please do it short and concise ;-)

Thanks.

JP.

On Feb 3, 2009, at 6:27 PM, Alexandru Petrescu wrote:

> In this sense, do you want me to make a separate thread regarding  
> this ND text?
>
> Alex
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 18:43:32 +0100

David E. Culler a écrit :
[...]
> within them is extremely constrained.

More to the point, current ROLL req drafts mentioning mobility are as 
follows:

Industrial:
5 - Mobility: wireless worker, mobile field devices, speed 35kmph

Home:
2 - Support of Mobility: multi-purpose remote, mobile wearable

Building:
3 - Mobility: mobile device association in 15s, location tracking

These kinds of key words have often been addressed with Mobile IP based 
protocols (of which NEMO are extensions), for example in a IPv6-enabled 
wearable PAN, or a bus connected to Internet, etc.

Given that, I am surprised it's said that all requirements are 
stationary and mobility within them is extremely constrained(?)

Alex

---

From: Kris Pister <[email-masked]>
Date: Tue, 03 Feb 2009 11:25:55 -0800

Alex - I can't speak for the other applications, but it is misleading to 
use the industrial requirements document to support a need for mobility.
There are 14 "MUST"s in the industrial requirements document.  None of 
them is associated with mobility.  There are a few "SHOULD"s associated 
with mobility.  It would be nice to have, but not at the expense of any 
of the MUSTs.

I don't understand the discussion about the protocol survey document.  
It seems like the discussion is distracting us from the main goal: 
finding a routing protocol that works.
If there is a protocol that satisfies the routing requirement MUSTs in 
my document and the other three, then let's implement it on motes and 
move on, and we won't care too much about whether RoLL recharters or 
not, and we certainly won't care what gets listed in the protocol survey 
document.
If such a protocol doesn't exist, then please let's recharter and create 
one.

ksjp

Alexandru Petrescu wrote:
>> (http://www.ietf.org/html.charters/roll-charter.html) only mentions 
>> the word MOBILE in making clear that it must be considered as part of 
>> the due diligence associated with the routing requirements.  If the 
>> process of turning over all the stones should bring mobility to the 
>> surface as a primary issue, then it would make sense to consider the 
>> overlap carefully.  They don't.  All the requirements are 
>> stationary.  Mobility within them is extremely constrained.
>
> These kinds of key words have often been addressed with Mobile IP 
> based protocols (of which NEMO are extensions), for example in a 
> IPv6-enabled wearable PAN, or a bus connected to Internet, etc.
>

---

From: Stephen Dawson-Haggerty <[email-masked]>
Date: Tue, 3 Feb 2009 11:47:38 -0800

I accidentally did not copy the list earlier.  See below.

On Tue, Feb 3, 2009 at 9:49 AM, Alexandru Petrescu <
[email-masked]> wrote:

> Stephen, thanks for the email.
>
> I would have liked this to go public though... I don't feel like
> exchanging privately at this point about ROLL.
>
> Stephen Dawson-Haggerty a écrit :
>
>> protocols-survey draft:
>>
>> The fact that all routers must respond to a Router Solicitation requires
>> that the number of routers with a 1-hop neighborhood is small, or there will
>> be a reply implosion.
>>
>>
>> Such reply implosion is avoided by the IPv6 ND spec, because it
>> requires the RAs responding to an RS be spaced randomly in time:
>>
>> RFC4861 "ND for IPv6":
>>
>> RFC2461 and 4861 define MAX_RA_DELAY_TIME as 0.5 seconds.   I think
>> it's very likely to lead to a lot of instantaneous traffic and
>> congestion if implemented exactly as specified.
>>
>
> I'm not sure... has one witnessed such implosion when the delay time was
> 0.5s? I really don't see why?

>
>  This is the reason for the text; we disagree that this mechanism /as
>> defined/ solves the problem; for instance especially on slower 900Mhz
>> links, this could completely congest the link as many senders
>> contend; this would be unacceptable.
>>
>
> Which link sorry?  Which is the link at 900Mhz over which ND would
> behave such badly?  What's its bandwidth?  Is it a ptp or shared link?

The ISM band has slots at, for instance 433 and 900Mhz; older Chipcon cc1000
radios provided a link at around 75kbps.  Now, we generally talk about
802.15.4 (that isn't) but we also don't want to rely on mechanisms that
won't work for other links since it's pretty conceivable someone would want
to run IP over a slower link (for instance to save power).  A 50 byte packet
at 75kbps is almost 7ms long, so it's not unreasonable to conclude that it
won't support densities higher then 25-50 if everyone MUST reply within half
a second.

In sensor nets reply implosion is pretty common;I'm sure there are other
people here will attest to that and you have to be very careful to manage
it, for instance using a density-dependent scheme like Trickle.

Let's not get sidetracked by ND though; I haven't heard any other concerns
about it and I feel like it's known both here and in 6lowpan that new
mechanisms are necessary. We'll welcome a look at your NEMO text.

Steve

>
>
> Alex
> PS: I suggest we go public with this, sorry...
>
>
>

---

From: Kris Pister <[email-masked]>
Date: Tue, 03 Feb 2009 12:04:24 -0800

excellent questions, Alex.  No doubt there will be many low power and 
lossy DLLs for us to route over in the future, but there are several 
that are of immediate commercial interest. 802.15.4 is a good place to 
start as an example.  There are at least a half-dozen different 
deeply-duty-cycled DLLs that have been demonstrated for 15.4 radios.  
All of them allow for a tradeoff between power consumption and useful 
bandwidth, typically over a range of at least three orders of 
magnitude.  I'd like to make sure that whichever routing protocol we use 
(find? create?  you tell me) that it can make intelligent use of the 
DLL.  It's really easy to build a network that runs everything at 1% 
duty cycle, but it turns out to give lousy performance in a lot of 
commercially relevant scenarios.

So in my opinion, our work won't be done until we have a routing 
protocol that has some mechanism to
1) be aware of the currently configured capabilities of the DLL , and 
the limits of configuration (e.g. I can handle 1 packet/sec right now, 
and up to 10 packets/sec if you need me to)
2) be able to configure those capabilities based on the routing decisions

I'm not hung up on this being in the routing protocol itself.  If you 
tell me that the right way to do it is through some other existing 
xyz-TE protocol that is independent of the routing protocol, that's 
fine.  But I'm convinced that the variable power/throughput capabilities 
of RoLL DLLs is one of the fundamental differences that makes routing 
"interesting" in these networks.

ksjp

Alexandru Petrescu wrote:
> themselves to the IP stack?  Do they all use the typical Ethernet MAC 
> interface? Or point-to-point links?
>
>>> requires

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 21:33:07 +0100

The existing NEMO text is in draft-ietf-roll-protocols-survey-05:

> 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.

I suggest replacing the above paragraph with the following longer
text, maybe in its own section.

    In this section we briefly overview the NEMO extensions to Mobile
    IPv6, its accepted drawbacks, and its features with respect to
    memory footprint (Table?), protocol reliability (Loss, Control?),
    energy metrics (Link and Node Cost?) and security.

    The Network Mobility Basic Support Protocol ("NEMO" RFC 3963,
    terminology RFC4885) is a set of extensions to the Mobile IPv6
    protocol (RFC3775).  They extend Mobile IPv6 to accomodate a moving
    network, i.e. a set of nodes moving together, and connecting to the
    Internet: laptops in a bus, or a PDA and a camera of a PAN.
    Arbitrarily "nested" combinations - e.g. a PAN getting into a bus -
    can equally be accomodated.  One noticeable problem is the
    enforcing of artifically long paths - all traffic between a
    Correspondent Node and a Local Fixed Node must travel through the
    Home Agent(s) (RFC4888), despite the existence of shorter straight
    IP paths.  Solutions addressing this problem are in the space of
    Route Optimization for NEMO (RFC4889), yet none is Standards Track
    at this point.

    The Mobile IPv6 protocol has been implemented on a wide range of
    platforms, of main OS vendors and freely available, from servers to
    smaller devices.  A footprint of a TCP/UDP/ND/IPv6 stack running
    NEMO and Mobile IPv6 in a Mobile Router is for example 200kb.

    Although the Mobile IPv6 protocol is basically a two-way exchange, it	
    has lifetimes, timers and retransmission logic such as to accommodate	
    several types of failures of the critical messages; and rate		
    limitation such as to avoid too much noise.				
    									
    The Mobile IPv6 NEMO extensions are used mainly between a Mobile	
    Router and a Home Agent: the MR updates only the HA about its Mobile	
    Network Prefix (MNP); it doesn't update several entities, just one.	
    									
    The Mobile IPv6 protocol and implicitely its NEMO extensions do not	
    currently have any field in the messages, nor any logic in the nodes,	
    relating to energy consumption.  One would think that binding		
    lifetimes would need to depend on remaining battery level; and maybe	
    an Error Code from the HA meaning 'not enough battery'; or similar.	
    Other possibilities do exist.

    An approximation of energy consumption of a particular small device
    running such an IPv6 stack can be divided as follows: 40% energy to
    enable the WiFi driver, 1% of energy to send IPv6 packets.

    The NEMO extensions and the Mobile IPv6 protocol are generally
    believed to be secure.  For through-the-HA communication they make
    extensive use of IPsec transport and tunnels (RFC4877) whereas for
    Route Optimization for Mobile Hosts a particular authentication
    mechanism is used (Return Routability tests).

    Conclusion: this section surveyed the NEMO (RFC3963) extensions to
    the Mobile IPv6 protocol, as necessary for a ROLL WG context.  It
    doesn't in any way pretend to be a complete (the protocol has many
    other features necessary in mobility environments), and errors may
    have slipped through, this is open to comments.

What do you think?

Alex

---

From: Kris Pister <[email-masked]>
Date: Tue, 03 Feb 2009 12:53:05 -0800

Is the footprint really 200kb, which is painful but might be ok, or 
200kB?  The latter is not going to work for any of the platforms 
currently addressing the four RoLL applications.

I don't understand the 40% WiFi driver and 1% for traffic.  What does 
that mean, exactly?  For most of the applications that we're talking 
about here, you get 10 to 100 microAmps average current.  This doesn't 
have anything to do with radios, DLLs, or routing protocols, it has to 
do with the acceptable battery size/cost and required lifetime.
Anything with "40%" and "WiFi" in the same part of a sentence makes me 
nervous.

ksjp

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 21:54:08 +0100

Stephen Dawson-Haggerty a écrit :
[discussion about RA implosion when RS sent to thousand neighbours,
  protocols-survey draft]

> The ISM band has slots at, for instance 433 and 900Mhz; older Chipcon
>  cc1000 radios provided a link at around 75kbps.  Now, we generally 
> talk about 802.15.4 (that isn't) but we also don't want to rely on 
> mechanisms that won't work for other links since it's pretty 
> conceivable someone would want to run IP over a slower link (for 
> instance to save power).  A 50 byte packet at 75kbps is almost 7ms 
> long, so it's not unreasonable to conclude that it won't support 
> densities higher then 25-50 if everyone MUST reply within half a 
> second.

Stephen, I fully agree the links you mention at 75kbps are pertinent and
should be accommodated in ROLL environments.

Indeed, 7ms latency is quite high and 1000 such messages wouldn't fit in
500ms, even if randomly spaced: some times there would be 2 or 3
simultaneous messages, maybe not very stormy.

PtP? I wanted to ask, arent't these links with high latencies of type
point-to-point?  I think it's very probably that a link with 75kbps
bandwidth be point-to-point.  In this case the nodes are neighbors
1-by-1, and thus no implosion (or message 'storm') danger.

> In sensor nets reply implosion is pretty common; I'm sure there are 
> other people here will attest to that and you have to be very careful
>  to manage it, for instance using a density-dependent scheme like 
> Trickle.
> 
> Let's not get sidetracked by ND though;

I'm using ND and link types as an opportunity to try to describe the 
addressing architecture and the subnet structure.  These are typical for 
MANET discussion and often helpful to identify what can be done at IP 
level and what below.

Alex

---

From: Stephen Dawson-Haggerty <[email-masked]>
Date: Tue, 3 Feb 2009 12:55:53 -0800

Thanks for the suggestions.  I think we may be able to work with some of
this.  However, some of the language is unnecessarily imprecise ("maybe an
Error Code from the HA meaning 'not enough battery'; or similar.", "avoid
too much noise. ").  Including power numbers is inappropriate because as we
state in section 3.3 we do not consider any particular implementation.
Discussing security is important and has been discussed on the list,
however, section 10 indicates that it is out of scope; it is yet another
reason this document is "necessary but not sufficient" (3.2).

I believe the goal for an updated paragraph should be to (a) briefly define
what NEMO is/does (we don't really do this now) and (b) why certain
mechanims are desirable to consider it when actually designing a routing
protocol (we have only a sentence on this now),  and finally (c) justify why
it is not included in Table 1 (we do this).  So, expanding on the (a) and
(b) seems worthwhile, but not in more then a couple of sentences each.

JP asked (and we authors feel), short and concise :)  The below accomplishes
(a) and (c).  We might want to identify more specific ways NEMO mechanisms
could be used in a ROLL solution to deal with (b).  Thoughts?

Thanks for your suggestions.
Steve

  The Network Mobility Basic Support Protocol ("NEMO" RFC 3963,
  terminology RFC4885) is a set of extensions to the Mobile IPv6
  protocol (RFC3775).  They extend Mobile IPv6 to accomodate a moving
  network, i.e. a set of nodes moving together, and connecting to the
  Internet: laptops in a bus, or a PDA and a camera of a PAN.
  Arbitrarily "nested" combinations - e.g. a PAN getting into a bus -
  can equally be accomodated.  This document does not examine (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.

On Tue, Feb 3, 2009 at 12:33 PM, Alexandru Petrescu <
[email-masked]> wrote:

>> (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

---

From: Stephen Dawson-Haggerty <[email-masked]>
Date: Tue, 3 Feb 2009 12:58:19 -0800

Kris also brought up another good point which is that if the links are
aggressively duty cycled (we consider that likely) matters are likely to be
even worse.  Also, most discussion in this group has not considered point to
point links; I don't believe they are prevalent in this design space.

Thanks,
Steve

On Tue, Feb 3, 2009 at 12:54 PM, Alexandru Petrescu <
[email-masked]> wrote:

>>  cc1000 radios provided a link at around 75kbps.  Now, we generally talk
>> about 802.15.4 (that isn't) but we also don't want to rely on mechanisms
>> that won't work for other links since it's pretty conceivable someone would
>> want to run IP over a slower link (for instance to save power).  A 50 byte
>> packet at 75kbps is almost 7ms long, so it's not unreasonable to conclude
>> that it won't support densities higher then 25-50 if everyone MUST reply
>> within half a second.
>>
>
>  In sensor nets reply implosion is pretty common; I'm sure there are other
>> people here will attest to that and you have to be very careful
>>  to manage it, for instance using a density-dependent scheme like Trickle.
>>
> MANET discussion and often helpful to identify what can be done at IP level
> and what below.
>
> Alex
>
>

---

From: Zach Shelby <[email-masked]>
Date: Tue, 03 Feb 2009 23:01:24 +0200

I fully agree. The WG documents and approach have my support and it is 
definitely time to start rechartering.

- Zach

-- 

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti
FINLAND

mobile: +358 40 7796297

This e-mail and all attached material are confidential and may contain 
legally privileged information. If you are not the intended recipient, 
please contact the sender and delete the e-mail from your system without 
producing, distributing or retaining copies thereof.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 22:04:18 +0100

> "interesting" in these networks.

Trying to identify to what extent the interesting part is already 
addressed at link-layer...

A link with its own routing (isa100.11a) talks to another link with its 
own other link routing (zigbee) through an IP router.  This wouldn't run 
any routing protocol, because the link-layer routing is enough.

I'm not sure I understand how variable power/throughput capabilities of 
RoLL DLLs make IP routing interesting for these networks.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 22:08:50 +0100

Kris Pister a écrit :
> Alex - I can't speak for the other applications, but it is misleading
> to use the industrial requirements document to support a need for
> mobility. There are 14 "MUST"s in the industrial requirements
> document.  None of them is associated with mobility.  There are a few
> "SHOULD"s associated with mobility.  It would be nice to have, but
> not at the expense of any of the MUSTs.
> 
> finding a routing protocol that works. If there is a protocol that
> satisfies the routing requirement MUSTs in my document and the other
> three, then let's implement it on motes and move on, and we won't
> care too much about whether RoLL recharters or not, and we certainly
> won't care what gets listed in the protocol survey document. If such
> a protocol doesn't exist, then please let's recharter and create one.

I also highly appreciate implementations.

The question about rechartering: implementations for a charter need to 
know what to implement, lazily.  I think we (at least not me) don't know 
what to implement at this point about ROLL.

On one hand it's very specific (routing, energy, latency, etc) on 
another hand I can't find a single hammer to address them.

Alex

>> David E. Culler a écrit : [...]
>>> 2. The charter of ROLL 
>>> (http://www.ietf.org/html.charters/roll-charter.html) only
>>> mentions the word MOBILE in making clear that it must be
>>> considered as part of the due diligence associated with the
>>> routing requirements.  If the process of turning over all the
>>> stones should bring mobility to the surface as a primary issue,
>>> then it would make sense to consider the overlap carefully.  They
>>> don't.  All the requirements are stationary.  Mobility within
>>> them is extremely constrained.
>> 
>> More to the point, current ROLL req drafts mentioning mobility are
>> as follows:
>> 
>> Industrial: 5 - Mobility: wireless worker, mobile field devices,
>> speed 35kmph
>> 
>> Home: 2 - Support of Mobility: multi-purpose remote, mobile
>> wearable
>> 
>> Building: 3 - Mobility: mobile device association in 15s, location
>> tracking
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 22:17:02 +0100

> currently addressing the four RoLL applications.

200k_B_.  I consider it small.

A large part of an IPv6 stack is taken by TCP code.  ND also may have
large state machine for NUD, but could be stripped.

Are RoLL applications relying on TCP or not?  Is UDP sufficient?

>  that mean, exactly?

It means the proportion of the consumption is veyr much taken by the
wifi chipset, and very very little by sending/receiving a packet.

> For most of the applications that we're talking about here, you get 
> 10 to 100 microAmps average current.  This doesn't have anything to 
> do with radios, DLLs, or routing protocols, it has to do with the 
> acceptable battery size/cost and required lifetime. Anything with 
> "40%" and "WiFi" in the same part of a sentence makes me nervous.

:-)

In the reassuring applications: do we have an idea about the percentage
of consumption of turning the radio on, as compared to sending/receiving
an IP packet?  And the name of that particular link layer?

One would prefer be sure when optimizing energy consumption that s/he
addresses the right weaknesses, at the right layers.  A quantitative
approach would involve measuring these...

Alex

>>> [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.
>> 
>>  network, i.e. a set of nodes moving together, and connecting to 
>> the Internet: laptops in a bus, or a PDA and a camera of a PAN. 
>> Although the Mobile IPv6 protocol is basically a two-way exchange, 
>> it      has lifetimes, timers and retransmission logic such as to 
>> accommodate      several types of failures of the critical 
>> messages; and rate          limitation such as to avoid too much 
>> noise.                                                        The 
>> Mobile IPv6 NEMO extensions are used mainly between a Mobile Router
>>  and a Home Agent: the MR updates only the HA about its Mobile 
>>  The Mobile IPv6 protocol and implicitely its NEMO extensions do
>> not currently have any field in the messages, nor any logic in the 
>> nodes, relating to energy consumption.  One would think that 
>> binding lifetimes would need to depend on remaining battery level; 
>> and maybe an Error Code from the HA meaning 'not enough battery'; 
>> or similar.      Other possibilities do exist.
>> 
>>  running such an IPv6 stack can be divided as follows: 40% energy 
>> to enable the WiFi driver, 1% of energy to send IPv6 packets.
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 22:18:55 +0100

Stephen Dawson-Haggerty a écrit :
> Kris also brought up another good point which is that if the links
> are aggressively duty cycled (we consider that likely) matters are
> likely to be even worse.  Also, most discussion in this group has not
> considered point to point links; I don't believe they are prevalent
> in this design space.

I think the slower the link, and the higher latency,  the more chances 
are it's a ptp link.  I think some Bluetooth serial links are ptp.  I 
think serial rs-232 is ptp.  I think these are potentially used in this 
space.

Alex

> 
> Thanks, Steve
> 
> On Tue, Feb 3, 2009 at 12:54 PM, Alexandru Petrescu 
> Stephen Dawson-Haggerty a écrit : [discussion about RA implosion when
> RS sent to thousand neighbours, protocols-survey draft]
> 
> 
> Stephen, I fully agree the links you mention at 75kbps are pertinent
> and should be accommodated in ROLL environments.
> 
> Indeed, 7ms latency is quite high and 1000 such messages wouldn't fit
> in 500ms, even if randomly spaced: some times there would be 2 or 3 
> addressing architecture and the subnet structure.  These are typical 
> for MANET discussion and often helpful to identify what can be done 
> at IP level and what below.
> 
> Alex
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 22:35:16 +0100

Stephen Dawson-Haggerty a écrit :
> Thanks for the suggestions.  I think we may be able to work with some
>  of this.  However, some of the language is unnecessarily imprecise 
> ("maybe an Error Code from the HA meaning 'not enough battery'; or 
> similar.", "avoid too much noise. ").

Imprecise because avoid being restrictive.

"avoid too much noise" - maybe "avoid protocol
chattiness"?

I'd agree to another more literate re-formulation.

> Including power numbers is inappropriate because as we state in 
> section 3.3 we do not consider any particular implementation.

Well these are not power numbers but percentage, reports, hinting
between link layers and network layers.

>  however, section 10 indicates that it is out of scope; it is yet 
> another reason this document is "necessary but not sufficient" (3.2).

Do you mind mentioning NEMO rfc3963 is believed to be secure?  Do you 
think otherwise?

> I believe the goal for an updated paragraph should be to (a) briefly
>  define what NEMO is/does (we don't really do this now) and (b) why 
> certain mechanims are desirable to consider it when actually 
> designing a routing protocol (we have only a sentence on this now), 
> and finally (c) justify why it is not included in Table 1 (we do 
> this).  So, expanding on the (a) and (b) seems worthwhile, but not in
>  more then a couple of sentences each.

I understand what you want in (a) but could you clarify what you want in
(b)?  why certain mechanisms are desirable to consider when designing a
routing protocol?  Which mechanisms?

> JP asked (and we authors feel), short and concise :)

Trying to be concise.

> The below accomplishes (a) and (c).  We might want to identify more 
> specific ways NEMO mechanisms could be used in a ROLL solution to 
> deal with (b). Thoughts?

I don't understand, do you want me to describe personal proposals (non
WG items, non RFC) about how some NEMO extensions could be used in ROLL? 
  Wouldn't that be too much for this WG? (and be more pertinent for MEXT 
WG).

Alex

> Thanks for your suggestions. Steve
> 
> can equally be accomodated.  This document does not examine (NEMO RFC
>  3963 [RFC3963]) because it is not a routing protocol.  It does not 
>  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 
> On Tue, Feb 3, 2009 at 12:33 PM, Alexandru Petrescu 
> IPv6, its accepted drawbacks, and its features with respect to memory
>  footprint (Table?), protocol reliability (Loss, Control?), energy 
> metrics (Link and Node Cost?) and security.
> 
> can equally be accomodated.  One noticeable problem is the enforcing
>  of artifically long paths - all traffic between a Correspondent Node
>  and a Local Fixed Node must travel through the Home Agent(s) 
> (RFC4888), despite the existence of shorter straight IP paths. 
> Solutions addressing this problem are in the space of Route 
> Optimization for NEMO (RFC4889), yet none is Standards Track at this
>  point.
> 
> smaller devices.  A footprint of a TCP/UDP/ND/IPv6 stack running NEMO
>  and Mobile IPv6 in a Mobile Router is for example 200kb.
> 
>  has lifetimes, timers and retransmission logic such as to 
> accommodate several types of failures of the critical messages; and 
> rate limitation such as to avoid too much noise.
> 
>

---

From: Kris Pister <[email-masked]>
Date: Tue, 03 Feb 2009 13:45:03 -0800

Alexandru Petrescu wrote:
> know what to implement, lazily.  I think we (at least not me) don't 
> know what to implement at this point about ROLL.
>
Hence the need to recharter to build the right hammer.

ksjp

---

From: Kris Pister <[email-masked]>
Date: Tue, 03 Feb 2009 14:01:31 -0800

> 200k_B_.  I consider it small.
I think that this may be one of the points of disconnect.  The wireless 
sensor network products that are shipping today in industrial, building, 
home, and urban applications all have far less than 200kB of program 
memory. 50kB might be close to average.
In this amount of space, protocols have implemented RS, RA, ND, 
multi-topology routing, reliable and best-effort transport, etc., in 
addition to the DLL and application.  So space is very tight, but there 
are existence proofs that it's possible.
There's a huge body of literature describing the academic side of this, 
and a couple of very thick standards documents describing HART, ISA100, etc.
> Are RoLL applications relying on TCP or not?  Is UDP sufficient?
Both reliable and best-effort transport are required for industrial 
automation.  Applications don't use TCP today because they don't use IP 
today.
> wifi chipset, and very very little by sending/receiving a packet.
We don't have that luxury.  If sending/receiving the packet isn't in the 
tens of percent of the overall node power consumption, the protocol 
stack is not likely to see widespread adoption.  Anything less means 
you're just not efficient enough of with your radio.
> an IP packet?  And the name of that particular link layer?
For 15.4 radios, turning on the radio costs you very roughly 1ms worth 
of equivalent radio on-time.  that translates to 30B worth of 
sending/receiving (250kbps is the most common raw bit rate).
> approach would involve measuring these...
The measurements have been done.  There are lots and lots of papers and 
some datasheets with these measurements for a wide range of platforms.
ksjp
>>>>  to LLNs, some of its mechanisms, such as loop-free tree formation, 
>>>> might be useful in an LLN routing protocol.
>>>
>>> accommodate      several types of failures of the critical messages; 
>>> and rate          limitation such as to avoid too much 
>>> noise.                                                        The 
>>> nodes, relating to energy consumption.  One would think that binding 
>>> an Error Code from the HA meaning 'not enough battery'; or 
>>> similar.      Other possibilities do exist.
>>>

---

From: Kris Pister <[email-masked]>
Date: Tue, 03 Feb 2009 14:11:28 -0800

Alexandru Petrescu wrote:
> think serial rs-232 is ptp.  I think these are potentially used in 
> this space.
I've deployed countless networks with 76.8kbps and 250kbps raw bit rate 
radios.  In both cases, the typical duty cycle on the radio is below 
0.1%, for an effective link data rate of at most a few tens to hundreds 
of bits per second, and latencies of very roughly 1 second per hop.  
These networks contain hundreds of nodes, and are tens of hops across.
You are probably right that traditionally slower links were point-to-point.
Point-to-point links don't deliver the range and reliability required in 
this space, whereas mesh networks do.
Hence the need for routing.
Hence the need for RoLL.
Hence the need to recharter. :)

ksjp

---

From: JP Vasseur <[email-masked]>
Date: Tue, 3 Feb 2009 23:20:21 +0100

Dear all,

Great to see all these discussions, but in light of the discussions  
today I would like to *converge* - I did propose a plan (below). Until  
we have concluded on the protocol survey (we're close) and re- 
chartering (coming soon), can we focus the discussion, it goes in all  
directions.

Many Thanks.

JP.

On Feb 3, 2009, at 6:36 PM, JP Vasseur wrote:

> First of all, I would like to remind that all the routing  
> requirements documents are finalized. I asked for a last revision of  
> the building routing requirements documents before publication  
> request. And then we will be done for this part. Lot of work.
>
> Here is what I propose:
>
> May I ask you to try to limit as much as possible your request and  
> we will do everything possible to address them.
> 6) If/once re-chartered, we count on everybody's help to continue  
> the good work.
>
> Thanks.
>
> JP.
>
>
>> hoc networks with specific requirements and use cases. Some of  
>> those use cases may or may not overlap with ROLL. There will be  
>> lessons to be learned but, the primary use cases being worked on  
>> appeared by all the chairs and ADs involved to be different enough  
>> to warrant a new WG in this area.
>> over IP (some call these  "sensor networks"). ROLL is only  
>> chartered to work on the routing protocol portion. Not the  
>> transport, encap or other topics at this time. Also note that  
>> mobility is not under consideration at this time.
>>
>> that state specific functions, attributes, power/memory envelope  
>> and algorithmic considerations that must be "in the routing  
>> protocol" for these networks. The survey ID (which is of course a  
>> snapshot at one point in time) puts some bounds on mapping the  
>> required functions, attributes and other considerations into  
>> protocols available *today.*
>>
>> Given the real work of designing a protocol hasn't begun by the  
>> ROLL WG participants; holding up the WG to begin taking what they  
>> ease or difficulty of "from scratch" or "modify what we have" can  
>> be made. I expect "wild swings" of the design pattern of the  
>> protocol during the first year of the design effort. I attempted to  
>> make this clear at the mic in Minneapolis that the current  
>> trajectory is very complex problem domain that hasn't born a lot of  
>> fruit but, that in the design phase reducing the complexity must  
>> occur. Members of the WG who have vast experience in these types of  
>> networks and have widely deployed products have stated that the  
>> and tradeoffs and debating the structure of the protocol. Any  
>> protocol reuse, experience, etc will be critical at this point to  
>> make the correct choices and I look to MANET, ROLL, MEXT, 6LOWPAN  
>> and other IETF'ers with routing protocol experience to contribute.  
>> This is an industry important juncture and moving LPLN to IP is a  
>> critical change.
>>
>>> applied or be applicable -- as you seem to suggest in your email.  
>>> I believe that I have stated so repeatedly.
>>>
>>> I submit, however, that as it is currently exposed, ROLL, MANET  
>>> and 6LOW seem to be operating within the same space -- to the  
>>> untrained eye, in exactly the same space. My position is that it  
>>> would be very unfortunate having one WG creating confusion on the  
>>> make sure to clearly spell out suitable perimeter definitions  
>>> prior to, or conjointly with, the first publication cycle. In this  
>>> case, before or with the survey I-D.
>>>
>>> Sincerely,
>>>
>>> Thomas
>>>
>>>
>>>> that have designed and deployed solutions so they not only have  
>>>> an excellent expertise of the requirements but also on solutions,
>>>> scale. I do not think that I have to convince anybody on this  
>>>> list that this is the WRONG approach for a number of reasons. The  
>>>> requirements. And if we can adapt an existing protocol, we are  
>>>> all for it !
>>>> precisely why ROLL has been formed, 4 application-specific  
>>>> routing requirements have been produced (to reduce the scope).  
>>>> Even if at a first sight, it looks very much similar to a MANET  
>>>> issue (and there ARE similarities but also very different  
>>>> requirements), having to deal with a highly static network of  
>>>> hundreds of thousands of battery operated sleeping nodes with 4K  
>>>> of RAM is quite specific. Note that this is not a random example,  
>>>> but an on-going non-IP deployed network.
>>>>
>>>> slowed down dramatically for the last 2 months, thus it is time  
>>>> to close and move on to quickly re-charter and start the protocol  
>>>>> protocols were not designed with these requirements in mind"  
>>>>> seem to confirm this).
>>>>>
>>>>> If what I suggest doesn't make sense at all, then I'd be happy  
>>>>> to have it debunked and, hopefully, through that debunking a  
>>>>> producing "longer than shortest paths" at the benefit of  
>>>>> slightly lower control cost would score better than a protocol  
>>>>> producing "shortest paths" with slightly higher control cost.  
>>>>> This is not hypothetical, btw., there are plenty of studies  
>>>>> observing and reflecting upon this regarding the different MANET  
>>>>> when I say "incomplete" in the above, I simply suggest that  
>>>>> based on what is presented one cannot draw conclusions based on  
>>>>> the evaluation criteria....or, worse, that one draws the wrong  
>>>> to show that existing protocols, with no change, could not be  
>>>> used in LLNs. This has been clarified in the document as your  
>>>> request and it HAD to be clarified.
>>>> You may have large amount of traffic and still require to follow  
>>>> a non-shortest path (constrained based routing). This is detailed  
>>>> in several requirements IDs. Criticality of data is of course

---

From: Kris Pister <[email-masked]>
Date: Tue, 03 Feb 2009 14:20:27 -0800

Alexandru Petrescu wrote:
>> that are of immediate commercial interest. 802.15.4 is a good place 
>> to start as an example.  There are at least a half-dozen different 
>> magnitude.  I'd like to make sure that whichever routing protocol we 
>> use (find? create?  you tell me) that it can make intelligent use of 
>> the DLL.  It's really easy to build a network that runs everything at 
>> 1% duty cycle, but it turns out to give lousy performance in a lot of 
>> the limits of configuration (e.g. I can handle 1 packet/sec right 
>> now, and up to 10 packets/sec if you need me to)
>> fine.  But I'm convinced that the variable power/throughput 
>> capabilities of RoLL DLLs is one of the fundamental differences that 
>> makes routing "interesting" in these networks.
>
> A link with its own routing (isa100.11a) talks to another link with 
> its own other link routing (zigbee) through an IP router.  This 
> wouldn't run any routing protocol, because the link-layer routing is 
> enough.
That would require protocol translation at the router.
6LoWPAN with the mesh under option might be a better example.  Companies 
X, Y, and Z can all build 4944-compliant networks that will form 
multi-hop meshes internally, but present it all as a single IP link.
>
> I'm not sure I understand how variable power/throughput capabilities 
> of RoLL DLLs make IP routing interesting for these networks.
You aren't alone. :)   At this point, if there's group consensus it's 
probably that I'm wrong.
It's incumbent on me to explain why I think that this is true, or to 
learn enough from the group to understand why it's not.  Assuming that 
we recharter, I'll get started on that effort.

ksjp

---

From: JP Vasseur <[email-masked]>
Date: Tue, 3 Feb 2009 23:20:21 +0100

Dear all,

Many Thanks.

JP.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 23:32:28 +0100

Kris Pister a écrit :
>>> excellent questions, Alex.  No doubt there will be many low power
>>> and lossy DLLs for us to route over in the future, but there are
>>> several that are of immediate commercial interest. 802.15.4 is a
>>> good place to start as an example.  There are at least a
>>> half-dozen different deeply-duty-cycled DLLs that have been
>>> demonstrated for 15.4 radios. All of them allow for a tradeoff
>>> between power consumption and useful bandwidth, typically over a
>>> range of at least three orders of magnitude.  I'd like to make
>>> sure that whichever routing protocol we use (find? create?  you
>>> tell me) that it can make intelligent use of the DLL.  It's
>>> really easy to build a network that runs everything at 1% duty
>>> cycle, but it turns out to give lousy performance in a lot of 
>>>  protocol that has some mechanism to 1) be aware of the currently
>>> configured capabilities of the DLL , and the limits of
>>> configuration (e.g. I can handle 1 packet/sec right now, and up
>>> to 10 packets/sec if you need me to) 2) be able to configure
>>> those capabilities based on the routing decisions
>>> 
>>> I'm not hung up on this being in the routing protocol itself.  If
>>> you tell me that the right way to do it is through some other
>>> existing xyz-TE protocol that is independent of the routing
>>> protocol, that's fine.  But I'm convinced that the variable
>>> power/throughput capabilities of RoLL DLLs is one of the
>>> fundamental differences that makes routing "interesting" in these
>>> networks.
>> 
>> wouldn't run any routing protocol, because the link-layer routing
>> is enough.
> 

No it wouldn't require translation, it would simply be an IP router with
two different interfaces, a routing table and a search algorithm.  The
effort would be in spec'ing and porting IP over foo.  And if foo already 
specifies a 802.3 MAC interface then IP over foo is straightforward.

> 6LoWPAN with the mesh under option might be a better example.
> Companies X, Y, and Z can all build 4944-compliant networks that will
> form multi-hop meshes internally, but present it all as a single IP
> link.

I think this is pertinent.  I think these kinds of networks wouldn't 
require complex IP routing.

>> I'm not sure I understand how variable power/throughput
>> capabilities of RoLL DLLs make IP routing interesting for these
>> networks.
 >
>  probably that I'm wrong. It's incumbent on me to explain why I think
> that this is true, or to learn enough from the group to understand
> why it's not.  Assuming that we recharter, I'll get started on that
> effort.

Ok that.

Alex

---

From: JP Vasseur <[email-masked]>
Date: Tue, 3 Feb 2009 23:35:44 +0100

I would have a lot to comment also here ;-) but I'll restrain myself  
until we get a close on the other aspects. More later ...

On Feb 3, 2009, at 11:32 PM, Alexandru Petrescu wrote:

> effort would be in spec'ing and porting IP over foo.  And if foo  
> already specifies a 802.3 MAC interface then IP over foo is  
> straightforward.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 23:36:51 +0100

> These networks contain hundreds of nodes, and are tens of hops across.

Is each hop-to-hop link a ptp link?  I believe so:

node<---ptplink---->node<----ptplink---->...
         76kbps               76kbps

I don't see any problem running ND on each ptplink, no risk of message 
storm.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2009 23:41:20 +0100

JP Vasseur a écrit :
> we have concluded on the protocol survey (we're close) and re-chartering 
> (coming soon), can we focus the discussion, it goes in all directions.

I agree, I'm waiting for comments from protocols-survey draft Authors 
about how should I improve the suggested NEMO-related text.

http://www.ietf.org/mail-archive/web/roll/current/msg00847.html

Alex

>> gathering from many participants, this is a good sign 
>> of strong participation for the next phase, a key of success.
>>
>> *3) Still there are a few requests that have been made by Thomas, 
>> Alex, ... that we should try to address.*
>>> the chairs and ADs involved to be different enough to warrant a new 
>>> WG in this area.
>>> widely deployed products have stated that the routing protocol issues 
>>> are solvable problems with some simplifying assumptions. I look 
>>> forward to the WG making these design decisions and tradeoffs and 
>>> debating the structure of the protocol. Any protocol reuse, 
>>>>>> confess) the various requirements documents  of the 
>>>>> 6lowpan WG item *by consensus*. We're are working together and 
>>>>> may have large amount of traffic and still require to follow a

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 3 Feb 2009 14:48:00 -0800

On Feb 3, 2009, at 2:36 PM, Alexandru Petrescu wrote:
>>> I think the slower the link, and the higher latency,  the more  
>>> chances are it's a ptp link.  I think some Bluetooth serial links  
>>> are ptp.  I think serial rs-232 is ptp.  I think these are  
>>> potentially used in this space.
> >
>> I've deployed countless networks with 76.8kbps and 250kbps raw bit  
>> rate radios.  In both cases, the typical duty cycle on the radio is  
>> below 0.1%, for an effective link data rate of at most a few tens  
>> to hundreds of bits per second, and latencies of very roughly 1  
>> second per hop.  These networks contain hundreds of nodes, and are  
>> tens of hops across.
>

I don't believe so... the link is both unicast- and broadcast- capable  
- the latter may reach > 1 node (possibly hundreds) with just a single  
transmission.

--
Jonathan Hui

> I don't see any problem running ND on each ptplink, no risk of  
> message storm.
>
> Alex
>
>
>
>> Point-to-point links don't deliver the range and reliability  
>> required in this space, whereas mesh networks do.
>>>> On Tue, Feb 3, 2009 at 12:54 PM, Alexandru Petrescu <[email-masked] 
>>>> Which link sorry?  Which is the link at 900Mhz over which ND  
>>>> would behave such badly?  What's its bandwidth?  Is it a ptp or  
>>>> shared
>>>> link?
>>>>
>>>>
>>>> in 500ms, even if randomly spaced: some times there would be 2 or  
>>>> 3 simultaneous messages, maybe not very stormy.
>>>>
>>>> point-to-point?  I think it's very probably that a link with  
>>>> 75kbps bandwidth be point-to-point.  In this case the nodes are  
>>>> neighbors 1-by-1, and thus no implosion (or message 'storm')  
>>>> danger.
>>>>
>>>>
>>>> I'm using ND and link types as an opportunity to try to describe  
>>>> the addressing architecture and the subnet structure.  These are  
>>>> typical for MANET discussion and often helpful to identify what  
>>>> can be done at IP level and what below.
>>>>
>>>> Alex
>>>>
>>>>
>>>

---

From: Tim Winter <[email-masked]>
Date: Tue, 03 Feb 2009 18:06:55 -0500

I also agree with and reiterate Anand's comments.

-Tim

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Feb 2009 00:46:07 +0100

Jonathan Hui a écrit :
>>> below 0.1%, for an effective link data rate of at most a few tens to 
>>> hundreds of bits per second, and latencies of very roughly 1 second 
>>> per hop.  These networks contain hundreds of nodes, and are tens of 
>>> hops across.
>>
> I don't believe so... the link is both unicast- and broadcast- capable - 
> the latter may reach > 1 node (possibly hundreds) with just a single 
> transmission.

Is the broadcast capability a link-layer capability or an IP-layer 
capability?  Maybe IP sees it as a ptp link despite its physical 
broadcast nature?

A difficult subnet structure may mean ND problems.  A routing protocol 
could address them, but a better subnet structure is quicker to plan.

Alex

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 3 Feb 2009 10:05:09 -0800

Dave,

This is a great e-mail.  One of the things I especially like about it is
that it touches on the cultural aspects of how the IETF does its work,
viz, we have  an iterative engineering approach in which things do not
have to be perfect before proceeding.  This discussion has been
interminable.

Thanks,

John  

>From: David Ward [mailto:[email-masked]] 
>Sent: Tuesday, February 03, 2009 8:52 AM
>To: ROLL WG
>Cc: Arsalan Tavakoli; Geoff Mulligan; David E. Culler; 
>[email-masked]; [email-masked]; Thomas Heide 
>Clausen; Jari Arkko; Ross Callon
>Subject: Re: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? 
>Re: Review andcomments draft-ietf-roll-protocols-survey-05.txt
>
>All -
>
>We debated the delta between these three WGs when chartering 
>ROLL for a considerable period of time. I do not want to 
>revisit that debate but, I will quickly summarize here
>
>- 6LOWPAN is not working at the IP layer so, the overlap here 
>is really not an issue.
>- MANET is and has been working on routing protocols for 
>mobile, ad hoc networks with specific requirements and use 
>cases. Some of those use cases may or may not overlap with 
>ROLL. There will be lessons to be learned but, the primary use 
>cases being worked on appeared by all the chairs and ADs 
>involved to be different enough to warrant a new WG in this area.
>evaluate existing protocols for low power, lossy networks 
>running over IP (some call these  "sensor networks"). ROLL is 
>only chartered to work on the routing protocol portion. Not 
>the transport, encap or other topics at this time. Also note 
>that mobility is not under consideration at this time.
>
>ROLL WG appears to have come to consensus on the requirement 
>docs that state specific functions, attributes, power/memory 
>envelope and algorithmic considerations that must be "in the 
>routing protocol" for these networks. The survey ID (which is 
>of course a snapshot at one point in time) puts some bounds on 
>mapping the required functions, attributes and other 
>considerations into protocols available *today.*
>
>Given the real work of designing a protocol hasn't begun by 
>the ROLL WG participants; holding up the WG to begin taking 
>what they currently defined as a very complex, multivariate 
>problem and begin whittling it down to something solvable via 
>theoretical and hypothetical exercises seems like an unwise 
>use of time given the experience and energy of the WG in this 
>problem space.  The WG must move beyond the moderately 
>consensus) and move onto the more challenging work of defining 
>the objects, algorithms, semantics, state machines and 
>functionality of the protocol.  In the design phase (vs the 
>survey phase) a better evaluation can be made of the ease or 
>difficulty of "from scratch" or "modify what we have" can be 
>made. I expect "wild swings" of the design pattern of the 
>protocol during the first year of the design effort. I 
>attempted to make this clear at the mic in Minneapolis that 
>the current trajectory is very complex problem domain that 
>hasn't born a lot of fruit but, that in the design phase 
>reducing the complexity must occur. Members of the WG who have 
>vast experience in these types of networks and have widely 
>deployed products have stated that the routing protocol issues 
>are solvable problems with some simplifying assumptions. I 
>look forward to the WG making these design decisions and 
>tradeoffs and debating the structure of the protocol. Any 
>protocol reuse, experience, etc will be critical at this point 
>to make the correct choices and I look to MANET, ROLL, MEXT, 
>6LOWPAN and other IETF'ers with routing protocol experience to 
>contribute. This is an industry important juncture and moving 
>LPLN to IP is a critical change.
>
>I am looking to the WG chairs to declare loose consensus on 
>the documents  (when appropriate) so that the rechartering of 
>the WG to enter the design phase can occur. WIthout a doubt, 
>the requirements as-is have defined the boundary of the work 
>effort and I believe it is clear what is the difference 
>between the WGs.
>
>
>HIH
>
>-DWard
>
>
>
>
>	For the record, I am not arguing that MANET protocols 
>should be applied or be applicable -- as you seem to suggest 
>in your email. I believe that I have stated so repeatedly.
>
>	I submit, however, that as it is currently exposed, 
>ROLL, MANET and 6LOW seem to be operating within the same 
>space -- to the untrained eye, in exactly the same space. My 
>position is that it would be very unfortunate having one WG 
>creating confusion on the applicability of the work of itself 
>and of other IETF wg's, by simple omission of suitable 
>perimeter definitions. 
>
>	In that sort of situation, the IETF needs to be extra 
>prudent to make sure to clearly spell out suitable perimeter 
>definitions prior to, or conjointly with, the first 
>publication cycle. In this case, before or with the survey I-D.
>
>	Sincerely,
>
>	Thomas
>
>
>		Two issues are raised here for which we would 
>appreciate ADs' point of view and feed-back from the WG. 
>Please see in line.
>
>
>		Dear Thomas,
>
>		At the risk of repeating myself, I'd like to 
>make a few important statements before *hopefully* come to a 
>closure ;-)
>
>		-> As you know, many of the ROLL WG active 
>participants have been working quite hard to produce a 
>detailed set of requirements, discuss how to proceed on the 
>protocol survey document, and other ID are in the works.
>		-> We managed to get highly experienced 
>contributors in the field that have designed and deployed 
>solutions so they not only have an excellent expertise of the 
>requirements but also on solutions,
>		-> Yes we need to rush out. Why ? Because 
>proprietary or semi-closed non-IP solutions are being deployed 
>at a fairly large scale. I do not think that I have to 
>convince anybody on this list that this is the WRONG approach 
>for a number of reasons. The industry is asking for an IP 
>solution *now*.
>		-> No we do not want to re-invent the wheel 
>(see our presentation at the routing plenary in Chicago). 
>Anything that already exists MUST (rfc2119 ;-)) be used 
>provided that it meets our requirements. And if we can adapt 
>an existing protocol, we are all for it !
>		-> Yes these requirements are quite specifics 
>and this is precisely why ROLL has been formed, 4 
>application-specific routing requirements have been produced 
>(to reduce the scope). Even if at a first sight, it looks very 
>much similar to a MANET issue (and there ARE similarities but 
>also very different requirements), having to deal with a 
>highly static network of hundreds of thousands of battery 
>operated sleeping nodes with 4K of RAM is quite specific. Note 
>that this is not a random example, but an on-going non-IP 
>deployed network.
>
>		And to conclude on this introduction ... after 
>an outstanding progress on the WG during the first 6-8 months, 
>we have been slowed down dramatically for the last 2 months, 
>thus it is time to close and move on to quickly re-charter and 
>start the protocol work (hopefully as light as possible) to 
>see IP-based solution deployed. I know that we are on the same 
>page, we just need to find a good compromise on both "sides".
>
>			I promised a review, and I apologize 
>that I wasn't able to do so before the weekend as originally projected.
>			
>			Other than some typos that Chris and 
>others have pointed out, I'll try to offer my understanding of 
>the problem space and suggest some ways of addressing my main 
>concerns....
>			
>			My first main concern remain that it is 
>not clear, still, how ROLL positions itself with respect to 
>MANET, 6LOW et. al, all of which appear to be within the same 
>space and within the IETF. This I-D sees ROLL as presented 
>with entirely new problems (the use of "novel" in the 
>abstract, the statement that "existing protocols were not 
>			Looking at the  requirements listed, 
>including "low power, low bandwidth, low footprint", these 
>appear similar to those which are also brought forward in e.g. 
>MANET and 6LOW. Reading (quickly, I confess) the various 
>requirements documents  of the draft-ietf-roll series present 
>scenarios which are similar to those where MANETs are 
>			I also note that many additional (and 
>unstated) characteristics between ROLL and e.g. MANET are the 
>same: mobile, wireless, fragility, auto-configuration, IP 
>routing, interface/link issues...
>			
>			Arguing that, as does this I-D, despite 
>the above impression "ROLL is novel and different" invites 
>asking "how, exactly?" I think that this question is valid, 
>and merits being answered, before the evaluations in this I-D 
>can be judged fairly.
>			
>			Note that I come from a MANET 
>background, and so I *could* interpret from the ROLL 
>discussion that where MANETs may aim for "low power, low 
>bandwidth, ....", ROLL may be able to quantify these as "below 
>this firm threshold" -- i.e. as a sort of "extreme" or 
>"constrained" MANET.
>			
>			This is a personal observation, I note, 
>which would allow me to comprehend how ROLL and MANET are 
>positioned relative to one another -- but one which neither 
>this I-D nor the requirements document spell out or quantify 
>-- or, for that matter, debunk.
>			
>			I think it's critical to understand 
>this, in order to understand the need for a new protocol 
>development. I think it is important to document this 
>			If what I suggest above makes sense as 
>a way of positioning ROLL and MANET relative to one another, 
>I'd suggest including something to this effect in the survey 
>I-D, as this I-D is the one making a *direct* reference to the 
>			If what I suggest doesn't make sense at 
>all, then I'd be happy to have it debunked and, hopefully, 
>through that debunking a positioning/description that does 
>ring true with us all can be produced?
>			
>			My second main concern is, that I still 
>think that the choice of criteria is unfortunate (not the 
>word, Phill has me convinced on that front, but the actual 
>criteria). Control cost is, by all means, a rather meaningless 
>criteria when taken in isolation. I've sketched a 
>"zero-control-cost" routing protocol (flood all data - say use 
>SMF, also a MANET protocol, and also a rather "mature" I-D and 
>wg item) which would score well on the control cost criteria, 
>but would likely be an extremely bad choice for delivering 
>unicast data.
>			
>			The metric which matters, and which 
>should matter to ROLL in particular, is "the total cost of 
>getting user data through the network, including control cost 
>necessary to set up paths" -- as we know, every packet sent 
>and received costs bandwidth, energy and cycles -- user data 
>no different from contro.
>			
>			According to the criterions as set up 
>by this I-D, a protocol producing "longer than shortest paths" 
>at the benefit of slightly lower control cost would score 
>better than a protocol producing "shortest paths" with 
>slightly higher control cost. This is not hypothetical, btw., 
>there are plenty of studies observing and reflecting upon this 
>regarding the different MANET protocols, in academic 
>literature -- and observed in real networks as well.
>			
>			I note that this trade-off (slightly 
>longer paths for lower control cost) may be perfectly fair, 
>assuming that very low amounts of user data traffic transit 
>through the network. However, I do not see this assumption 
>mentioned as a justification for focusing on the control cost 
>metric and discarding the "path length" or the "total cost of 
>			I believe that either these assumptions 
>should be made explicit ("there's so little user data traffic 
>in a ROLL network that we do not care about shortest paths") 
>or -- if these assumptions do not hold, that the evaluation 
>criteria are incomplete.
>			
>			I note that it's true that we can 
>always add another criteria ad infinitum, and that's CLEARLY 
>not what we want to do. However when I say "incomplete" in the 
>above, I simply suggest that based on what is presented one 
>cannot draw conclusions based on the evaluation 
>criteria....or, worse, that one draws the wrong conclusions 
>based on the information presented.
>
>
>		It is not easy to answer each of your point 
>without running the risk to start a debate that will never 
>end. You raised some excellent points that I agree with and 
>others that I firmly disagree with ... So let me try to make a 
>few observations:
>		1) As pointed out earlier, yes there are 
>similarities between MANET and ROLL. I do not see this as an issue.
>		2) The aim of the protocol survey IS NOT to 
>exclude MANET protocols. As mentioned many times on the list, 
>we *only* wanted to show that existing protocols, with no 
>change, could not be used in LLNs. This has been clarified in 
>the document as your request and it HAD to be clarified.
>		- Try to derive a subset of necessary but not 
>sufficient criteria, which the WG chose to do (consensus). Yes 
>this list is not perfect,
>		
>		criteria could be changed, removed or added but 
>looked good enough with excellent consensus until LC.
>		
>		4) With regards to 6lowpan (I copy the chair), 
>I do not see any overlap at all. Please refer to their charter 
>and WG items. The only place that required clarification was 
>the routing requirements and I was personally opposed to it 
>but this was adopted as a 6lowpan WG item by consensus. We're 
>are working together and managed to sort this out. This 
>document will be 6lowpan specific.
>
>		What I want to avoid is an endless discussion 
>on the positioning of ROLL, MANET, 6lowpan and quite frankly 
>we could add other WGs to the list.
>
>		We just need to agree on the fact that there is 
>no existing protocol that meets the ROLL requirements and move 
>to the next step (re-chartering) to select one (hopefully not 
>two) routing protocols in light of the routing requirement 
>(NOT the protocol survey), which can either be an adapted 
>MANET protocol or a new protocol.
>
>			So, in a nutshell, I suggest that we 
>address (i) the positioning issue and (ii) the criteria issue thus:
>			
>			have deducted. If my deduction is 
>incorrect, then let's quickly iterate on the list
>			as to understand how to do produce an 
>alternative description. If we can't do this,
>			then the conclusion can be that "we do 
>not know how ROLL and MANET position
>			It *should* not be more than a couple 
>of paragraphs worth of text to add, I gather?
>			
>			
>
>
>		If you find a way to word this, please feel 
>free and I'd be happy to help but feel it as necessary ... Any 
>opinion from our RTG and INT ADs ?
>
>
>			- Add the assumption that "user data 
>traffic is so low that path lengths do not
>		The motivation for selecting a longer path is 
>not tied to the amount of traffic here but the level of 
>constraints. Note that this is also true for several other 
>technologies such as MPLS-TE. You may have large amount of 
>traffic and still require to follow a non-shortest path 
>(constrained based routing). This is detailed in several 
>requirements IDs. Criticality of data is of course different, 
>thus the requirements for potentially different data paths 
>according to packet marking using DSCP.
>
>
>			- Add a criteria & evaluation of "total 
>cost for getting user data through the network"
>			
>			
>
>
>		And we can add many more but if the current 
>protocol do not satisfy existing requirements, isn't it 
>sufficient to answer the question on whether one can find an 
>existing protocol?
>
>
>			This would make a large chunk of my 
>concerns and issues vanish, and allow correctly interpreting 
>and evaluating the rest of the document.
>
>
>		That said, question for the WG. Who think that 
>such criteria should be added to move forward ? Please reply.
>
>
>
>
>				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
>				
>
>				  important.  Wireless link 
>qualities can vary significantly over time,
>				
>
>				  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
>				
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 4 Feb 2009 09:59:22 -0000

> protocol to a specific issue as "this protocol is BAD".

No, that was a hypothetical. The argument I meant was that, whether
or not you wqnt it to, the document has non-ROLL implications. That
would be an example of where they were clearly unacceptable. But as
I later say

>> any X.

Any disagreement is not at that level.

> add 1-2 sentences very explicitly if you will.

It's not to me to address that, but rather where the issues are
coming from. (I haven't followed the details - and there are 30
unread posts after this one - on whether the DYMO comments are
now to everyone's satisfaction.)

> Informational RFC with limited scope (very explicitly pointed out in  

Still an RFC, and a reason why if it comments in an area it needs to
be basically right (some fine details may not be critical). But I'm
not proposing any specific changes for such a reason, though others
may be (or not, I've lost track).

---

From: "Jakob Buron" <[email-masked]>
Date: Wed, 4 Feb 2009 11:14:35 +0100

I completely agree with JPs comments - ROLL needs to move on. The
ongoing discussion of the protocol survey draft is counter-productive,
and I support closing it so we can proceed.
 
/jakob

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of JP Vasseur
	Sent: 3. februar 2009 13:20
	To: ROLL WG; Thomas Heide Clausen; David Ward; Ross Callon;
[email-masked]; [email-masked]
	Cc: Arsalan Tavakoli; Geoff Mulligan; David E. Culler;
[email-masked]
	Subject: [Roll] * ALL PLEASE READ ** TIME FOR CLOSURE ? Re:
Review andcomments draft-ietf-roll-protocols-survey-05.txt

	Dear WG and ADs,

	Dear Thomas, 

	At the risk of repeating myself, I'd like to make a few
important statements before *hopefully* come to a closure ;-)

	-> As you know, many of the ROLL WG active participants have
been working quite hard to produce a detailed set of requirements,
discuss how to proceed on the protocol survey document, and other ID are
in the works.
	-> We managed to get highly experienced contributors in the
field that have designed and deployed solutions so they not only have an
excellent expertise of the requirements but also on solutions,
	-> Yes we need to rush out. Why ? Because proprietary or
semi-closed non-IP solutions are being deployed at a fairly large scale.
I do not think that I have to convince anybody on this list that this is
the WRONG approach for a number of reasons. The industry is asking for
an IP solution *now*.
	-> No we do not want to re-invent the wheel (see our
presentation at the routing plenary in Chicago). Anything that already
exists MUST (rfc2119 ;-)) be used provided that it meets our
requirements. And if we can adapt an existing protocol, we are all for
it !
	-> Yes these requirements are quite specifics and this is
precisely why ROLL has been formed, 4 application-specific routing
requirements have been produced (to reduce the scope). Even if at a
first sight, it looks very much similar to a MANET issue (and there ARE
similarities but also very different requirements), having to deal with
a highly static network of hundreds of thousands of battery operated
sleeping nodes with 4K of RAM is quite specific. Note that this is not a
random example, but an on-going non-IP deployed network.

	And to conclude on this introduction ... after an outstanding
progress on the WG during the first 6-8 months, we have been slowed down
dramatically for the last 2 months, thus it is time to close and move on
to quickly re-charter and start the protocol work (hopefully as light as
possible) to see IP-based solution deployed. I know that we are on the
same page, we just need to find a good compromise on both "sides".

	Nothing new so far, let's move to a proposed resolution - See in
line, 
	
	[...]

---

From: Miguel Sánchez <[email-masked]>
Date: Wed, 4 Feb 2009 12:20:08 +0100

Hi all,

The survey can be improved, but it's good enough for me. So my vote is to
close it now.

Cheers,

Miguel Sánchez

On Tue, Feb 3, 2009 at 11:20 PM, JP Vasseur <[email-masked]> wrote:

> Dear all,
> Great to see all these discussions, but in light of the discussions today I
> would like to *converge* - I did propose a plan (below). Until we have
> concluded on the protocol survey (we're close) and re-chartering (coming
> soon), can we focus the discussion, it goes in all directions.
>
> Many Thanks.
>
> JP.
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 4 Feb 2009 15:59:36 +0100

Hi Alex:

I expect that peer discovery won't be very different from current ND or hello. So there's no ruling ND out of the story. 

What is new is a node density factor that we will have to address. For instance, Trickle is discussed at 6LoWPAN for that exact reason. Power Control / management is also critical for that matter.

AFAIK, 6LoWPAN proposes a ND model that can be extended the way MANEMO extended traditional ND so it can be considered in the solution space... once we recharter. 

Pascal

>From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>Sent: mercredi 4 février 2009 00:46
>To: Jonathan Hui
>Cc: ROLL WG
>Subject: Re: [Roll] Review and comments Re:I-D ACTION:draft-ietf-roll-protocols-survey-05.txt
>
>Jonathan Hui a écrit :
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Feb 2009 16:17:03 +0100

Hi Pascal,

Pascal Thubert (pthubert) a écrit :
> Hi Alex:
> 
> I expect that peer discovery won't be very different from current ND
>  or hello. So there's no ruling ND out of the story.

I'd be more reassured of explicitely stating ND is not ruled out from
the ROLL space.

Some text in protocols-survey draft seems to rule it out.

In a constrained device the designer is tempted to strip out some
protocols.  If we list the protocols we asumme implemented I think we'll
have many surprising disagreements.

> What is new is a node density factor that we will have to address. 
> For instance, Trickle is discussed at 6LoWPAN for that exact reason.

Sorry, Trickle being?  A protocol?  A product?  Doesn't figure in
6LoWPAN documents...

You mean the node density is very high as compared to something?  (or
very low?).

> Power Control / management is also critical for that matter.
> 
> AFAIK, 6LoWPAN proposes a ND model that can be extended the way 
> MANEMO extended traditional ND

Thanks for pointing this out!  Indeed I find indeed the 6LoWPAN Prefix 
Information Option in the RA (draft-ietf-6lowpan-nd-00.txt) to be akin 
to some of the MANEMO work (MANEMO was an earlier pre-BoF-never-BoF for 
MANET and NEMO).

Do you think I should propose the MANEMO personal proposal for prefix in 
RA to 6LoWPAN?  To ROLL?  To AUTOCONF?

Alex

>> so it can be considered in the solution space... once we recharter.

---

From: Zachary Smith <[email-masked]>
Date: Wed, 4 Feb 2009 08:14:45 -0800

Hey all,

If one more voice will make a difference here, it seems clear that -  
as always happens with these things - as the race gets closer to the  
finish line the atmosphere gets more.... well... I guess "animated"  
would be an appropriately neutral word. This is fine, of course, and  
to be expected but it is also clear that all of this discussion can be  
continued in the context of a re-chartered ROLL with a mandate to  
actually make routing protocol choices.

Now, my personal opinion, based on direct experience is that one all- 
singing-all-dancing routing protocol will not be sufficient to satisfy  
the requirements as currently constituted. The experience of the  
ZigBee WGs (I know, I know, ZigBee isn't IP and so on but the  
underlying problem is roughly the same) was that it really took a  
small suite of integrated protocols to satisfy, in particular, the low- 
latency requirements inherent in certain applications (e.g. building  
control) and the scaling requirements inherent in certain others (e.g.  
condition-based maintenance for large C&I facilities).

Personal opinions aside, though, the only way to get to the point  
where we can actually have this discussion in a context where the  
results of the discussion are consequential, is to close the current  
phase and move on to the next.

   z

On Feb 3, 2009, at 2:20 PM, JP Vasseur wrote:

> today I would like to *converge* -

Zachary Smith - CTO
http://www.daintree.net/

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 4 Feb 2009 08:20:10 -0800

> Sorry, Trickle being?  A protocol?  A product?  Doesn't figure in

Try the 6LoWPAN WG ML:
http://www.ietf.org/mail-archive/web/6lowpan/current/msg01266.html

To those of us in the sensornet community, Trickle is widely used in  
many applications at all layers of the stack. It's a pretty  
fundamental primitive for building robust protocols.

--
Jonathan Hui

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Feb 2009 17:35:17 +0100

Jonathan Hui a écrit :
> many applications at all layers of the stack. It's a pretty fundamental 
> primitive for building robust protocols.

Funny - that single CACM issue is eternally unread on my desk, and I get 
drawn by the IETF documents instead...

Alex

---

From: Philip Levis <[email-masked]>
Date: Wed, 4 Feb 2009 09:00:02 -0800

Comments follow.

On Feb 3, 2009, at 12:33 PM, Alexandru Petrescu wrote:

>> protocol.  It does not examine hierarchical NEMO [I-D.thubert-tree- 
>> discovery] as a candidate because it only maintains
> it	
> accommodate	

Suddenly the NEMO section is longer than all of the other ones, even  
though it's not being considered in the table! Why is a lengthy  
restatement of NEMO's capabilities relevant to the purpose and intent  
of the document?

The document has a single and solitary purpose: to determine whether  
an existing IETF routing protocol can meet the requirements of LLN  
applications. It can't even answer "yes," as that would require a  
detailed examination of application drafts. It can only answer "maybe"  
or "no."

Any content added to the document outside this purpose dilutes its  
point and will make our job harder down the line. Adding words is  
easy; removing them is hard. We don't want the draft to be like a  
piece of U.S. legislation, where there are lots of ancillary "riders"  
that append sometimes completely orthogonal content to the main  
document. If NEMO suddenly receives a very long section, then future  
readers may wonder whether the document was implicitly promoting  
NEMO's mechanisms as a starting point.

The statement that "NEMO is not a routing protocol" is, as I've said  
before, based on the fact that you can't use NEMO alone. NEMO allows  
nodes to route in a mobile setting by *tunneling over an existing  
routing infrastructure.* The fact that it advertises prefixes and  
modifies routing tables does not make it a routing protocol in the  
context of ROLL and this draft. Otherwise, DHCP is one too. Debating  
"what is a routing protocol" in the general sense isn't particularly  
helpful. But in the context of this draft, based on the application  
requirements, that seems pretty clear. It's something that, starting  
with link layer connectivity to other IP nodes, lets you send a packet  
over multiple hops to a destination based on an IP address.

I think we've lost track of the real reason for NEMO's exclusion.  
Would you agree with changing 3.1 to:

"This document does not examine the Network Mobility Basic Support
Protocol (NEMO <xref target="RFC3963">RFC 3963</xref>) because
it requires an underlying IP routing protocol over which to
tunnel. It does not examine hierarchical
NEMO <xref target="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."

Then, in Section 9, Conclusion, change from

"Figure 1 shows that no existing IETF protocol specification meets the
criteria described in Section 4.  Therefore, having a routing
protocol for LLNs requires new protocol specification documents.
Whether such documents describe modifications to existing protocols
or new protocols it outside the scope of this document and warrants
further discussion.  However, the results in Figure 1 may provide
some insight or guidance in such a discusssion, indicating what
protocol mechanisms may be better suited to LLNs than others."

to

"Figure 1 shows that no existing IETF protocol specification meets the
criteria described in Section 4.  Therefore, having a routing
protocol for LLNs requires new protocol specification documents.
Whether such documents describe modifications to existing protocols
or new protocols it outside the scope of this document and warrants
further discussion.  However, the results in Figure 1 may provide
some insight or guidance in such a discusssion, indicating what
protocol mechanisms may be better suited to LLNs than others."

"Such a discussion should not, however, be limited to the protocols
listed in Figure 1. As discussed in Section 3.1, there are several
existing protocols, such as NEMO<cite> and hierarchical NEMO<cite>,
which are unsuitable as a general routing protocol but describe
mechanisms that could be very useful in the context of LLNs. Any
such future discussion ought to consider how routing in LLNs may
benefit from borrowing mechanisms from a broader suite of protocols
than those listed in Figure 1."

Thoughts?

Phil

---

From: Ian Chakeres <[email-masked]>
Date: Wed, 4 Feb 2009 13:11:23 -0500

Please also include the comments that I have reiterated through the
last few protocol-survey updates.
Thanks & I look forward to seeing the next rev.
Ian Chakeres

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Feb 2009 19:23:19 +0100

Philip, thanks for the reply.

[...]
>  though it's not being considered in the table!

How many lines would one suggest?  Would 30 lines cut it?  I can do, 
just let me know.

The suggested NEMO text is 56 lines.  The other similar sections are:
OSPF/ISIS 22 lines, OLSR 34 lines, etc.

If we don't converge, I'm also ok to put this as an Appendix section.

[...]
> context of ROLL and this draft.

I don't agree.  I think commonly agreeing what a 'Routing Protocol in 
ROLL context' is would make a lot of sense, discussing it.

> Otherwise, DHCP is one too.

Thanks for mentioning it!

I think DHCP should be mentioned too in protocols-survey.  The DHCP
Server and Relay often modify the routing tables and they go hand in
hand with address autoconfiguration needs.  I think ROLL nodes are 
supposed to auto-configure somehow, thus DHCP is very pertinent.

> Debating "what is a routing protocol" in the general sense isn't 
> particularly helpful.

I think we could very well debate what is a routing protocol, discussion.

> But in the context of this draft, based on the application 
> requirements, that seems pretty clear.

It's not clear at all.  What are the applications?  Are _all_ typical
TCP/UDP/HTTP applications considered by ROLL?  Or only some of them?  In
such a constrained environment one would strip some protocols from the 
stack - for example MLD - an otherwise integral part of an IPv6 stack 
(informational requirements for IPv6 nodes are in RFC4294).

But if one strips MLD away then ND may work less efficiently.  If ND is 
less efficient then OSPF may be less efficient.  And so on.

> It's something that, starting with link layer connectivity to other 
> IP nodes, lets you send a packet over multiple hops to a destination 
> based on an IP address.

I think it's way too vague... how about static routes - they're induced 
by humans not protocols.  Or routes induced by ICMP Redirect messages - 
is ICMP a routing protocol?

> Protocol (NEMO <xref target="RFC3963">RFC 3963</xref>) because it 
> requires an underlying IP routing protocol over which to tunnel. It

No I don't agree.  NEMO MR and HA tunnel ok over networks that don't 
require an IP routing protocol, networks using static IP routes.  It 
also works ok when MR and HA are neighbors, linked by a single link.

> does not examine hierarchical NEMO <xref 
> target="I-D.thubert-tree-discovery"/> as a candidate because it only
> routing.

What is 'hierarchical' NEMO?

More complete would be to cite an RFC overviewing several NEMO RO 
competing proposals rather than a personal proposal.  I mean use RFC4889 
"NEMO RO Space Analysis" instead of thubert-tree-discovery which is but 
one technique for NEMO RO.

What is '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."
> 
> "Figure 1 shows that no existing IETF protocol specification meets 
> the criteria described in Section 4.  Therefore, having a routing 
> "Figure 1 shows that no existing IETF protocol specification meets 
> the criteria described in Section 4.  Therefore, having a routing 
> mechanisms that could be very useful in the context of LLNs. Any such
>  future discussion ought to consider how routing in LLNs may benefit
>  from borrowing mechanisms from a broader suite of protocols than 
> those listed in Figure 1."

In principle this extended conclusion sounds better to me.  But again, I
don't understand "hierarchical NEMO".  There's an RFC4885 "Network
Mobility Support Terminology." if you wish to consider or me to describe.

And also I don't understand 'general routing protocol'.

Maybe citing DHCP in this paragraph as well.

Alex

---

From: JP Vasseur <[email-masked]>
Date: Wed, 4 Feb 2009 19:53:22 +0100

Alex,

Please hold-on, we are trying to satisfy your request as much as  
possible but this becomes a "bit" unreasonable.
We tried to provide you a lot of information on ROLL and non-ROLL  
issue, this is fine. Remember we are not writing a tutorial or a book  
on LLNs here.

Now you ask for adding DHCP in the survey.

You also ask to look at applications: PLEASE read the 4 application- 
specific requirement documents then.

and transport protocols (out of our charter).

On the discussion on what is a routing protocol, sorry but it does not  
belong to this list. Let's say a bit focussed.

Phil made a very reasonable suggestion. Please consider it carefully  
and we will make a final attempt.

Thanks.

JP.

On Feb 4, 2009, at 7:23 PM, Alexandru Petrescu wrote:

> I don't agree.  I think commonly agreeing what a 'Routing Protocol  
> in ROLL context' is would make a lot of sense, discussing it.
>
> such a constrained environment one would strip some protocols from  
> the stack - for example MLD - an otherwise integral part of an IPv6  
> stack (informational requirements for IPv6 nodes are in RFC4294).
>
> But if one strips MLD away then ND may work less efficiently.  If ND  
> is less efficient then OSPF may be less efficient.  And so on.
>
>> IP nodes, lets you send a packet over multiple hops to a  
>> destination based on an IP address.
>
> I think it's way too vague... how about static routes - they're  
> induced by humans not protocols.  Or routes induced by ICMP Redirect  
> messages - is ICMP a routing protocol?
>
>> does not examine hierarchical NEMO <xref target="I-D.thubert-tree- 
>> discovery"/> as a candidate because it only
> competing proposals rather than a personal proposal.  I mean use  
> RFC4889 "NEMO RO Space Analysis" instead of thubert-tree-discovery  
> which is but one technique for NEMO RO.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Feb 2009 21:06:46 +0100

JP,

I consider carefully my reply to Philip.

I offered to maybe make the NEMO text an Appendix, or maybe write it in 
a limited number of lines, you decide the number.

I strongly disagree to cite a personal proposal (RRH) when an RFC agreed 
by a WG is more appropriate (RFC4889).  Do you think this is unreasonable?

'NEMO vs routing protocols': we seem to have strong disagreements - are 
they, aren't they.  Two sections in 2 RFCs [x] detail interactions of 
NEMO protocol with dynamic routing protocols.  These sections are there 
because WGs and IESG asked for them.  They could be cited as well... so 
different than saying NEMO is not a routing protocol, or NEMO requires 
an existing routing protocol...

Finally - DHCP is pertinent to mention for ROLL, and ICMP Redirect too, 
maybe in the Conclusions section, like "we don't rule out DHCP nor ICMP 
Redirect".

I carefully consider the discussions.

Alex
[x]: section 8 of rfc3963 and section section 9 of rfc5177

JP Vasseur a écrit :
> We tried to provide you a lot of information on ROLL and non-ROLL issue, 
> this is fine. Remember we are not writing a tutorial or a book on LLNs 
> here.
> 
> You also ask to look at applications: PLEASE read the 4 
> application-specific requirement documents then.
> 
> Phil made a very reasonable suggestion. Please consider it carefully and 
> we will make a final attempt.
> 
> Thanks.
> 
> JP.
>

---

From: "David E. Culler" <[email-masked]>
Date: Wed, 04 Feb 2009 12:36:14 -0800

Perhaps we could apply a simple rule like the following:

Routing?
  layer 7: NO
  layer 3: YES
  layer 2: NO

Alexandru Petrescu wrote:
> I offered to maybe make the NEMO text an Appendix, or maybe write it 
> in a limited number of lines, you decide the number.
>
> I strongly disagree to cite a personal proposal (RRH) when an RFC 
> agreed by a WG is more appropriate (RFC4889).  Do you think this is 
> unreasonable?
>
> 'NEMO vs routing protocols': we seem to have strong disagreements - 
> are they, aren't they.  Two sections in 2 RFCs [x] detail interactions 
> of NEMO protocol with dynamic routing protocols.  These sections are 
> there because WGs and IESG asked for them.  They could be cited as 
> well... so different than saying NEMO is not a routing protocol, or 
> NEMO requires an existing routing protocol...
>
> Finally - DHCP is pertinent to mention for ROLL, and ICMP Redirect 
> too, maybe in the Conclusions section, like "we don't rule out DHCP 
> nor ICMP Redirect".
>
>> On the discussion on what is a routing protocol, sorry but it does 
>> not belong to this list. Let's say a bit focussed.
>>

---

From: Philip Levis <[email-masked]>
Date: Wed, 4 Feb 2009 12:55:23 -0800

> in a limited number of lines, you decide the number.

Why should NEMO have an Appendix? Appendix A is for the analysis  
behind Table 1. That is why the mechanisms of these protocols are  
mentioned; they give the reader an understanding of where the analysis  
comes from. Appendix B is to explain the reason for a log factor. Why  
should the document have a restatement of factual information that is  
not relevant to its purpose and is in another document? That is  
exactly what a citation is for.

This draft is *not* a place to advertise the features and capabilities  
of some IETF protocols but not others. Otherwise, it has started down  
the path of suggesting paths post re-chartering, something it is  
explicitly not supposed to do, and is playing favorites. It would then  
require a statement of many possible mechanisms ROLL might draw from,  
a task which should occur *after* rechartering, not before.

The reason why NEMO *is* mentioned specially is because its  
examination is part of the current ROLL charter. We want to perform  
due diligence and cover it, even though in retrospect it is very far  
afield and not suitable for inclusion in Figure 1.

> agreed by a WG is more appropriate (RFC4889).  Do you think this is  

The reason is that the tree formation in the personal proposal has  
some similarities to what many LLN networks today do. Please refer to  
this very limited subset of documents:

http://www.dustnetworks.com/technology/tsmp.shtml
http://www.sensicast.com/mesh_nodes.php
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.1.5480
http://portal.acm.org/citation.cfm?id=1460415
http://sing.stanford.edu/pubs/hotnets07-4b.pdf
http://dcg.ethz.ch/publications/ipsn2007.pdf
http://www.tinyos.net/tinyos-2.x/doc/txt/tep123.txt
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4147030
http://www.cs.berkeley.edu/~jwhui/pubs/jhui-ic-6lowpan.pdf

> are they, aren't they.  Two sections in 2 RFCs [x] detail  
> interactions of NEMO protocol with dynamic routing protocols.  These  
> sections are there because WGs and IESG asked for them.  They could  
> be cited as well... so different than saying NEMO is not a routing  
> protocol, or NEMO requires an existing routing protocol...

I'll be honest here; we might disagree, but that disagreement seems to  
be based on a lack of understanding on your part on LLNs, wireless,  
and ROLL networks. I think folks in ROLL, including long-term IETFers,  
industry representatives, and protocol designers, are happy to help  
dispel this confusion, that doesn't mean all of this information  
should be pushed into the first draft that led to your confusion.

Furthermore, your statement is misleading. It says that those RFCs  
detail interactions of NEMO with dynamic routing protocols. This is  
true. They do so in the context of *NEMO can work on top of dynamic  
protocols.* For example, RFC 5119, Section 9:

"There are several benefits of running a dynamic routing protocol
    between the Mobile Router and the Home Agent.  If the Mobile Network
    is relatively large, including several wireless subnets, then the
    topology changes within the moving network can be exposed from the
    Mobile Router to the Home Agent by using a dynamic routing protocol.
    The purpose of the NEMOv4 protocol extensions to Mobile IPv4, as
    defined in previous sections, is not to inform the Home Agent about
    these topology changes, but to manage the mobility of the Mobile
    Router."

That is, this paragraph is clearly stating that a routing protocol  
sits underneath NEMO!

RFC 3963, section 3:

"When a Correspondent Node sends a data packet to a node in the Mobile
    Network, the packet is routed to the Home Agent that currently has
    the binding for the Mobile Router. "

"When the Home Agent receives a data packet meant for a node in the  
Mobile
    Network, it tunnels the packet to the Mobile Router's current Care- 
of
    Address"

"The Mobile Router decapsulates the packet and forwards it
    onto the interface where the Mobile Network is connected."

The debate of "what is a routing protocol" is irrelevant. In the  
context of ROLL, the requirements are clear. Starting with wireless  
link-layer connectivity that is lossy, low power, and dynamic, LLNs  
need a protocol that enables them to deliver packets to nodes that are  
more than one hop away. From the above descriptions, NEMO does not fit  
this scenario, unless you assume that the correspondent node is a  
single hop from the Home Agent, the Home Agent is a single hop from  
the Care-of-Address, and the Care-of-Address is a single hop from the  
Mobile Router. Or am I mistaken?

Phil

---

From: Philip Levis <[email-masked]>
Date: Wed, 4 Feb 2009 12:56:31 -0800

> Thanks & I look forward to seeing the next rev.

Will do.

Phil

---

From: "David E. Culler" <[email-masked]>
Date: Wed, 04 Feb 2009 13:46:11 -0800

I agree.  KISS. 

Plenty of time and venue to expand in later work. 

Philip Levis wrote:
>    Network, it tunnels the packet to the Mobile Router's current Care-of
>    Address"
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Feb 2009 23:24:33 +0100

Philip Levis a écrit :
>> I offered to maybe make the NEMO text an Appendix, or maybe write 
>> it in a limited number of lines, you decide the number.
> 
> mentioned; they give the reader an understanding of where the 
> analysis comes from. Appendix B is to explain the reason for a log 
> factor. Why should the document have a restatement of factual 
> information that is not relevant to its purpose and is in another 
> document? That is exactly what a citation is for.

You seem to disagree making it an Appendix, but agree making good citations.

Would one thus agree to: "with respect to NEMO and routing protocols
please refer to sections 8 and 9 of rfc3963 and rfc5177 respectively"
and remove the parts we disagree? (remove "NEMO is not a" and "NEMO
requires a").

It would substantially reduce the line number too.

> This draft is *not* a place to advertise the features and 
> capabilities of some IETF protocols but not others.
> 
> Otherwise, it has started down the path of suggesting paths post 
> re-chartering, something it is explicitly not supposed to do, and is 
> playing favorites. It would then require a statement of many possible
> mechanisms ROLL might draw from, a task which should occur *after*
> rechartering, not before.

Ok.

> some similarities to what many LLN networks today do.

I still suggest two things: the RFC4889 is a good survey of NEMO RO
techniques, all build on trees in their respective sense, worth citing.

The lack of non-default routes of tree-discovery draft can be addressed
by another personal proposal draft-petrescu-manemo-nano-00 (it runs on
flat subnets, and employs specific routes) - both are ND extensions.

(and Pascal sorry, yes, I wrongly took RRH draft for tree-discovery
  draft).

> Please refer to this very limited subset of documents:
> 

Ok, thanks, I set it aside for my biblio one day.

>>  sections are there because WGs and IESG asked for them.  They 
>> could be cited as well... so different than saying NEMO is not a 
>> routing protocol, or NEMO requires an existing routing protocol...
> 
> I'll be honest here; we might disagree, but that disagreement seems 
> to be based on a lack of understanding on your part on LLNs, 
> wireless, and ROLL networks.

Ok.

> I think folks in ROLL, including long-term IETFers, industry 
> representatives, and protocol designers, are happy to help dispel 
> this confusion, that doesn't mean all of this information should be 
> pushed into the first draft that led to your confusion.
> 
> protocols.*

Well no.  They work together, there's no top-bottom.  NEMO affects the
same routing table affected by say OSPF.  Each could function without
the other, less synch headaches.

> That is, this paragraph is clearly stating that a routing protocol 

Sorry if that paragraph makes think so!  It should have explicitely said
that exposition happens as "OSPF messages are encapuslated in the tunnel
established by Mobile IPv6, when MR not at home".

WOuld this clarify it's not an underneath/above relationship?

MAybe an errata is necessary to that RFC, thanks for pointing it out.

> RFC 3963, section 3:
> 
> "When a Correspondent Node sends a data packet to a node in the 
> Mobile Network, the packet is routed to the Home Agent that currently
>  has the binding for the Mobile Router. "

YEs, routed, as in 'forwarded', or 'passed along'.  Could be via static
routes, not necessarily routes set by a dynamic rt protocol.

> Mobile Network, it tunnels the packet to the Mobile Router's current 
> Care-of Address"

Yes, I think this does not bring confusion about routing protocol.

> "The Mobile Router decapsulates the packet and forwards it onto the 
> interface where the Mobile Network is connected."

YEs same.

> need a protocol that enables them to deliver packets to nodes that 
> are more than one hop away.
> 
> From the above descriptions, NEMO does not fit this scenario, unless
>  you assume that the correspondent node is a single hop from the Home
>  Agent, the Home Agent is a single hop from the Care-of-Address, and
>  the Care-of-Address is a single hop from the Mobile Router. Or am I
>  mistaken?

I think the NEMO protocol extensions could qualify to an IP topology I
think you think, especially if connected to the Internet.

It depends if 'more than one hop away' means 'decrementing the hopcount'
or means 'bridged'.

This begs for illustration about what a ROLL topology looks like, where
are the subnets and how is the subnet addresing architecture.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Feb 2009 23:35:04 +0100

> Perhaps we could apply a simple rule like the following:

David, I tend to agree.

But how would it clarify NEMO vs routing protocols?

NEMO is Mobility Headers, following the IP base header (maybe AH/ESP/DO 
headers in between), final header no further payload, 'below' the BSD 
Sockets. Layer 3 thus.

RIPng is UDP, above BSD Socket interface, non final headers, plenty of
payload. In this sense it looks at least Transport layer (6 maybe?).

I'm not sure how you see this.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Feb 2009 15:05:22 +0100

Philip, let me try to better address your comments.

Substitute the following:
> The Network Mobility Basic Support Protocol extensions of Mobile IPv6
>  ("NEMOv6" RFC3963) allow a Mobile Router to manage mobile routing 
> information with its Home Agent, in order to securely connect a
> moving network to the Internet.  Section 8 of RFC3963 describes
> support for dynamic routing protocols.  Simple and nested topologies
> of NEMO moving networks can be useful for topologies of low-power
> devices communicating through wireless lossy links, either when
> disconnected from - but most notably when connected to - the
> Internet.

What do you think?

Alex
PS: I have separated away the ND and DHCP suggestions.

Philip Levis a écrit :
> capabilities of some IETF protocols but not others. Otherwise, it has
>  started down the path of suggesting paths post re-chartering, 
> something it is explicitly not supposed to do, and is playing 
> favorites. It would then require a statement of many possible 
> wireless, and ROLL networks. I think folks in ROLL, including 
> long-term IETFers, industry representatives, and protocol designers,
>  are happy to help dispel this confusion, that doesn't mean all of 
> this information should be pushed into the first draft that led to 
> your confusion.
> 
> are more than one hop away. From the above descriptions, NEMO does 
> not fit this scenario, unless you assume that the correspondent node
>  is a single hop from the Home Agent, the Home Agent is a single hop
>  from the Care-of-Address, and the Care-of-Address is a single hop 
> from the Mobile Router. Or am I mistaken?
> 
> Phil
>

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 6 Feb 2009 06:16:06 -0800

Snipped...

> Although 

JD:  Do we have consensus that this is true, or is it simply an
assertion?  Also, there are a multiplicity of protocols and algorithms
that might be considered useful so why do we have to specifically call
out this one?

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Feb 2009 15:42:07 +0100

Drake, John E a écrit :
> Snipped...
> 
>>> 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.
> 
> assertion?

Which do you question?  The "NEMO is not suitable..." or the part
"loop-free tree formation... useful..."?

My oppinion:  when protocols-survey co-Authors say "loop-free tree
formation" I think it refers to an individual proposal for NEMO RO space
(or maybe of MANEMO effort), which is a novel extension of a protocol.
Contrary to that oppinion I think not only "loop-free tree formation" is
an inner characteristic of simple moving networks, but protocol-wise 
could be addressed by any other individual proposals already posted 
previously.

I disagree with the part "NEMO is not suitable..." because I think the
NEMO extensions RFC3963 could very well apply to lossly linked low
powered devices.

> Also, there are a multiplicity of protocols and algorithms that might
>  be considered useful so why do we have to specifically call out this
>  one?

I agree with this statement, but not sure which "one" do you question
"specifically calling out"?  I support mentioning NEMO RFC 3963 because
it is agreed by a WG and has many implementations.  I don't support
citing singly draft-thubert-tree-discovery, because it is only one
proposal among many others.

Alex

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 6 Feb 2009 06:51:04 -0800

> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Friday, February 06, 2009 6:42 AM
> To: Drake, John E
> Cc: ROLL WG
> Subject: Re: [Roll] suggestion of NEMO text for protocols-survey draft
> 
> Drake, John E a écrit :
> > Snipped...
> > 
> >>> some of its mechanisms, such as loop-free tree formation, 
> might  be 
> Which do you question?  The "NEMO is not suitable..." or the 
> part "loop-free tree formation... useful..."?

JD:  Oops, sorry.  The latter.  I thought the former was obvious.
 
> 
> My oppinion:  when protocols-survey co-Authors say "loop-free 
> tree formation" I think it refers to an individual proposal 
> for NEMO RO space (or maybe of MANEMO effort), which is a 
> novel extension of a protocol.
> Contrary to that oppinion I think not only "loop-free tree 
> formation" is an inner characteristic of simple moving 
> networks, but protocol-wise could be addressed by any other 
> individual proposals already posted previously.
> 
> I disagree with the part "NEMO is not suitable..." because I 
> think the NEMO extensions RFC3963 could very well apply to 
> lossly linked low powered devices.
> 
> I agree with this statement, but not sure which "one" do you 
> question "specifically calling out"?  I support mentioning 
> NEMO RFC 3963 because it is agreed by a WG and has many 
> implementations.  I don't support citing singly 
> draft-thubert-tree-discovery, because it is only one proposal 
> among many others.
> 
> Alex
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Feb 2009 15:58:57 +0100

Drake, John E a écrit :
[...]

>>>>> Although NEMO itself is not a suitable routing solution to
>>>>> LLNs, some of its mechanisms, such as loop-free tree

I agree there's no consensus on "loop-free tree formation... useful...".

For the former "NEMO [RFC3963] is not suitable... [to ROLL]" - I disagree.

Alex

>> formation" I think it refers to an individual proposal for NEMO RO
>> space (or maybe of MANEMO effort), which is a novel extension of a
>> protocol. Contrary to that oppinion I think not only "loop-free
>> tree formation" is an inner characteristic of simple moving 
>> I disagree with the part "NEMO is not suitable..." because I think
>> the NEMO extensions RFC3963 could very well apply to lossly linked
>> low powered devices.
>> 
>> question "specifically calling out"?  I support mentioning NEMO RFC
>> 3963 because it is agreed by a WG and has many implementations.  I
>> don't support citing singly draft-thubert-tree-discovery, because
>> it is only one proposal among many others.
>> 
>> Alex
>> 
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 6 Feb 2009 16:44:54 +0100

Hi John and Alex
 
1) The NEMO explicit prefix is a route advertisement, NEMO injects routes in the RIB, redistributes them etc... IOW NEMO includes a routing protocol packaged with a tunnel setup protocol.
 
2) I do not see a thing that was done at the NEMO WG and that can be remotely useful to ROLL. NEMO is out of the picture because it aims at global mobility which is a very different problem, and not surprisingly, is not suited for the job at hand.
 
3) MANEMO is a very different story. MANEMO had sensor networking in its problem statement. I think that there is a risk on confusion between NEMO and MANEMO because MANEMO was a spawned off NEMO, though a very different problem.
 
4) The MANEMO approach was to split the problem in several subcomponents that you could assemble at your guise. For instance build a tree and source route, build a tree and route along the tree, build a tree, route long the tree and build additional routes on-demand, build a tree and use it to define subareas where other (MANET) protocol(s) would apply and then use the tree to route between those subareas, build a graph and route along it, etc... Taking one individual draft out of that effort to point out that it is unsufficient as a full solution is missing the point completely.
 
Maybe we should just remove all reference to NEMO because it's irrelevant, like many of the 5K+ RFCs available at this time.
 
We need to make sure, in any case, that people do not read this prose as ruling out MANEMO. MANEMO is not considered in the study because it was stalled at the stage of a proposal, as opposed to an IETF experimental or standard track work. I think it is acceptable to mention its existence as previous and related IETF art.
 
On the side, I'm not aware of many protocols that aim at building those mobile/radio trees/DAGs at the IETF, though I agree there are plenty in the academia. If there are then I think they should all be mentioned on equal ground. Either they exist as exp/std track and then they should be studied, or they exist as individual submission and they can be referenced together with the MANEMO work as background information.
 
Makes sense?
 
Pascal

De: [email-masked] de la part de Drake, John E
Date: ven. 06/02/2009 15:51
À: Alexandru Petrescu
Cc: ROLL WG
Objet : Re: [Roll] suggestion of NEMO text for protocols-survey draft

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 6 Feb 2009 07:56:51 -0800

> Maybe we should just remove all reference to NEMO because 
> it's irrelevant, like many of the 5K+ RFCs available at this time.

JD:  Fine with me.  Alternatively, we could provide an explantion and applicability evaluation for all of the 5K+ RFCs.

> On the side, I'm not aware of many protocols that aim at 
> building those mobile/radio trees/DAGs at the IETF, though I 
> agree there are plenty in the academia. If there are then I 
> think they should all be mentioned on equal ground. Either 
> they exist as exp/std track and then they should be studied, 
> or they exist as individual submission and they can be 
> referenced together with the MANEMO work as background information.

JD:  I think that was my point.  I.e., don't mention any of them.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Feb 2009 17:01:50 +0100

Pascal Thubert (pthubert) a écrit :
> Hi John and Alex
> 
> 1) The NEMO explicit prefix is a route advertisement, NEMO injects 
> routes in the RIB, redistributes them etc... IOW NEMO includes a 
> routing protocol packaged with a tunnel setup protocol.

"RIB"?  "IOW"?  Sorry I can't agree or disagree with that without
knowing what you mean.

> 2) I do not see a thing that was done at the NEMO WG and that can be 
> remotely useful to ROLL. NEMO is out of the picture because it aims 
> at global mobility which is a very different problem, and not 
> surprisingly, is not suited for the job at hand.

Well, I think NEMO RFC3963 is useful in general for moving networks, and
may be the only possibility if one wants to securely connect a moving
ROLL network to the Internet.

> Maybe we should just remove all reference to NEMO because it's 
> irrelevant

I think I can agree to remove all text saying "NEMO" from
protocols-survey, neither useful nor not-useful, neither as
"hierarchical NEMO", neither RFC3963.

> We need to make sure, in any case, that people do not read this prose
>  as ruling out MANEMO. MANEMO is not considered in the study because 
> it was stalled at the stage of a proposal, as opposed to an IETF 
> experimental or standard track work. I think it is acceptable to 
> mention its existence as previous and related IETF art.

I agree.

> On the side, I'm not aware of many protocols that aim at building 
> those mobile/radio trees/DAGs at the IETF, though I agree there are 
> plenty in the academia.

At least one other NEMO proposal builds a star of moving networks.  A
star is a tree and a DAG (Directed Acyclic Graph) at the same time.

Alex

---

From: JP Vasseur <[email-masked]>
Date: Fri, 6 Feb 2009 17:07:41 +0100

Thanks for continuing the discussion - here is my take here:

[SNIP]

> "hierarchical NEMO", neither RFC3963.

OK.

Authors can you update accordingly ?

> star is a tree and a DAG (Directed Acyclic Graph) at the same time.

Let's continue this discussion when the protocol will start. I  
(myself) has to restrain from commenting ...

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 6 Feb 2009 17:09:33 +0100

So we are down to
* Resolving Ian's comments
* Resolving Thomas' comments: we are moving toward a nice resolution.

Thanks.

JP.

On Feb 6, 2009, at 5:07 PM, JP Vasseur wrote:

>>> as ruling out MANEMO. MANEMO is not considered in the study  
>>> because it was stalled at the stage of a proposal, as opposed to  
>>> an IETF experimental or standard track work. I think it is  
>>> acceptable to mention its existence as previous and related IETF  
>>> art.
>>
>> I agree.
>>
>>> those mobile/radio trees/DAGs at the IETF, though I agree there  
>>> are plenty in the academia.
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Feb 2009 17:15:08 +0100

>> "hierarchical NEMO", neither RFC3963.

Sorry, I forgot, make sure to remove "NEMO" from the Charter too.

Alex

---

From: Philip Levis <[email-masked]>
Date: Fri, 6 Feb 2009 08:41:29 -0800

NEMO originally was not in the draft, then Emmanuel insisted it be  
included because it is in the charter (December 15) So.... Tug of war  
here.

Phil

On Feb 6, 2009, at 8:01 AM, Alexandru Petrescu <[email-masked] 

>> 2) I do not see a thing that was done at the NEMO WG and that can  
>> be remotely useful to ROLL. NEMO is out of the picture because it  
>> aims at global mobility which is a very different problem, and not

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Feb 2009 18:44:07 +0100

> included because it is in the charter (December 15) So.... Tug of war

Sorry, no rival rope pulling, no tug war.

Emmanuel may have suggested so because it's in the Charter - perfectly
reasonable.  But from that to saying "NEMO is not a...", there's a long 
way.  Emmanuel may have suggested "NEMO RO" too, which is also 
reasonable - an RFC overviews NEMO RO space.

And that to boil down to "NEMO is not a..." and the improvement of that 
being an individual NEMO RO proposal...  I completely disagree with both.

There seems to be disagreement to what I say, so.

Alex

> 
> 
> Phil
> 
> On Feb 6, 2009, at 8:01 AM, Alexandru Petrescu 
> <[email-masked]> wrote:
> 
>>> Hi John and Alex 1) The NEMO explicit prefix is a route
>>> advertisement, NEMO injects routes in the RIB, redistributes them
>>> etc... IOW NEMO includes a routing protocol packaged with a
>>> tunnel setup protocol.
>> 
>>> aims at global mobility which is a very different problem, and
>>> not surprisingly, is not suited for the job at hand.
>> 
>> Well, I think NEMO RFC3963 is useful in general for moving
>> networks, and may be the only possibility if one wants to securely
>> connect a moving ROLL network to the Internet.
>> 
>>> We need to make sure, in any case, that people do not read this
>>> prose as ruling out MANEMO. MANEMO is not considered in the study
>> At least one other NEMO proposal builds a star of moving networks.
>> A star is a tree and a DAG (Directed Acyclic Graph) at the same
>> time.
>> 
>> Alex
>> 
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 6 Feb 2009 19:25:11 +0100

Hi Alex

>"RIB"?  "IOW"?  Sorry I can't agree or disagree with that without

RIB is the Routing Information Base. In Other Words (IOW) the routing
table.

Pascal

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Feb 2009 20:26:38 +0100

Pascal Thubert (pthubert) a écrit :
> Hi Alex
> 
>>> 1) The NEMO explicit prefix is a route advertisement, NEMO 
>>> injects routes in the RIB, redistributes them etc... IOW NEMO 
>>> includes a routing protocol packaged with a tunnel setup 
>>> protocol.

Ok.  For what is worth, I agree to qualify NEMO explicit mode as a
routing protocol packaged with a tunnel setup protocol - following an
explicit Binding Update/Ack exchange the routing table entries and the
right tunnel parameters are set up at Mobile Router and at Home Agent.

Alex

---

From: "David E. Culler" <[email-masked]>
Date: Sun, 08 Feb 2009 01:53:56 -0800

There is no question that a number of ideas developed in NEMO are very
valuable for ROLL.  Indeed, many of Jonathan Hui's proposals for RA
options, the use of non-reflexive (i.e., overlapping) link local
domains, and so on, have roots in NEMO drafts.  His drafts show that
connection pretty well.  If we can ever get past the survey stage, we
should have some really productive technical discussions.  There are
definitely ideas in NEMO that have value outside the particular scope
of that WG.  I'm not sure about this particular suggestion, as there is
a great body of work on tree and dag formation, loop freedom, and loop
detection.  And a lot of it is extremely well grounded in actual low
power and lossy links.  But, if a few lines mean that we can wrap this
up and get back to technical work focused on arriving at a solution, it
is OK with me to toss it in.  I feel really comfortable letting the
authors be the final judge on the details of the wording.  I do think
we should avoid going hugely out of our way to stroke any particular
subcommunity.  There are many that bring huge value and it will get
incredibly unwieldy if everyone feel the need to have a nice word
tossed in for them.  This, of course, was why in the original plan for
the draft we placed hard limits on the universe of candidates to
consider.  On the other hand, the charter dictates that we pay special
attention to MANET and NEMO, so let's get to text that they are happy
with, even if it has a few sentences that are general observations of
goodness and potential opportunity and even if they don't contribute
directly to the goal of answering: YES / NO.  We've already answered
that, so at this stage we are just getting everyone into a comfort zone
so we can wrap it up and move on.

Drake, John E wrote:

Snipped...

Although

---

From: "David E. Culler" <[email-masked]>
Date: Sun, 08 Feb 2009 02:02:06 -0800

What makes most sense is that we not burden the ROLL routing survey
draft with resolving the fine points of MANET/NEMO/MANEMO.  The survey
has an extremely simple binary goal.  Is there an established routing
protocol that exists today that can be used for Low Power and Lossy
networks.  If the answer to that is yes, the ROLL WG is done.  If the
answer to that is No, the ROLL WG recharters and begins the process of
modifying an existing, building a new hybrid, or building from
scratch.  If we simply take that simple statement of the responsibility
of the survey document to heart, we have a trivial answer to all these
subtle questions.  If the proposed text contributes directly to
resolving that question, it goes in.  If it does not contribute
directly to that goal, it says out.

It is not to be a treatise on all things relevant to routing in the
wireless networking domain.  It is not a beauty contest.  It is not a
performance evaluation.  It is not prestigious to be included.  It is
not pejorative to be left out.  The survey is merely an assessment
relative to a particular question.

So here he have a simple guideline: "When in doubt, leave it out."

Pascal Thubert (pthubert) wrote:

Hi John and Alex

1) The NEMO explicit prefix is a route advertisement,
NEMO injects routes in the RIB, redistributes them etc... IOW NEMO
includes a routing protocol packaged with a tunnel setup protocol.

2) I do not see a thing that was done at the NEMO WG
and that can be remotely useful to ROLL. NEMO is out of the picture
because it aims at global mobility which is a very different problem,
and not surprisingly, is not suited for the job at hand.

3) MANEMO is a very different story. MANEMO had sensor
networking in its problem statement. I think that there is a risk on
confusion between NEMO and MANEMO because MANEMO was a spawned
off NEMO, though a very different problem.

4) The MANEMO approach was to split the problem in
several subcomponents that you could assemble at your guise. For
instance build a tree and source route, build a tree and route along
the tree, build a tree, route long the tree and build additional routes
on-demand, build a tree and use it to define subareas where other
(MANET) protocol(s) would apply and then use the tree to route between
those subareas, build a graph and route along it, etc... Taking one
individual draft out of that effort to point out that it is
unsufficient as a full solution is missing the point completely.

Maybe we should just remove all reference to NEMO
because it's irrelevant, like many of the 5K+ RFCs available at this
time.

We need to make sure, in any case, that people do not
read this prose as ruling out MANEMO. MANEMO is not considered in the
study because it was stalled at the stage of a proposal, as opposed to
an IETF experimental or standard track work. I think it is acceptable
to mention its existence as previous and related IETF art.

On the side, I'm not aware of many protocols that aim
at building those mobile/radio trees/DAGs at the IETF, though I agree
there are plenty in the academia. If there are then I think they should
all be mentioned on equal ground. Either they exist as exp/std track
and then they should be studied, or they exist as individual submission
and they can be referenced together with the MANEMO work as background
information.

Makes sense?

Pascal

De:
[email-masked] de la part de Drake, John E

À: Alexandru Petrescu

Cc: ROLL WG

Objet : Re: [Roll] suggestion of NEMO text for
protocols-survey draft

> might  be

> >>> useful in an LLN routing protocol.

> > Also, there are a multiplicity of protocols and algorithms

> that might

> > be considered useful so why do we have to specifically call

> out this

Roll mailing list

[email-masked]