Subject: Re: [Roll] Proposal so as to reach a consensus on **draft-ietf-roll-protocols-survey-02 **

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 5 Jan 2009 14:55:42 -0000

>  - OLSRv2 changed to ? in the control cost metric, because it might be
possible to pass 
> with the right sort of aging of updates. ("Fisheye State Routing in
Mobile Ad Hoc Networks"). 
 
I think there are two components here, Fisheye (which is a sort of -
very loosely - backing off in space),
and backing off in time. Each allows a potential overhead vs.
performance tradeoff. (The tradeoff
depending on mobility, density, and all the other usual things.)
 
>  It would almost certainly require a new specification to say how to
do this in a correct and 
>  inoperable way, but might not violate the specification. 
 
OLSrv2 as-is already permits both, and interoperably. But how you might
choose to use it, and what
the costs and benefits might be, are up to the operator. (I suspect the
draft may need more work
on explaining that this is available.)
 
As a simpler case of this permission to do what you want, and
interoperate, consider the
more common fixed beacon time HELLO messages. (Actually even that isn't
the norm,
because of jitter and responses to topology changes, but for now let's
ignore those.)
Different nodes can use a different beacon period, and (provided they
also set their validity
times to match) can interoperate. But it's up to the user/operator to
decide if 2 seconds
(the suggested default) is good, or should it be 20 seconds or 0.2
second? But it's the
same analogy - the protocol supports, but doesn't define how to use the
flexibility. (It
also allows seprate decentralised decisions, so nodes can be using
different values -
or different strategies in the broader case - but doesn't exclude a
coordinated approach
set by some sort of policy.)
 
>  manet-fsr-00 seems like it has not been updated in quite a while. 
 
It's the Fisheye concept (also used in Fuzzy/Hazy Sighted Link State
routing - and I
don't know about the relative timing of each as originating the concept)
that is available
in OLSRv2, not the actual FSR protocol. As I recall, there's an IEEE
paper by the FSR
authors that I'd actually use as my basic reference rather than the FSR
ID, and a
FSLS/HSLS paper likewise. (HSLS is, I think, clearest on permitted
patterns of hop
count usage that give regular periods at each distance, something also
advised in the
OLSRv2 draft.)
 
 >  FSR does not alter the "table scalability "; it's not claimed in the
paper. 
 
I'd have to check which one that is. If it's the routing table size one,
then no, it doesn't.
(There are some partially speculative, and partially incomplete, ideas
in this area. But
they are developments, not part of OLSRv2 as-is, or expected to be in
the basic OLSRv2
RFC when we get to that point.)

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 5 Jan 2009 16:10:20 +0100

Hi Phil:

http://tools.ietf.org/html/draft-thubert-tree-discovery is about structuring a mesh of mobile routers. 

Tunnels and nested tunnel optimization come later in the process iff NEMO is to be used over that mesh.
NINA can also be added to advertise routes down the tree and enable a minimal routing within the mesh.

Quoting the abstract: 

"  This paper describes a simple distance vector protocol that exposes
   only a default route towards the infrastructure in a nested NEMO
   configuration.
"

In nested NEMO, the exit point to the infrastructure plays a role that is very similar to the sink in WSNs. 
For that reason, TD could play a role in the solution space for ROLL, once we have re-chartered for that work.

Have a great year,

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Philip Levis
Sent: samedi 20 décembre 2008 02:04
To: Emmanuel Baccelli
Cc: ROLL WG
Subject: Re: [Roll] Proposal so as to reach a consensus on **draft-ietf-roll-protocols-survey-02 **

On Dec 19, 2008, at 12:58 AM, Emmanuel Baccelli wrote:

>
>
> Emmanuel, did you read the rest of my message? I address NEMO/DTN on  
> point 2. Please acknowledge.
>
>
> Here are some relevant pointers (non-exhaustive list):
>
> http://tools.ietf.org/html/draft-irtf-dtnrg-prophet-01

This one doesn't fit the requirement of "mature draft."

> http://tools.ietf.org/html/draft-thubert-tree-discovery-06

This is a multi-tunneling protocol across multiple in a nest NEMO  
environment. You're right, we should at least mention why this is not  
included.

>
> They are in scope (NEMO space and DTN space) and they are describing  
> routing protocols that may be of interest for ROLL.

>
> If we just add the line you proposed, there will be no justification  
> why they are not evaluated. Do you agree?
>
> So we have a choice to make: either
> (i) justify why such routing approaches are not in scope, or
> (ii) evaluate a couple of such protocols in the draft, so as to  
> partially cover DTN and NEMO spaces, as the charter indicates.
>
> I suppose the latter wouldn't take so long? It's just a couple of  
> additional paragraphs and a couple of additional lines in the pass/ 
> fail table, like for the protocols already evaluated in the draft...  
> Do you agree?
>

I agree that we need to say something more in depth about the above  
NEMO draft. Do you agree that the DTN one does not satisfy the  
requirement?

Phil

---

From: Philip Levis <[email-masked]>
Date: Tue, 6 Jan 2009 09:46:13 -0800

On Dec 31, 2008, at 2:24 AM, Emmanuel Baccelli wrote:

>
>
> On Mon, Dec 29, 2008 at 11:10 PM, Philip Levis <[email-masked]>  
> wrote:
>
> On Dec 22, 2008, at 12:17 AM, Emmanuel Baccelli wrote:
>
> "analyze the scaling and characteristics of
> existing protocols and identify whether or not they meet the routing
> requirements of the applications identified above"
>
> If a protocol is not a routing protocol, then it can't meet the  
> routing requirements.
>
>
> Let's look at one example I was pointing to, the beginning of the  
> abstract of http://tools.ietf.org/html/draft-thubert-tree- 
> discovery-06 which reads:
>
> "This paper describes a simple distance vector protocol that exposes
> configuration."
> if this is not a routing protocol, what is it? If this is not in  
> scope, then I wonder what is.
>
> By the way, I'm sure you'll agree that it makes more sense to  
> evaluate this than to evaluate OSPF, in the context of ROLL...
>
> Maybe the next version of the draft will contain a convincing  
> explanation for these choices, but for now, I must say it still  
> eludes me.

You're right; it is a routing protocol. However, it only maintains a  
default route. It does not provide sufficient mechanisms for two nodes  
within an L2N to communicate. So I guess it's *technically* a routing  
protocol, but not in the sense that the draft is concerned with. Do  
you agree that the protocol described in draft-thubert-tree- 
discovery-06 would require additional mechanisms to support routing  
within an L2N?

Phil

---

From: JP Vasseur <[email-masked]>
Date: Tue, 6 Jan 2009 18:52:45 +0100

On Jan 6, 2009, at 6:46 PM, Philip Levis wrote:

>> On Mon, Dec 29, 2008 at 11:10 PM, Philip Levis  
>> <[email-masked]> wrote:
>>
>> abstract of http://tools.ietf.org/html/draft-thubert-tree-discovery-06 
>>  which reads:
>>
> default route. It does not provide sufficient mechanisms for two  
> nodes within an L2N to communicate. So I guess it's *technically* a  
> routing protocol, but not in the sense that the draft is concerned  
> with. Do you agree that the protocol described in draft-thubert-tree- 

note that the aim of this I-D is not to evaluate individual submission  
(yet)

Cheers.

JP.

>
>
> Phil_______________________________________________
> Roll mailing list
> [email-masked]

---

From: "Emmanuel Baccelli" <[email-masked]>
Date: Wed, 7 Jan 2009 13:08:11 +0100

Hi Phil, happy new year.

On Tue, Jan 6, 2009 at 6:46 PM, Philip Levis <[email-masked]> wrote:

>> If a protocol is not a routing protocol, then it can't meet the routing
>> requirements.
>>
>>
>> Let's look at one example I was pointing to, the beginning of the abstract
>> of http://tools.ietf.org/html/draft-thubert-tree-discovery-06 which
>> reads:
>>
>> if this is not a routing protocol, what is it? If this is not in scope,
>> then I wonder what is.
>>
>> By the way, I'm sure you'll agree that it makes more sense to evaluate
>> this than to evaluate OSPF, in the context of ROLL...
>>
>> Maybe the next version of the draft will contain a convincing explanation
>> for these choices, but for now, I must say it still eludes me.
>>
>
> protocol, but not in the sense that the draft is concerned with. Do you
> agree that the protocol described in draft-thubert-tree-discovery-06 would
> require additional mechanisms to support routing within an L2N?
>
> Phil

I thought that ROLL routing was about something more specific than MANET
routing? The way I understood it, the difference was basically: ROLL cares
about identified, simplistic traffic patterns. Judging from what you say, I
am wondering what is then, in your mind, the difference?

If there is no difference between ROLL routing and MANET routing other than
"ROLL wants to do exactly the same thing as MANET, only with 5 bytes of RAM
and 1 byte-per-second of control traffic", then this is interesting
research, but this is not ready for the IETF. MANET already has cared about
small "foot-print" solutions for more than a decade, and experience so far
has not given birth to a MANET solution with "5 bytes of RAM and 1
byte-per-second of control traffic". Thus, feasibility within 6 months or a
year (which is the ballpark here, if I am not mistaken?) is not obvious at
all.

If it is not the case, then please explain the difference between ROLL
routing and MANET routing in a better way, in order to stress the
feasibility of the goals.

Emmanuel

---

From: Mischa Dohler <[email-masked]>
Date: Wed, 07 Jan 2009 13:40:21 +0100

Ciao Emmanuel,

You may have a different view but for me the currently written docs in 
ROLL are a mere basis for discussion and harmonizer of "language" of 
people with very (!) different backgrounds. This has worked very well so 
far as we are starting to understand each other.

The discussion on the inclusion/exclusion of certain protocols is maybe 
best placed in the actual (or future version of the) survey document 
itself. I propose to you that the next email you write to ROLL 
(including a possible response to my email), you simply formalize your 
thoughts and add them in the respective sections of the document.

As for the goals of ROLL, they are very clearly formalized in the 
charter. As for routing solutions over L2Ns, there are some already 
available which trade quite well the constraints of said networks (not 
implying that they do everything we would expect them to do).

Do not neglect one major difference to MANET in that in ROLL not every 
node wants to talk to every node but traffic is rather convergecast from 
nodes to sink(s). The routing solution we developed profits very much 
from this insight and works well on 3 bytes of RAM (literally).

Regards from snowy Barcelona,
Mischa.

Emmanuel Baccelli wrote:
> Hi Phil, happy new year. 
> 
> 
> On Tue, Jan 6, 2009 at 6:46 PM, Philip Levis <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>         <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         Let's look at one example I was pointing to, the beginning of
>         the abstract of
>         http://tools.ietf.org/html/draft-thubert-tree-discovery-06 which
>         reads:
> 
>     with. Do you agree that the protocol described in
>     draft-thubert-tree-discovery-06 would require additional mechanisms
>     to support routing within an L2N?
> 
>     Phil
> 
> 
> 
> routing? The way I understood it, the difference was basically: ROLL 
> cares about identified, simplistic traffic patterns. Judging from what 
> you say, I am wondering what is then, in your mind, the difference?
> 
> If there is no difference between ROLL routing and MANET routing other 
> than "ROLL wants to do exactly the same thing as MANET, only with 5 
> bytes of RAM and 1 byte-per-second of control traffic", then this is 
> interesting research, but this is not ready for the IETF. MANET already 
> has cared about small "foot-print" solutions for more than a decade, and 
> experience so far has not given birth to a MANET solution with "5 bytes 
> of RAM and 1 byte-per-second of control traffic". Thus, feasibility 
> within 6 months or a year (which is the ballpark here, if I am not 
> mistaken?) is not obvious at all.
> 
> ------------------------------------------------------------------------
>

---

From: JP Vasseur <[email-masked]>
Date: Wed, 7 Jan 2009 14:37:22 +0100

Hi Emmanuel,

Happy new year too ... See in line,

On Jan 7, 2009, at 1:08 PM, Emmanuel Baccelli wrote:

> I thought that ROLL routing was about something more specific than  
> MANET routing? The way I understood it, the difference was  
> basically: ROLL cares about identified, simplistic traffic patterns.  
> Judging from what you say, I am wondering what is then, in your  
> mind, the difference?
>
> If there is no difference between ROLL routing and MANET routing  
> other than "ROLL wants to do exactly the same thing as MANET, only  
> with 5 bytes of RAM and 1 byte-per-second of control traffic", then  
> this is interesting research, but this is not ready for the IETF.  
> MANET already has cared about small "foot-print" solutions for more  
> than a decade, and experience so far has not given birth to a MANET  
> solution with "5 bytes of RAM and 1 byte-per-second of control  
> traffic". Thus, feasibility within 6 months or a year (which is the  
> ballpark here, if I am not mistaken?) is not obvious at all.
>

