Subject: Re: [Roll] Few comments for our first discussion today

From: Philip Levis <[email-masked]>
Date: Thu, 7 May 2009 09:48:16 -0700

On Apr 16, 2009, at 6:31 AM, JP Vasseur wrote:

> Dear all,
>
> First many thanks again for accepting to be part of the DT. I did  
> not want to comment on the various individual submissions so far  
> since it was much more appropriate to provide feed-back to the DT,  
> especially because the authors of these drafts are part of the DT.
>
> Please find below some comments (that apply to the IDs already  
> posted):

Have there been any subsequent DT discussions? I can't seem to find  
any follow-up reports to the WG.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Thu, 7 May 2009 19:02:02 +0200

Hi Phil,

> any follow-up reports to the WG.

Yes the DT has been working hard and should very soon be ready to  
provide some comments, ask for feed-back/advise from the WG, .. the  
goal is to have a first ID (very first draft) within 2 weeks or so to  
start some discussion.

Thanks.

JP.

---

From: Philip Levis <[email-masked]>
Date: Thu, 7 May 2009 11:34:56 -0700

On May 7, 2009, at 10:02 AM, JP Vasseur wrote:

> goal is to have a first ID (very first draft) within 2 weeks or so  
> to start some discussion.

Going from a restatement of general design considerations to a  
concrete design in a draft doesn't provide a lot of visibility into  
the process. While I think it would be counter-productive for the WG  
to question every intermediate state of the DT's design, having some  
understanding of the process and considerations made would be helpful.  
Otherwise, I fear that reception of the first ID will end up with a  
long discussion of assumptions rather than technical details, which  
will ultimately lead to an inferior design.

Phil

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 May 2009 21:25:22 +0200

Philip Levis a écrit :
>>>> Please find below some comments (that apply to the IDs already posted):
>>>
> Going from a restatement of general design considerations to a concrete 
> design in a draft doesn't provide a lot of visibility into the process. 
> While I think it would be counter-productive for the WG to question 
> every intermediate state of the DT's design, having some understanding 
> of the process and considerations made would be helpful. Otherwise, I 
> fear that reception of the first ID will end up with a long discussion 
> of assumptions rather than technical details, which will ultimately lead 
> to an inferior design.

I agree in the sense there is need for more visibility to the DT 
activities - are there public archives of the ongoing DT email discussions?

I'm working on an energy metric for IPv6 links... how would this fit in 
the eventual ROLL protocol?  For example, does the ROLL protocol take 
_any_ metric into account?  The IP distance (number of hops)?  Any other 
metric?

I'm interested in the current DT thinking about the metrics, at least.

Alex

---

From: Tim Winter <[email-masked]>
Date: Thu, 07 May 2009 21:21:51 -0400

Hi Philip, Alexandru, WG,

The design team is aware that our efforts are only viable if the WG finds
them usable, and it is certainly not our intent that the process would
appear opaque.  I see your point that more visibility into the process will
better equip the WG to perform a focused technical review of the resulting
draft, as opposed to being distracted trying to understand the
process/assumptions.  I certainly dont want to see all of this effort
produce an inferior solution.  I shall endeavor to keep the WG
updated more frequently.

We have looked at the 4 requirements documents, extracting the MUSTs,
categorized them together, and used this exercise as a basis to understand
what would be required of a common routing solution.

We recognize the constrained and challenging aspects of LLN networks, and
the subsequent trade offs that will have to be made in application solutions.

Based on these exercises and further discussion, we have a working concept
of a routing solution built around a simple, core protocol plus a number of
options which can be added in a controlled manner to suit various
applications and take advantage of platform capabilities.  Further, we are
thinking that the solution should be specified in a
parametrized/configurable manner that will allow a solution implementer to
make trade-offs in the operation/administration of the protocol as
appropriate to the application/platform.  It is envisaged that a series of
Applicability Statements will also be developed to guide the implementer in
selecting parameters appropriate to solutions for the urban, building,
industrial, and home applications.

