Subject: [Roll] I-D Action:draft-ietf-roll-indus-routing-reqs-04.txt

From: [email-masked]
Date: Thu, 22 Jan 2009 00:45:01 -0800 (PST)

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

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 23 Jan 2009 11:18:07 +0100

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 23 Jan 2009 11:35:48 +0100

---

From: JP Vasseur <[email-masked]>
Date: Fri, 23 Jan 2009 12:32:29 +0100

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 23 Jan 2009 11:39:00 +0100

---

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

On Jan 23, 2009, at 1:40 AM, Thomas Heide Clausen wrote:

> Dear Authors, All,
>
> Since I'm taking stabs at 6lowpan here as well, I've included the  
> 6lowpan AD as Cc to this email.
>
> Thanks for producing an updated I-D so quickly. JP asked for a  
> quick turn-around on the review as well, and so I have reviewed the  
> document, and attached a pdf as I did last time, to include my  
> detailed/nittty-gritty comments as well.

I think it's a bit beyond me to engage in the entire ROLL/MANET/ 
6lowpan debate. So I'll keep my replies constrained to comments on  
the document itself.
>
> 	o	I still see "Criteria" used, and I think that it's not the right  
> term. "Evaluation metrics" seems
> 		a much more appropriate term. I've argued why in my previous  
> review, and so I'll defer to
> 		that for details as to why -- but I REALLY do encourage changing  
> the term.
>
> 		I can say the magic word ("please"), if it helps any ;)

Response on the ROLL list; I have to respectfully disagree based on  
the literal meanings of the terms. Pass/fail/? are criteria; the big- 
O notation used to reach them is the metric.

>
>
> 	o	There still are a few inconsistencies as to if not attaining a  
> "pass" on all the evaluation
> 		metrics means that the protocol:
>
> 			o	cannot be used
> 			o	is not a candidate at all
> 			o	cannot be used as-is, but may be modified to work
>
> 		Sections 1 (last paragraph), 3.2, 4.0 (2nd paragraph) send  
> slightly different messages as to
> 		this.
>
> 		This ties in with another problem, that I just notice right now.  
> Section 1 ends with:
>
> 			"Whether or not such a protocol involves modifications to an  
> existing
> 			   protocol or a new protocol entirely is outside the scope of this
> 			   document: this document simply seeks to answer the question:  
> do LLNs
> 			   require a new protocol specification document at all?"
>
> 		Which I can agree with, as such. However 3.2 reads:
>
> 			"A protocol that does not meet the criteria cannot be used as
> 			   specified, but it is possible that a protocol meets the  
> criteria yet
> 			   is not able to meet the requirements of a particular application
> 			   domain.  Nevertheless, a protocol that meets all of the criteria
> 			   would be very promising, and deserve a closer look and  
> consideration
> 			   in light of LLN application domains."
>
> 		And 4.0:
> 		
> 			"If a protocol  cannot meet even these minimalist criteria, then  
> it cannot be used
> 			   unchanged in several major ROLL application domains and so is
> 			   unlikely to be a good candidate for use."
>
>
> 		The offending bits here are the last sentence in the quote from  
> 3.2, and the
> 		"is unlikely to be a good candidate for use" from 4.
>
> 		Now, 1 states that the goal simply is to identify "can an  
> existing protocol
> 		specification be used?".
>
> 		3.2 and 4.0 state, essentially, that the document go both beyond  
> and below that,
> 		by admitting that "no, we cannot answer that, the evaluation  
> metrics presented
> 		do not allow answering this question completely" -- and "oh, the  
> document also
> 		tries to identify protocols that could be further developed/ 
> investigated".
>
> 		In other words, the document sets out to do one thing, then  
> doesn't quite do that,
> 		but does something else. While I am sure that that's not the  
> intent, it could be
> 		read as if the document essentially had as objective to "dismiss  
> all related IETF work"
> 		-- and I'd really rather that we not be accused of that ;)

Hrm. Let me try to work through this.

The issue is that we'll only know if a protocol can be used is by,  
well, using it. Given the large number of protocols out there, asking  
ROLL folks to implement them all and start testing is a bad idea.  
Instead, we want to get some sense of what is promising and what is not.