Although I strongly believe that discussion is always beneficial for  
the community, I also think that it is time to close on this, and this  
has been mentioned by several key WG members.

We (ROLL) are not chartered to discuss the differences between what we  
need to work on *and* MANET. Our charter is well specified and 4  
routing requirements with extensive discussion have been produced. So  
I would suggest to stop this counter productive discussion on ROLL  
versus MANET. If you need to better understand what we need to do  
please read the charter and the requirements documents.

It is now time to converge on the survey I-D, the aim of which (again)  
is to determine whether we can find an existing mature routing  
protocol (as defined today) that meet our specific and well documented  
routing requirements.

At this point, please very specific in what you want to see added to  
the document, which passed WG LC several weeks ago. We now need to  
quickly converge.

Thanks.

JP.

> If it is not the case, then please explain the difference between  
> ROLL routing and MANET routing in a better way, in order to stress  
> the feasibility of the goals.
>
> Emmanuel
>

---

From: Philip Levis <[email-masked]>
Date: Wed, 7 Jan 2009 13:24:25 -0800

On Jan 7, 2009, at 5:37 AM, JP Vasseur wrote:

>> You're right; it is a routing protocol. However, it only maintains  
>> a default route. It does not provide sufficient mechanisms for two  
>> with. Do you agree that the protocol described in draft-thubert- 
>> tree-discovery-06 would require additional mechanisms to support  
>> routing within an L2N?
>>
>> Phil
>>
>>
>> basically: ROLL cares about identified, simplistic traffic  
>> patterns. Judging from what you say, I am wondering what is then,  
>> in your mind, the difference?
>>
> the community, I also think that it is time to close on this, and  
> this has been mentioned by several key WG members.
>
> We (ROLL) are not chartered to discuss the differences between what  
> we need to work on *and* MANET. Our charter is well specified and 4  
> routing requirements with extensive discussion have been produced.  
> So I would suggest to stop this counter productive discussion on  
> ROLL versus MANET. If you need to better understand what we need to  
> do please read the charter and the requirements documents.
>
> It is now time to converge on the survey I-D, the aim of which  
> (again) is to determine whether we can find an existing mature  
> routing protocol (as defined today) that meet our specific and well  
> documented routing requirements.
>