In light of this strategy, the DT has reached consensus that the most
straightforward approach is to specify a new routing protocol.  With this
approach we believe we can be most successful in having a minimal protocol
suitable to the ROLL application requirements.  We do certainly hope to
draw on many of the features found in existing protocols in order to 
composite a solution.

The DT is currently in the process of defining the basic mechanisms of the
core protocol.  A first draft outlining what we know of the solution so
far is underway, and will be further fleshed out by the basic mechanisms as
DT consensus is reached.  We are also working to refine our terminology.

At this time it is a little too early in the process to have specific
technical details on, e.g. metrics (although there will certainly be
metrics! ;) ), but once the basic mechanisms are defined then I think the DT
should be able to quickly reach consensus on such items, soliciting input 
from the WG as needed.

Regards,

-Tim

---

From: Philip Levis <[email-masked]>
Date: Thu, 7 May 2009 18:27:18 -0700

On May 7, 2009, at 6:21 PM, Tim Winter wrote:

> draw on many of the features found in existing protocols in order  
> to composite a solution.
>
> should be able to quickly reach consensus on such items, soliciting  
> input from the WG as needed.

Tim,

This is very helpful. Thanks!

One question: could you articulate the requirements of the core  
protocol? That is, what the DT's thoughts are on what should "core"  
and what should be an "option?" I understand that this list might  
change a bit, and so don't want to quibble on it, but it would help  
understand the priorities in the design's tradeoffs.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Fri, 8 May 2009 12:35:18 +0200

On May 7, 2009, at 9:25 PM, Alexandru Petrescu wrote:

>>>>> First many thanks again for accepting to be part of the DT. I  
>>>>> did not want to comment on the various individual submissions so  
>>>>> far since it was much more appropriate to provide feed-back to  
>>>>> the DT, especially because the authors of these drafts are part  
>>>>> of the DT.
>>>>>
>>>> Have there been any subsequent DT discussions? I can't seem to  
>>>> find any follow-up reports to the WG.
>>>>
>>>
>>> provide some comments, ask for feed-back/advise from the WG, ..  
>>> the goal is to have a first ID (very first draft) within 2 weeks  
>>> or so to start some discussion.
>> the process. While I think it would be counter-productive for the  
>> WG to question every intermediate state of the DT's design, having  
>> some understanding of the process and considerations made would be  
>> helpful. Otherwise, I fear that reception of the first ID will end  
>> up with a long discussion of assumptions rather than technical  
>> details, which will ultimately lead to an inferior design.
>

The DT will come back to the WG VEYR soon ... so far discussions have  
been focussed on syncing up on requirements, look at existing  
solutions, ... I asked the DT to go back to the WG for input as soon  
as there will be even a first cut of the core protocol.

>
> I'm working on an energy metric for IPv6 links... how would this fit  
> in the eventual ROLL protocol?  For example, does the ROLL protocol  
> take _any_ metric into account?  The IP distance (number of hops)?   
> Any other metric?
>

There is a document discussing metrics that has been adopted as WG  
(should be published soon). Expected new revision in 2 weeks: could  
you comment on it ?

Thanks.

JP.

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

---

From: Tim Winter <[email-masked]>
Date: Fri, 08 May 2009 19:40:12 -0400

Phil,

We are not ready to articulate such a list yet, but should be shortly.  I 
will keep you posted.

-Tim

Philip Levis wrote:
...
> protocol? That is, what the DT's thoughts are on what should "core" and 
> what should be an "option?" I understand that this list might change a 
> bit, and so don't want to quibble on it, but it would help understand 
> the priorities in the design's tradeoffs.
> 
> Phil
>

---

From: Philip Levis <[email-masked]>
Date: Fri, 8 May 2009 13:59:24 -0700

On May 8, 2009, at 3:35 AM, JP Vasseur wrote:

>> ]
>
> The DT will come back to the WG VEYR soon ... so far discussions  
> have been focussed on syncing up on requirements, look at existing  

JP,