The Section 1 quote describes the high order bit: does ROLL have to  
write new protocol specification documents? Note that this is  
actually a implication, in the logical sense:

if no protocol has all passes -> ROLL needs to work on protocol  
specification

In that way, it answers the question at the end of Section 1.

The Section 3.2 quote is about the case where a protocol has all  
passes. Simply put, if a protocol has all passes, we don't know if  
further specification is needed. It might be that other  
considerations besides the criteria in the document (e.g.,  
application specific, security, as you mention) require such work.  
But the fact that a protocol has all passes means that we should look  
at it closely.

The Section 4 quote might come across as stronger than it's supposed  
to be. The implicit statement here is that there are more ROLL  
application domains than those in the application documents. The  
point is that if a protocol can't meet the minimal requirements of  
those applications, it can't be used in those apps and, given a  
random other application, is unlikely to be a good choice.

>
>
> 	o	Security
> 		
> 		It still troubles me a great deal that the "Security  
> Considerations" section is
> 		intentionally left blank. It strikes me that the different  
> protocols discussed have
> 		different properties with respect to how they can be secured --  
> and that this
> 		discussion belongs in this document. If not, then I think the  
> rationale as to why
> 		this document does not consider security MUST be included in the  
> security
> 		considerations section.
>
> 		Or, if security simply is not at all important in ROLL networks,  
> then stating that
> 		as reason for not discussing security would likely be enough?

Security is important. But a lot of things are important. "Necessary  
but not sufficient." I think that pulling security into the picture  
will complicate things greatly, in part because it's one place where  
application domains differ tremendously. We tried to pick the  
criteria such that they were common across the application domains.  
But industrial monitoring has very different security requirements  
than home networks.

>
> 	o	I've made some additional comments to the evaluation of OLSR as  
> well, I encourage
> 		that these be considered.

I don't see them -- I see some terminology points (e.g., MANET versus  
mesh network); I thought I had addressed the fact that OLSRv2 can  
have a minimum interval between control messages?

The one major comment that seems to be outstanding is the control  
overhead. On one hand, I agree that ultimately what you care about is  
the overall cost of delivering packets. However, the recent compact  
routing work has shown that routing state, route stretch, and control  
traffic are all tightly entwined. I really don't think it would be  
helpful -- or productive, given the complexity of the problem -- to  
start carving out what subsets of this design space are acceptable  
for ROLL. Rather, the document just gives a very basic requirement;  
while it might not be tight enough, there are plenty of protocols  
that don't meet it.

Phil

---

From: "David E. Culler" <[email-masked]>
Date: Fri, 23 Jan 2009 11:57:05 -0800

---

From: JP Vasseur <[email-masked]>
Date: Sat, 24 Jan 2009 15:21:16 +0100

Dear Thomas,

Since we want to conclude this work end of this week according to the  
schedule, we worked with the authors yesterday.

We propose to add two new paragraph to address your concern (see  
below) and Phil will also post a new revision addressing the other  
comments.

Could you please then ACK ?

Please see in line for JP>

On Jan 23, 2009, at 12:32 PM, JP Vasseur wrote:

> Hi Thomas,
>
> On Jan 23, 2009, at 10:40 AM, Thomas Heide Clausen wrote:
>
>> Dear Authors, All,
>>
> And thanks for this Thomas, we very much appreciate the detailed  
> comments. As pointed in many emails we now passed WG LC several  
> weeks, and I want to close on this work item *this week* so as not  
> to further delay our progress as a WG. I know that you agree and  
> understand.
>
>> I think that the document has improved some, however I still have  
>> some high-level comments, in addition to the nitty-gritty ones  
>> included in the pdf and those that I raised in my -03 review which  
>> are not yet addressed.
>
> Let me reply on the high level comments and I'm sure that Phil and  
> his co-authors will quickly address the other ones.
>
>> I raise the high-level ones here, as those are what I think we need  
>> to resolve before sending the document onwards.
>>
>> 	o	I note that a number of my review comments from -03 have not  
>> been addressed, and so
>> 		I consider those to still be applicable and encourage that my -03  
>> review be reconsidered.
>> 		In particular, some of the comments which I would consider "easy  
>> fixes" have not been
>> 		incorporated. I wonder if it would be possible to expand on why  
>> not?
>>
>> 		That said, there are a number of also important comments  
>> (terminology-confusion,
>> 		omissions etc.) that I pointed out in my -03 review, which have  
>> not been addressed
>> 		(either through inclusion of text or through debunking on the  
>> 'list)
>
> I will work with Phil, Steve and Arsalan on these comments today and  
> over the week-end if they are available to get then addressed.
>

JP> Phil mentioned that he was working on a new revision to address  
the detailed comments.

>>
>>
>> 	o	It's still not clear how ROLL distinguishes itself from, say,  
>> MANET or 6low. Many of the
>> 		characteristics listed for ROLL deployments are isomorphic to  
>> those listed for MANET
>> 		and 6low, and even having read through the document(s) multiple  
>> times, I'm still left
>> 		having to guess.
>
> Ah you push my Hot Button ... since this discussion has been going  
> on for some time, was entirely resolved and pops up again. As you  
> know such questions are resolved when a WG is chartered (we are no  
> longer in a WG formation process, BOF, ...). That being said, we owe  
> you an answer. I'm just wondering whether we should try by writing  
> or simply discussing in SFO. But for the time being I think that  
> trying to position/compare/.... WGs is not that productive. The WG  
> chairs are all in sync and we can find some time with you to clarify  
> anything you want.
>

JP> I hopefully address your point here. Nothing more to add.

>>
>>
>> 		As the charter is relatively vague on this matter (it's not  
>> really a criticism of the charter,
>> 		it is as I think is reasonable for a wg with goal of "figuring  
>> our what to do next"),
>> 		I think it is a paramount requirement that this document -- which  
>> aims at evaluating
>> 		existing protocols for their applicability -- is extremely  
>> specific on this matter.
>>
>> 		So, my BIGGEST issue remains: the document concludes that "no  
>> existing protocols
>> 		are applicable as-is" -- but does not spell out, or even hint at,  
>> "applicable for what?"
>>
>> 		Would it be possible to add a section somewhere clearly stating  
>> this?
>
> Of course. I thought that this has been clarified but let me try  
> again and we'll draft a short text: the objective was to determine  
> whether we could find an existing protocol (as is) in order to meet  
> to requirements spelled out on the 4 WG documents for industrial  
> automation, urban networks, home automation and building automation.  
> That is it. You asked to clearly state that we should not exclude  
> existing protocol from being extended in the future to meet these  
> requirements, which we did, and we absolutely agree with you  
> (something we discussed several time in ROLL WG meetings).

JP> We owe you some text here, it is indeed a good idea to add some  
text:

PROPOSED TEXT:

Conclusion

Table XX shows that no existing IETF protocol specification meets the  
criteria described in Section YY
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. The new protocol  
specification will be based on the ROLL
routing requirements listed in the application-specific requirements  
documents [I-D.ietf-roll-home-routing-reqs]
[I-D.ietf-roll-indus-routing-reqs], [I-D.martocci-roll-building- 
routing-reqs].The results in Table XX may provide
some insight or guidance in such a discussion, indicating what  
protocol mechanisms may be better suited
to LLNs than others.

You made another comment that deserves additional text.

PROPOSED TEXT

New paragraph just before the "Formal Definitions" subsection:

A protocol failing to meet one or more of the criteria does not  
exclude it from being used in LLNs. Rather, it means
that, in order to be used in LLNs, the protocol would need to be  
extended in ways that do not conform with the current
specification document.

>
> Yes we could add other criteria in the protocol survey, change  
> them, ... but there was a good consensus in the WG to move ahead  
> with these (necessary but not sufficient) criteria.
>
> One (if) re-chartered for protocol work, we (as a WG) will look at  
> various existing candidates (with potential extensions such as OLSR  
> fish eye, RIP, ...) or new protocol. In the former we will of course  
> closely work with the WGs that own these protocol in light of the  
> application specific routing requirements.
>
>>
>> 		Let me cite from the 6low charter:
>>
>>
>> 			  "Well-established fields such as control networks, and  
>> burgeoning ones
>> 	such as "sensor" (or transducer) networks, are increasingly being
>> 	based on wireless technologies. Most (but certainly not all) of  
>> these
>> 	nodes are amongst the most constrained that have ever been networked
>> 	wirelessly. Extreme low power (such that they will run potentially  
>> for
>> 	years on batteries) and extreme low cost (total device cost in  
>> single
>> 	digit dollars, and riding Moore's law to continuously reduce that
>> 	price point) are seen as essential enablers towards their deployment
>> 	in networks with the following characteristics...."
>>
>> 		The 6lowpan charter even cites a milestone thus "Sep 2008: Submit  
>> Routing
>> 		Requirements document to IESG for consideration as an  
>> Informational RFC"
>>
>> 		Reading this indicates an overlap, and one could ask "Is ROLL the  
>> routing component
>> 		of 6low?". If yes, then this should probably be stated  
>> explicitly. If NO, then this probably
>> 		also should be stated explicitly -- and a justification given as  
>> well.
>
> No. We do not have in this document to put the relationship with all  
> other WG in perspective. That being said, I am happy to provide you  
> an explanation since this has been discussed many times in the past  
> (in 6lowpan and ROLL - look at the minutesm, "presentations", ...).  
> I was personally opposed to see that 6lowpan WG item on routing  
> since by definition routing is "agnostic" (not ignorant) to the PHY/ 
> MAC. The WG consensus was to have this WG item included the charter  
> and consensus wins, which is a good thing :-) In its current form, I  
> do not think that the WG ID is acceptable and I proposed (with the  
> agreement of the 6lowpan chairs and Mark) to propose a new revision  
> so as to clearly state that these routing requirement will be  
> 6lowpan specifics. ROL and 6lowpan will happily work together on  
> this. Issue closed. Hope this sheds some light.
>
> Now I cannot resist from making a general comment here: it is very  
> much welcome to receive comments, guidance, ... but please do not re- 
> open debates on which people have spent a lot of time and reached  
> consensus. ROLL has been moving fast with a lot of energy and time  
> from its active participants and I do not want to loose that  
> traction and motion. Hope you understand.
>
>>
>>
>> 		The same kind of argument can be made, let me cite from the MANET  
>> charter:
>>
>> 	   "The purpose of the MANET working group is to standardize IP  
>> routing
>> 	protocol functionality suitable for wireless routing application  
>> within
>> 	both static and dynamic topologies with increased dynamics due to  
>> node
>> 	motion or other factors"
>>
>> 		It does not explicitly enumerate the characteristics of "wireless  
>> routing", but again the relationship
>> 		with ROLL isn't clear.
>
> Note that we could do a similar exercise with many other WGs.
>
>>
>>
>> 		I think that this is the biggest piece missing from this document  
>> -- and I think that it's
>> 		a piece of paramount importance as well, so I really really think  
>> that we need to
>> 		write up something to clarify this.
>>
>
> The relationship with 6lowpan is fairly clear and ROLL and 6lowpan  
> works in concert. The only ambiguity was for the routing requirement  
> ID in 6lowpan (which is about 6lowpan specific issue) for which I  
> hope I clarified the situation. With regards to MANET, this is also  
> fairly simple. Should we decide to use a routing protocol of the  
> MANET WG, we will be more than happy to work with MANET to provide  
> the requirements and get the protocol extensions worked out by the  
> MANET WG. It is that simple :-)
>
>>
> We will address these comments.

JP> See the new revision and let us know if we addressed your comments.

> Just because we looked at the (necessary) but not sufficient criteria.
>
> Look at our charter, it is quite critical. But again, if a WG does  
> not pass the existing criteria this is enough to conclude.
>
> AGAIN, that does not mean that we will not use such a protocol with  
> extensions at all. The question is" can we use this
> protocol as-is" ?
>
>>
>> I think that these high-level points are important to get  
>> straightened out before moving this document forward. I see that  
>> others have raised issues as well, I'll reply to those with my  
>> comments.
>
> Hope I clarified.

Thanks.

>
> Thanks.
>
> JP.
>
>>
>> Cheers,
>>
>> Thomas
>>
>> <draft-ietf-roll-protocols-survey-04_review.pdf>
>