Emmanuel, do you agree that draft-thubert-tree-discovery-06 is  
insufficient as it only maintains a default route? Pascal, do you agree?

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 8 Jan 2009 11:14:51 +0100

Hi: 

As an author of TD , RRH and NINA, which are all building blocks that can be used together with others (including existing MANET protocols) in a consistent mesh/mobile solution, I never suggested to get this work included in the survey because the survey rules were very clear from the start, and excluded unproven / non standardized work -  since MANEMO / NEMO RO drafts are simply I-Ds they were excluded by definition.

OTOH MANEMO did include sensor networks in the original proposal so I certainly hope that this work can be adapted for ROLL once ROLL is rechartered to work on solutions, which is not the case at this point of time. I waited a long time for NEMO to work on RO - RRH was published before NEMO was even formed as a group. I guess I can wait a little more. J

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of JP Vasseur (jvasseur)
Sent: mercredi 7 janvier 2009 14:37
To: Emmanuel Baccelli
Cc: ROLL WG
Subject: [Roll] ** Please read ** Re: Proposal so as to reach a consensus on** draft-ietf-roll-protocols-survey-02 **

Hi Emmanuel,

Hi Phil, happy new year. 

On Mon, Dec 29, 2008 at 11:10 PM, Philip Levis <[email-masked]> wrote:

If a protocol is not a routing protocol, then it can't meet the routing requirements.

Let's look at one example I was pointing to, the beginning of the abstract of http://tools.ietf.org/html/draft-thubert-tree-discovery-06 which reads:

if this is not a routing protocol, what is it? If this is not in scope, then I wonder what is.

By the way, I'm sure you'll agree that it makes more sense to evaluate this than to evaluate OSPF, in the context of ROLL...

Maybe the next version of the draft will contain a convincing explanation for these choices, but for now, I must say it still eludes me.

You're right; it is a routing protocol. However, it only maintains a default route. It does not provide sufficient mechanisms for two nodes within an L2N to communicate. So I guess it's *technically* a routing protocol, but not in the sense that the draft is concerned with. Do you agree that the protocol described in draft-thubert-tree-discovery-06 would require additional mechanisms to support routing within an L2N?

Phil

I thought that ROLL routing was about something more specific than MANET routing? The way I understood it, the difference was basically: ROLL cares about identified, simplistic traffic patterns. Judging from what you say, I am wondering what is then, in your mind, the difference?

If there is no difference between ROLL routing and MANET routing other than "ROLL wants to do exactly the same thing as MANET, only with 5 bytes of RAM and 1 byte-per-second of control traffic", then this is interesting research, but this is not ready for the IETF. MANET already has cared about small "foot-print" solutions for more than a decade, and experience so far has not given birth to a MANET solution with "5 bytes of RAM and 1 byte-per-second of control traffic". Thus, feasibility within 6 months or a year (which is the ballpark here, if I am not mistaken?) is not obvious at all.

Although I strongly believe that discussion is always beneficial for the community, I also think that it is time to close on this, and this has been mentioned by several key WG members. 

We (ROLL) are not chartered to discuss the differences between what we need to work on *and* MANET. Our charter is well specified and 4 routing requirements with extensive discussion have been produced. So I would suggest to stop this counter productive discussion on ROLL versus MANET. If you need to better understand what we need to do please read the charter and the requirements documents.

It is now time to converge on the survey I-D, the aim of which (again) is to determine whether we can find an existing mature routing protocol (as defined today) that meet our specific and well documented routing requirements.

At this point, please very specific in what you want to see added to the document, which passed WG LC several weeks ago. We now need to quickly converge.

Thanks.

JP.

If it is not the case, then please explain the difference between ROLL routing and MANET routing in a better way, in order to stress the feasibility of the goals.

Emmanuel

---

From: "Emmanuel Baccelli" <[email-masked]>
Date: Thu, 8 Jan 2009 11:34:35 +0100

>> At this point, please very specific in what you want to see added to the
>> document, which passed WG LC several weeks ago. We now need to quickly
>> converge.
>>
>>

OK, I'll be specific:

1- Everyone in the community agrees that no protocol (existing or near
future) will pass ALL the criterias chosen by the draft.
2- Requirements for ROLL are in fact more realistic, i.e. various SUBSETS of
all these criterias.

So in order to be unambiguous, the draft should thus explicitly spell out:

3- the different subsets of criterias that are in fact targeted,
4- the evaluation of applicable protocols for each targeted subset.

This way, I think we will indeed stop wasting time with this.

Emmanuel

---

From: JP Vasseur <[email-masked]>
Date: Thu, 8 Jan 2009 13:44:12 +0100

Hi Emmanuel,

What have we achieved so far ?

(1) We wrote a very detailed set of routing requirements (with MUST,  
SHOULD, ...) - lots of work from the WG.
(2) We reached a consensus on the fact that no existing mature routing  
protocol exist today that satisfy the requirements of ROLL.
(3) We also agreed that existing protocols (AODV, OLSR, ...) are NOT  
at all excluded as the set of candidates (with protocol extensions) -  
(see the discussion with Thomas)

When we got chartered, we have been tasked to see whether an existing  
routing protocol could satisfy our requirements. We could have taken  
the approach of considering all MUST, with subset on a per application  
basis, etc .. The WG rather decided to select a few (necessary but not  
sufficient) set of criterion derived from the requirements. The only  
objective of that I-D is to answer to this question.

Now, should ROLL be re-chartered to start some protocol work, there  
will obviously be several candidates to evaluate against the  
requirements (we will exclusively be using the routing requirements).  
This includes existing protocol with extensions and potentially new  
protocol.