It would be more useful and productive to start a discussion on design  
considerations before presenting a protocol design to the larger WG.  
Consensus is more important for design priorities than  technical  
details. While priorities are judgements that call for consensus,  
technical designs can be quantitatively evaluated through running code.

Tim commented that the DT is going through the application IDs to  
derive the MUSTs and SHOULDs, distilling them to a set of core  
requirements and optional ones for extensions. This has always been  
the stated first work item of the WG after rechartering, and so it  
makes a much more logical synchronization point.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Sun, 10 May 2009 13:16:09 +0200

On May 8, 2009, at 10:59 PM, Philip Levis wrote:

>> solutions, ... I asked the DT to go back to the WG for input as  
>> soon as there will be even a first cut of the core protocol.
>
> JP,
>
> It would be more useful and productive to start a discussion on  
> design considerations before presenting a protocol design to the  
> larger WG. Consensus is more important for design priorities than   
> technical details. While priorities are judgements that call for  
> consensus, technical designs can be quantitatively evaluated through  
> running code.

You are absolutely right and this is what I meant by "core protocol".

> makes a much more logical synchronization point.

Yes note that there is nothing new here, just a review of the MUST.

The DT will go back to the list very soon.

Thanks.

JP.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 May 2009 10:23:16 +0200

JP Vasseur a écrit :
>>> understanding of the process and considerations made would be 
>>> helpful. Otherwise, I fear that reception of the first ID will end up 
>>> with a long discussion of assumptions rather than technical details, 
>>> which will ultimately lead to an inferior design.
>>
> been focussed on syncing up on requirements, look at existing solutions, 
> ... I asked the DT to go back to the WG for input as soon as there will 
> be even a first cut of the core protocol.
> 
>>
> (should be published soon). Expected new revision in 2 weeks: could you 
> comment on it ?

I have commented earlier on it, about the necessity an energy for link 
metric...

I will wait for the next revision.

Alex

---

From: JP Vasseur <[email-masked]>
Date: Mon, 11 May 2009 11:09:48 +0200

On May 11, 2009, at 10:23 AM, Alexandru Petrescu wrote:

>>>>>>> did not want to comment on the various individual submissions  
>>>>>>> so far since it was much more appropriate to provide feed-back  
>>>>>>> to the DT, especially because the authors of these drafts are  
>>>>>>> part of the DT.
>>>>>>>
>>>>> Yes the DT has been working hard and should very soon be ready  
>>>>> to provide some comments, ask for feed-back/advise from the  
>>>>> WG, .. the goal is to have a first ID (very first draft) within  
>>>>> 2 weeks or so to start some discussion.
>>>> concrete design in a draft doesn't provide a lot of visibility  
>>>> into the process. While I think it would be counter-productive  
>>>> for the WG to question every intermediate state of the DT's  
>>>> design, having some understanding of the process and  
>>>> considerations made would be helpful. Otherwise, I fear that  
>>>> reception of the first ID will end up with a long discussion of  
>>>> assumptions rather than technical details, which will ultimately  
>>>> lead to an inferior design.
>>>
>>> I'm working on an energy metric for IPv6 links... how would this  
>>> fit in the eventual ROLL protocol?  For example, does the ROLL  
>>> protocol take _any_ metric into account?  The IP distance (number  
>>> of hops)?  Any other metric?
>>>
> I have commented earlier on it, about the necessity an energy for  
> link metric...

yes this has been day 1 part of the METRIC ID.

> I will wait for the next revision.

Excellent, thanks.

JP.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 May 2009 11:54:02 +0200

> yes this has been day 1 part of the METRIC ID.

But it doesn't seem to be in the draft(?)

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 13 May 2009 16:06:22 +0100

JP Vasseur
> Philip Levis

As the various documents aren't exactly aligned, even this needs
to make some judgements, and it would be useful to see what those
are.

********************************************************************
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: [email-masked]
Date: Thu, 14 May 2009 09:30:01 -0500