Proposal
* Let's try to close on this I-D: hopefully, we managed to clarify the  
objective of that document (which might have been confusing and I  
understand your comments).
Steve told us that a new revision will be posted soon, addressing  
several comments including yours.
The objective is to send the I-D for IESG review by end of next week  
(we completed LC on Dec 5),
* Send the rechartering proposal to the IESG (new WG item: Start  
protocol work),
* Immediately start evaluating solutions (existing (with the help on  
the appropriate WGs) and potentially new ones) in light of the  
application specific routing requirements).
At that point, we may find out that more than one solution will be  
needed to satisfy the maximum number of MUST of application X and Y.  
We will figure this out at that point, but we of course first need to  
be re-chartered.

Can we agree on this plan ?

Thanks.

JP.

On Jan 8, 2009, at 11:34 AM, Emmanuel Baccelli wrote:

> 1- Everyone in the community agrees that no protocol (existing or  
> near future) will pass ALL the criterias chosen by the draft.
> 2- Requirements for ROLL are in fact more realistic, i.e. various  
> SUBSETS of all these criterias.
>

---

From: JP Vasseur <[email-masked]>
Date: Mon, 12 Jan 2009 08:58:23 +0100

resending .. we need to move on.

Many Thanks.

JP.

On Jan 8, 2009, at 1:44 PM, JP Vasseur wrote:

> (2) We reached a consensus on the fact that no existing mature  
> routing protocol exist today that satisfy the requirements of ROLL.
> at all excluded as the set of candidates (with protocol extensions)  
> - (see the discussion with Thomas)
>
> When we got chartered, we have been tasked to see whether an  
> existing routing protocol could satisfy our requirements. We could  
> have taken the approach of considering all MUST, with subset on a  
> per application basis, etc .. The WG rather decided to select a few  
> (necessary but not sufficient) set of criterion derived from the  
> requirements. The only objective of that I-D is to answer to this  
> question.
>
> requirements (we will exclusively be using the routing  
> requirements). This includes existing protocol with extensions and  
> potentially new protocol.
>
> Proposal
> * Let's try to close on this I-D: hopefully, we managed to clarify  
> the objective of that document (which might have been confusing and  
> I understand your comments).
> We will figure this out at that point, but we of course first need  
> to be re-chartered.
>
>> At this point, please very specific in what you want to see added  
>> to the document, which passed WG LC several weeks ago. We now need  
>> to quickly converge.
>>
>>
>>
>> OK, I'll be specific:
>>

---

From: "Emmanuel Baccelli" <[email-masked]>
Date: Mon, 12 Jan 2009 11:51:17 +0100

On Mon, Jan 12, 2009 at 8:58 AM, JP Vasseur <[email-masked]> wrote:

> (3) We also agreed that existing protocols (AODV, OLSR, ...) are NOT at all
> excluded as the set of candidates (with protocol extensions) - (see the
> discussion with Thomas)
>
> routing protocol could satisfy our requirements. We could have taken the
> approach of considering all MUST, with subset on a per application basis,
> etc .. The WG rather decided to select a few (necessary but not sufficient)
> set of criterion derived from the requirements. The only objective of that
> I-D is to answer to this question.
>
> Now, should ROLL be re-chartered to start some protocol work, there will
> obviously be several candidates to evaluate against the requirements *(we
> will exclusively be using the routing requirements)*. This includes
> existing protocol with extensions and potentially new protocol.
>
> Proposal
> objective of that document (which might have been confusing and I understand
> your comments).
> Steve told us that a new revision will be posted soon, addressing several
> comments including yours.
> The objective is to send the I-D for IESG review by end of next week (we
> completed LC on Dec 5),
> * Send the rechartering proposal to the IESG (new WG item: Start protocol
> work),
> * Immediately start evaluating solutions (existing (with the help on the
> appropriate WGs) and potentially new ones) in light of the application
> specific routing requirements).
> At that point, we may find out that more than one solution will be needed
> to satisfy the maximum number of MUST of application X and Y. We will figure
> this out at that point, but we of course first need to be re-chartered.
>
> 2- Requirements for ROLL are in fact more realistic, i.e. various SUBSETS
> of all these criterias.
>
I am also looking forward to the next version of the draft. I have already
signaled all of what I thought was important to mention, in order to get a
useful document for the next phase of ROLL: identifying solutions for the
sets of requirements described in the requirement drafts. I am looking
forward to participating.
cheers,
Emmanuel
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: JP Vasseur <[email-masked]>
Date: Mon, 12 Jan 2009 14:44:53 +0100

On Jan 12, 2009, at 11:51 AM, Emmanuel Baccelli wrote:

>> (1) We wrote a very detailed set of routing requirements (with  
>> MUST, SHOULD, ...) - lots of work from the WG.
>> (3) We also agreed that existing protocols (AODV, OLSR, ...) are  
>> NOT at all excluded as the set of candidates (with protocol  
>> extensions) - (see the discussion with Thomas)
>>
>> The objective is to send the I-D for IESG review by end of next  
>> week (we completed LC on Dec 5),
>> * Immediately start evaluating solutions (existing (with the help  
>> on the appropriate WGs) and potentially new ones) in light of the  
>> needed to satisfy the maximum number of MUST of application X and  
>> Y. We will figure this out at that point, but we of course first  
>> need to be re-chartered.
>>
> I am also looking forward to the next version of the draft. I have  
> already signaled all of what I thought was important to mention, in  
> order to get a useful document for the next phase of ROLL:  
> identifying solutions for the sets of requirements described in the  
> requirement drafts. I am looking forward to participating.
> cheers,

off-line ... c'est pas exactement ce que je proposais ... donc tu n'es  
pas OK avec le plan propose ? Car la prochaine version est la derniere  
(pas LC).

Merci.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Mon, 12 Jan 2009 14:48:03 +0100

sorry for the "French Part". What I wrote was ... "thus you do not  
agree with the proposed plan ?"

On Jan 12, 2009, at 2:44 PM, JP Vasseur wrote:

>>> per application basis, etc .. The WG rather decided to select a  
>>> few (necessary but not sufficient) set of criterion derived from  
>>> the requirements. The only objective of that I-D is to answer to  
>>> this question.
>>>
>>> Now, should ROLL be re-chartered to start some protocol work,  
>>> there will obviously be several candidates to evaluate against the  
>>> the objective of that document (which might have been confusing  
>>> and I understand your comments).
>>>> to the document, which passed WG LC several weeks ago. We now  
>>>> need to quickly converge.
>>>>
>>>>
>>>>
>>>> OK, I'll be specific:
>>>>
> off-line ... c'est pas exactement ce que je proposais ... donc tu  
> n'es pas OK avec le plan propose ? Car la prochaine version est la  
> derniere (pas LC).
>
> Merci.
>
> JP.
>
>> Emmanuel
>>

---

From: "Emmanuel Baccelli" <[email-masked]>
Date: Mon, 12 Jan 2009 15:54:22 +0100

Sorry about the misunderstanding. I do not disagree with the plan. What I
meant was: I am looking forward to the revision of the draft, and to after
rechartering. My comments will be properly logged anyways, even if they are
not taken into account ;)
This document may be ill-conceived, but for me it does not alter the
consensus on the fact that something specific (at least an extension of an
existing protocol) needs to be standardized for ROLL. Hence it does not
alter the fact that rechartering is needed along the lines you proposed.

cheers
Emmanuel

On Mon, Jan 12, 2009 at 2:48 PM, JP Vasseur <[email-masked]> wrote:

> sorry for the "French Part". What I wrote was ... "thus you do not agree
> with the proposed plan ?"
>
>> (3) We also agreed that existing protocols (AODV, OLSR, ...) are NOT at
>> all excluded as the set of candidates (with protocol extensions) - (see the
>> discussion with Thomas)
>>
> off-line ... c'est pas exactement ce que je proposais ... donc tu n'es pas
> OK avec le plan propose ? Car la prochaine version est la derniere (pas LC).
>
> Merci.
>
> JP.
>
> Emmanuel
>

---

From: JP Vasseur <[email-masked]>
Date: Mon, 12 Jan 2009 17:15:38 +0100

Hi Emmanuel,

On Jan 12, 2009, at 3:54 PM, Emmanuel Baccelli wrote:

> Sorry about the misunderstanding. I do not disagree with the plan.

OK great.

> What I meant was: I am looking forward to the revision of the draft,  
> and to after rechartering.

Excellent.

> My comments will be properly logged anyways, even if they are not  
> taken into account ;)
>
> consensus on the fact that something specific (at least an extension  
> of an existing protocol) needs to be standardized for ROLL. Hence it  
> does not alter the fact that rechartering is needed along the lines  
> you proposed.
>

Thanks for the comments.

Cheers.

JP.

>>>> existing routing protocol could satisfy our requirements. We  
>>>> could have taken the approach of considering all MUST, with  
>>>> subset on a per application basis, etc .. The WG rather decided  
>>>> to select a few (necessary but not sufficient) set of criterion  
>>>> derived from the requirements. The only objective of that I-D is  
>>>> to answer to this question.
>>>>
>>>> there will obviously be several candidates to evaluate against  
>>>> the requirements (we will exclusively be using the routing  
>>>> requirements). This includes existing protocol with extensions  
>>>> and potentially new protocol.
>>>>
>>>> Proposal
>>>> * Let's try to close on this I-D: hopefully, we managed to  
>>>> clarify the objective of that document (which might have been  
>>>> confusing and I understand your comments).
>>>> At that point, we may find out that more than one solution will  
>>>> be needed to satisfy the maximum number of MUST of application X  
>>>> and Y. We will figure this out at that point, but we of course  
>>>> first need to be re-chartered.
>>>>
>>>>> At this point, please very specific in what you want to see  
>>>>> added to the document, which passed WG LC several weeks ago. We  
>>>>> now need to quickly converge.
>>>>>
>>>>>
>>>>>
>>>>> OK, I'll be specific:
>>>>>
>>>>> 1- Everyone in the community agrees that no protocol (existing  
>>>>> or near future) will pass ALL the criterias chosen by the draft.
>>>>> 2- Requirements for ROLL are in fact more realistic, i.e.  
>>>>> various SUBSETS of all these criterias.
>>>>>
>>> already signaled all of what I thought was important to mention,  
>>> in order to get a useful document for the next phase of ROLL:  
>>> identifying solutions for the sets of requirements described in  
>>> the requirement drafts. I am looking forward to participating.
>>> cheers,
>>

---

From: "David E. Culler" <[email-masked]>
Date: Mon, 12 Jan 2009 09:54:32 -0800

I think that you said "Yes, this ID can go forward".  (I got lost in
the multi-negatives.)

Emmanuel Baccelli wrote:

Sorry about the misunderstanding. I do not disagree with
the plan. What I meant was: I am looking forward to the revision of the
draft, and to after rechartering. My comments will be properly logged
anyways, even if they are not taken into account ;)

This document may be ill-conceived, but for me it does not alter
the consensus on the fact that something specific (at least an
extension of an existing protocol) needs to be standardized for ROLL.
Hence it does not alter the fact that rechartering is needed along the
lines you proposed.

cheers

Emmanuel

On Mon, Jan 12, 2009 at 2:48 PM, JP Vasseur <[email-masked]>
wrote:

sorry for the "French Part". What I wrote was ...
"thus you do not agree with the proposed plan ?"

On Mon, Jan 12, 2009 at 8:58 AM, JP
Vasseur <[email-masked]>
wrote:

Many Thanks.

JP.

Hi Emmanuel,

(1) We wrote a very detailed set of routing
requirements (with MUST, SHOULD, ...) - lots of work from the WG.

(2) We reached a consensus on the fact that no
existing mature routing protocol exist today that satisfy the
requirements of ROLL.

(3) We also agreed that existing protocols (AODV,
OLSR, ...) are NOT at all excluded as the set of candidates (with
protocol extensions) - (see the discussion with Thomas)

When we got chartered, we have been tasked to
see whether an existing routing protocol could satisfy our
requirements. We could have taken the approach of considering all MUST,
with subset on a per application basis, etc .. The WG rather decided to
select a few (necessary but not sufficient) set of criterion derived
from the requirements. The only objective of that I-D is to answer to
this question.

Now, should ROLL be re-chartered to start some
protocol work, there will obviously be several candidates to evaluate
against the requirements (we will exclusively be using the routing
requirements). This includes existing protocol with extensions and
potentially new protocol.

Proposal

* Let's try to close on this I-D: hopefully, we
managed to clarify the objective of that document (which might have
been confusing and I understand your comments).

Steve told us that a new revision will be posted soon,
addressing several comments including yours.

The objective is to send the I-D for IESG review by
end of next week (we completed LC on Dec 5),

* Send the rechartering proposal to the IESG (new WG
item: Start protocol work),

* Immediately start evaluating solutions (existing
(with the help on the appropriate WGs) and potentially new ones) in
light of the application specific routing requirements).

At that point, we may find out that more than one
solution will be needed to satisfy the maximum number of MUST of
application X and Y. We will figure this out at that point, but we of
course first need to be re-chartered.

Thanks.

JP.

OK, I'll be specific:

1- Everyone in the community agrees that no protocol
(existing or near future) will pass ALL the criterias chosen by the
draft.

2- Requirements for ROLL are in fact more realistic,
i.e. various SUBSETS of all these criterias.

So in order to be unambiguous, the draft should thus
explicitly spell out:

3- the different subsets of criterias that are in
fact targeted,

4- the evaluation of applicable protocols for each
targeted subset.

This way, I think we will indeed stop wasting time
with this.

Emmanuel

I am also looking forward to the next version of the
draft. I have already signaled all of what I thought was important to
mention, in order to get a useful document for the next phase of ROLL:
identifying solutions for the sets of requirements described in the
requirement drafts. I am looking forward to participating.

cheers,

off-line ... c'est pas exactement ce que je proposais ...
donc tu n'es pas OK avec le plan propose ? Car la prochaine version est
la derniere (pas LC).

Merci.

JP.

Emmanuel

Roll mailing list

[email-masked]

Roll mailing list

[email-masked]

---

From: "Miguel Sánchez" <[email-masked]>
Date: Mon, 12 Jan 2009 20:07:18 +0100

It was not only you David :-)

Cheers,

Miguel Sanchez

On Mon, Jan 12, 2009 at 6:54 PM, David E. Culler
<[email-masked]>wrote:

>  I think that you said "Yes, this ID can go forward".  (I got lost in the
> multi-negatives.)
>
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 13 Jan 2009 04:30:30 +0100

I'm not Emmanuel :) but I'd like to actually *read* the updated I-D  
before pronouncing myself on if the I-D can go forward.

My position is that a lot of people have given a lot of good feedback  
to the current I-D, and that the WG chairs and authors have responded  
with "Ok, we'll produce an update based on this feedback".

I appreciate that position, and have all the confidence that the  
authors will try to capture the feedback in their update as best they  
can. I think that it'd be unfair to the authors to not await and  
review this I-D before saying "yes" or "no".

I've been sitting quiet for a while, since I felt that I had given  
air to my concerns and that those were being listened to (even if not  
agreed with :) ) so repeating myself would not be helpful until an  
updated I-D was out.