I agree.  Otherwise we are just setting ourselves up for confrontation 
once the DT has developed a working document.  If they provide their 
integrated requirement set earlier the requirement's authors could in 
parallel be assimilating these four requirement sets into a single 
comprehensive set.

"Dearlove, Christopher (UK)" <[email-masked]> 
Sent by: [email-masked]
05/13/2009 10:06 AM

To
"JP Vasseur" <[email-masked]>, "Philip Levis" <[email-masked]>
cc
ROLL WG <[email-masked]>, [email-masked]
Subject
Re: [Roll] Few comments for our first discussion today

JP Vasseur

---

From: JP Vasseur <[email-masked]>
Date: Thu, 14 May 2009 16:37:56 +0200

That is an excellent suggestion. Since regrouping the requirements  
(MUST) is a starting point, we'll make sure to send it to the list.
Note that the point is not to rediscuss any of these of course.

Thanks.

JP.

On May 14, 2009, at 4:30 PM, [email-masked] wrote:

>
> I agree.  Otherwise we are just setting ourselves up for  
> confrontation once the DT has developed a working document.  If they  
> provide their integrated requirement set earlier the requirement's  
> authors could in parallel be assimilating these four requirement  
> sets into a single comprehensive set.
>
>
>
>
>

---

From: Philip Levis <[email-masked]>
Date: Thu, 14 May 2009 10:51:10 -0400

> Note that the point is not to rediscuss any of these of course.

Clearly the MUSTs are simply a synthesis of the application drafts and  
so not really worth discussing, unless WG members find a misreading or  
typo.

That being said, the breakdown of what's "core" and what's "optional"  
may be worth discussion. Of course, this discussion would be more  
productive if it strove to better understand the DT's approach,   
rather than question it at this early stage.

Phil

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 14 May 2009 16:05:58 +0100

JP Vasseur
>  Note that the point is not to rediscuss any of these of course.

If there are any resolutions of differences between the documents
then to that extent, discussing the MUSTs is inevitable, you can't
simply say don't rediscuss.

And there are significant differences. The number of nodes to support
varies (and by a couple of orders of magnitude). The route finding
time varies from seconds to minutes. Yes, you could say "take the
worst case for each". But now you have a large network, with a low
latency - and a specification (in one of the drafts) for any peer
to peer routing. And authentication has to be both compulsory and
optional (OK, SHOULD technically rather than MUST for the latter,
but still an issue - and I haven't checked all details of all four
drafts).

If anyone can achieve all the MUSTs (let alone the SHOULDs) in all
drafts, excellent. But I suspect not, as document A may make a
demand that's reasonable for its (for example) lower number of nodes,
but not so easy for document B's higher number of nodes, especially
in combination with document C's latency. I strongly suspect some
trading off of requirements will be needed. And that's going to need
agreement.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 14 May 2009 16:10:27 +0100

Philip Levis

> typo.

I think that is absolutely not the case. What's your synthesis, all
worst cases to be supported simultaneously? Something else?

> Of course, this discussion would be more  

I would love to understand the DT's approach. Where is it explained,
in particular with regard to how conflicting requirements are being
reconciled?

---

From: [email-masked]
Date: Thu, 14 May 2009 12:01:10 -0500

I couldn't have stated it better than Christopher.  As one of the document 
authors (commercial buildings), I purposely spent little time reviewing 
the other 3 documents since I didn't want to taint my requirements by 
understanding the other requirements too well.  I know the other authors 
didn't review my document since my document was drafted months after the 
other three.

As was noted in San Francisco, we need to concern ourselves with the 
'duck' syndrome. That is, when God created the duck he decided to make one 
animal that could swim, fly and walk.  He got what he designed, except now 
the poor thing can't do any of them too well.  If we simply take all the 
MUSTs as absolutes, we will be creating our own duck. 

I would be willing to 'rack and stack' my requirements with others.  The 
worst that could happen is we decide we must have all our MUSTs which is 
where we are now.  More likely, we will be able to assimilate the list 
into a more refined prioritized list that would better assist the DT.