As soon as a new I-D hits the servers, I shall jump on a review. I  
would, however, suggest if a bit more than a week of review time is  
allowed before the I-D is being sent to the IESG: I think that it'd  
be better if any concerns are aired and addressed within the WG  
rather than linger and have to be raised (and potentially cause  
problems) elsewhere within the circuit. A week is really short, and a  
lot of issues have been raised. I, for one, am traveling - writing  
this email from a hotel room in Beijing - and still want to give this  
document the cycles it, and the authors, deserve.

Sounds fair enough, no?

Thomas

On Jan 12, 2009, at 18:54 PM, David E. Culler wrote:

> I think that you said "Yes, this ID can go forward".  (I got lost  
> in the multi-negatives.)
>
> Emmanuel Baccelli wrote:
>>
>> What I meant was: I am looking forward to the revision of the  
>> draft, and to after rechartering. My comments will be properly  
>> logged anyways, even if they are not taken into account ;)
>>
>> extension of an existing protocol) needs to be standardized for  
>> ROLL. Hence it does not alter the fact that rechartering is needed  
>> along the lines you proposed.
>>
>> cheers
>> Emmanuel
>>
>>
>>>>> (3) We also agreed that existing protocols (AODV, OLSR, ...)  
>>>>> are NOT at all excluded as the set of candidates (with protocol  
>>>>> derived from the requirements. The only objective of that I-D  
>>>>> is to answer to this question.
>>>>>
>>>>> * Send the rechartering proposal to the IESG (new WG item:  
>>>>> Start protocol work),
>>>>> * Immediately start evaluating solutions (existing (with the  
>>>>> help on the appropriate WGs) and potentially new ones) in light  
>>>>> of the application specific routing requirements).
>>>>> be needed to satisfy the maximum number of MUST of application  
>>>>> X and Y. We will figure this out at that point, but we of  
>>>>>> added to the document, which passed WG LC several weeks ago.  
>>>>>> We now need to quickly converge.
>>>>>>
>>>>>>
>>>>>>
>>>>>> OK, I'll be specific:
>>>>>>
>>>> I am also looking forward to the next version of the draft. I  
>>>> have already signaled all of what I thought was important to  
>>>> mention, in order to get a useful document for the next phase of  
>>>> ROLL: identifying solutions for the sets of requirements  
>>>> described in the requirement drafts. I am looking forward to  
>>>> participating.
>>>> cheers,
>>>
>>> n'es pas OK avec le plan propose ? Car la prochaine version est  
>>> la derniere (pas LC).
>>>
>>> Merci.
>>>
>>> JP.
>>>
>>>> Emmanuel
>>>>

---

From: Philip Levis <[email-masked]>
Date: Mon, 12 Jan 2009 19:38:12 -0800

On Jan 12, 2009, at 7:30 PM, Thomas Heide Clausen wrote:

> My position is that a lot of people have given a lot of good  
> feedback to the current I-D, and that the WG chairs and authors have  
> responded with "Ok, we'll produce an update based on this feedback".
>
> authors will try to capture the feedback in their update as best  
> they can. I think that it'd be unfair to the authors to not await  
> and review this I-D before saying "yes" or "no".
>
> air to my concerns and that those were being listened to (even if  
> not agreed with :) ) so repeating myself would not be helpful until  
> an updated I-D was out.
>
> problems) elsewhere within the circuit. A week is really short, and  
> a lot of issues have been raised. I, for one, am traveling - writing  
> this email from a hotel room in Beijing - and still want to give  
> this document the cycles it, and the authors, deserve.
>
> Sounds fair enough, no?

I'll try to get the new version out tonight. Stephen and Arsalan have  
addressed almost all of the comments in our working copy; I just need  
to make a few last changes.

Phil

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 13 Jan 2009 04:43:11 +0100

Phil,

Sounds excellent, I'm looking forward to reviewing the update. Thanks  
in advance for your efforts (all of you) - I know that getting an  
avalanche of feedback and trying to make sense and structure of it is  
really hard work.

Cheers,

Thomas

On Jan 13, 2009, at 04:38 AM, Philip Levis wrote:

>> I'm not Emmanuel :) but I'd like to actually *read* the updated I- 
>> D before pronouncing myself on if the I-D can go forward.
>>
>> feedback to the current I-D, and that the WG chairs and authors  
>> have responded with "Ok, we'll produce an update based on this  
>> feedback".
>>
>> not agreed with :) ) so repeating myself would not be helpful  
>> until an updated I-D was out.
>>
>> would, however, suggest if a bit more than a week of review time  
>> is allowed before the I-D is being sent to the IESG: I think that  
>> it'd be better if any concerns are aired and addressed within the  
>> WG rather than linger and have to be raised (and potentially cause  
>> problems) elsewhere within the circuit. A week is really short,  
>> and a lot of issues have been raised. I, for one, am traveling -  
>> writing this email from a hotel room in Beijing - and still want  
>> to give this document the cycles it, and the authors, deserve.
>>
>> Sounds fair enough, no?
>
> I'll try to get the new version out tonight. Stephen and Arsalan  
> have addressed almost all of the comments in our working copy; I  
> just need to make a few last changes.
>
> Phil
>