Jerry

05/14/2009 10:06 AM

To
"JP Vasseur" <[email-masked]>, "Jerald P Martocci" 
<[email-masked]>
cc
<[email-masked]>, "Philip Levis" <[email-masked]>, "ROLL 
WG" <[email-masked]>, <[email-masked]>
Subject
RE: [Roll] Few comments for our first discussion today

JP Vasseur

---

From: JP Vasseur <[email-masked]>
Date: Thu, 14 May 2009 19:11:00 +0200

On May 14, 2009, at 7:01 PM, [email-masked] wrote:

>
>
> I couldn't have stated it better than Christopher.  As one of the  
> document authors (commercial buildings), I purposely spent little  
> time reviewing the other 3 documents since I didn't want to taint my  
> requirements by understanding the other requirements too well.  I  
> know the other authors didn't review my document since my document  
> was drafted months after the other three.
>
> 'duck' syndrome. That is, when God created the duck he decided to  
> make one animal that could swim, fly and walk.  He got what he  
> designed, except now the poor thing can't do any of them too well.   
> If we simply take all the MUSTs as absolutes, we will be creating  
> our own duck.

I cannot agree more.

>
>
> I would be willing to 'rack and stack' my requirements with others.   
> The worst that could happen is we decide we must have all our MUSTs  
> which is where we are now.

Just a re-assure you ... I think that we are all on the same page, we  
will have to make compromises.

That being said, and there are many examples of such protocols, the  
idea is to build a modular protocol with a minimal "core" of basic  
functions and optional features that could be used in different  
environments activating the required options only when necessary.

> More likely, we will be able to assimilate the list into a more  
> refined prioritized list that would better assist the DT.
>
> Jerry
>
>
>
>
>
> "JP Vasseur" <[email-masked]>, "Jerald P Martocci" <[email-masked] 
> >
> cc
> <[email-masked]>, "Philip Levis" <[email-masked]>,  
> "ROLL WG" <[email-masked]>, <[email-masked]>
> Subject

---

From: Philip Levis <[email-masked]>
Date: Thu, 14 May 2009 10:11:58 -0700

> worst cases to be supported simultaneously? Something else?

Oh, I think there's a misunderstanding here. Where the protocol survey  
document was very clear in that it did not treat application  
requirements exhaustively, a protocol design needs to.

I think the point the DT is making by separating "core" from  
"optional" is that there might be a set of MUSTs which most if not all  
applications share, which you then want in the core protocol. MUSTs  
which are only in a subset of the applications might then be served by  
optional extensions.

> in particular with regard to how conflicting requirements are being

I think they're in this process now: let's not burden them with over- 
documentation of every minutia and prevent them from getting work done.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Fri, 15 May 2009 10:00:48 +0200

Hi Christopher,

> simply say don't rediscuss.

Let me clarify what I mean by "rediscuss": I was referring to not  
reopening the
discussion on the requirements. We will have to make compromise  
between the
MUST, SHOULD, ... and in some cases we may not be able to satisfy them  
all,
which is acceptable, as long as it is documented. Of course, each time  
I say
"we" I mean the WG.

> trading off of requirements will be needed. And that's going to need

Completely agreeing.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 15 May 2009 10:01:38 +0200

On May 14, 2009, at 7:11 PM, Philip Levis wrote:

> Oh, I think there's a misunderstanding here. Where the protocol  
> survey document was very clear in that it did not treat application  
> "optional" is that there might be a set of MUSTs which most if not  
> all applications share, which you then want in the core protocol.  
> MUSTs which are only in a subset of the applications might then be  
> served by optional extensions.

That is exactly right.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 15 May 2009 10:09:36 +0100

Philip Levis
> Christopher Dearlove

If they are putting together consolidated, and possibly prioritised,
requirements as a recommendation to the WG, yes. Those will need some
rationale where requirements are downgraded. But there's not much point
in proceeding with protocol design until that. (Note that not proceeding
with protocol design is not the same as not considering protocol
realities.)