Subject: [Roll] draft-ietf-roll-protocols-survey-00

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 24 Aug 2008 13:13:46 +0100

Hi,

As one of the two tourists who raised a hand in Dublin to express uneasiness 
about this I-D becoming a WG draft, I thought I should write a note about my 
concerns.

I should caveat this by saying that I do appreciate the need for this work, 
and that the author-team will, I'm sure, do a fine job at delivering what 
the working group needs. My concerns were much more about getting the 
direction of the I-D right before accepting it as I think it is often harder 
to recast an I-D once it is within the working group.

Below, please find my major discussion point. I have also done a review of 
the draft and found a bunch of issues/questions of more minor importance.

Regards,
Adrian

===

The analysis of the routing protocols is predicated on what they are 
currently used for. To some extent this is reasonable - the easiest analysis 
of a routing protocol is in its operational environment. But to use this 
analysis as the basis of a decision for use of a protocol in a new 
environment is not so reasonable. If you want to show that none of today's 
protocols has been designed for use in the ROLL environment, then I don't 
suppose anyone will be surprised. However, what we are really interested in 
is whether any of the existing protocols is suitable for adaptation for use 
in ROLL, whether the those adaptations would be contrived and technically 
hard (or flaky), and whether it would be more efficient to design a new 
protocol.

For an example (and I'm not proposing this as the solution for ROLL), an IGP 
could easily be adapted to flood on only certain links, to discard certain 
LSAs, and to build a FIB according to specific rules. This would not be a 
large change to the protocol, although it would obviously not be 
interoperable.

To discard from consideration any protocol based on its behavior in a 
certain environment without setting it in the context of your forwarding 
paradigm and without examining the potential to adapt a protocol to that 
environment is wrong. If all you wanted to do was show that no current 
variant of any existing routing protocol is immediately applicable to ROLL, 
then that would be easy and would not be a surprise. But to imply that 
protocols are not open for adaptation is more serious.

This is not to say that inventing a new protocol would be wrong or not fun. 
Only that your reasons for discarding protocols are poorly founded. You have 
focused on the operation of the routing protocol, not the purpose of the 
routing protocol. To give a better understanding of why you are discarding a 
protocol, you must show what you want to achieve as your forwarding 
paradigm. The requirements documents make some start at this. For example, 
draft-ietf-roll-urban-routing-reqs talks about:
- routing to minimise power usage
- routing to consider node and link capabilities
- routing protocol to scale within CPU, memory and power limits
- routing according to different metrics (latency is cited)

Such considerations are a good start to understanding the forwarding 
paradigm in ROLL, but would not be good enough to use to devise a new 
routing protocol, so I don't see how they can be good enough to determine 
whether an existing protocol should be discarded, modified, or used.

=============

More specific comments on the draft follow.

---

Do we have a commitment from the WG that any new protocol developed will be 
held to the same standards? That is, that the new protocol MUST achieve a 
"pass" in very column of the table in section 4. Or is there scope for 
pragmatism allowing trade-offs in the new protocol such that in some 
environments it achieves a pass in some columns, and in other environments 
it achieves a pass in other columns.

Maybe you could add this as a statement in the Abstract and Introduction

---

Why do you include the requirements language boilerplate? I don't think you 
use (or should use) such language in this document.

---

Section 1

Can you strip out terms not used in the document?

---

Section 2

You quote CPU power in MHz. Although that is the practical electronic limit, 
maybe MIPS would be a better measure.

---

Section 3 para 2

"If a protocol cannot meet even these minimalist criteria..."
I think your use of "cannot" is correct in the context of the sentence, but 
I think your I-D examines "does not"

"...is unlikely to be good candidate..."
Too much prevarication!

---

Section 3 para 3

"...the protocol does not appear to contain sufficient flexibility..."
The problem with this is that it is very mushy!
It is OK to discard a protocol that is not flexible enough to handle your 
requirements. It is not OK to discard a protocol because you don't appear to 
know how to extend it.

A example comes in the somewhat contentious table in section 4 :-)
Here, for OSPF, you say that there is a "fail" for conveying node costs.
But there is already LSA available for carrying node capabilities, and there 
are opaque LSAs available for carrying additional "unconventional" 
information.

All this sort of ties to my main point. Of course, the protocols don't do 
exactly what you want already, but a more thorough survey is needed if you 
what to use this I-D as the reason for excluding protocols.

---

Section 3.2 para 1
"...with size ranging from a minimum..."
I think you mean "...with maximum size ranging from a minimum..."

"very large networks"
Can you de-fluff this? Some people might think that 250 nodes is very large 
;-)

"network depths"
Would be worth including your definition here.

--

Section 3.2 para 1

Is every network node a router? draft-ietf-roll-urban-routing-reqs says 
"Sensor nodes are capable of forwarding data." If every node is a router and 
participates in the routing protocol, this creates a very different 
environment from saying that most sensors are hosts, and some are routers. I 
appreciate that "capable" does not imply "do".

---

Associated with the previous point, I think you might spend a little more 
time discussing the definition of a link in ROLL. It is clear that in a 
wireless n/w a link may exist between any two nodes in range. If that is 
what you mean, then it would help to make it clear. On the other hand, 
"link" could be defined as an active neighbor relationship between a pair of 
routers. Or something else.

This becomes important as we try to understand how the protocol must scale, 
and what it is supposed to do.

I presume that the concept of "parallel links" between neighbors is going to 
have no meaning at the moment. That is, you use only one frequency in any 
network. Maybe I presume wrong, in which case, you need to refine the 
definition of "network density" in section 3.1.

---

Section 3.2 para 1
Final sentence is a bit mangled.

---

Section 3.2 para 2

I can see why scaling with O(L) may be an issue, but it may depend on the 
definitions of links and routers. Also it may depend on what magnitude you 
expect for L. Perhaps you could give some ball-parks in the previous 
paragraph as you do for N and D. Without that, it is hard to justify the 
claim that scaling with O(L) is a problem.

---

Section 3.3

Can you add SINR to your terminology?

"...not trigger unnecessary responses..."
I think that this is subjective and unhelpful. Can you rephrase to capture a 
quantifiable requirement?

s/link changes to propagate across/link changes to be propagated across/

s/O(l)/O(L)/

---

Section 3.3 final para

You have "transmissions", "broadcast", and "route updates". Can you use a 
consistent term? It may be less pretty English, but it would be a better way 
to avoid accusations of bias :-)

Perhaps...
More precisely, loss responses that require transmissions within the network 
of O(N) fail, while those that are limited to O(L) or O(D) pass.

---

Section 3.4 para 1

"In terms of routing structure, any proposed L2N routing protocol ought to 
support the autonomous organization and configuration of the network at the 
lowest possible energy cost."

Why "L2N"? I thought "Networks of low power wireless devices introduce novel 
IP routing issues."

"ought" is not a recognized RFC 2119 word :-)

I think "at the lowest possible energy cost" is a statement that this 
requirement trumps all others. Is that what you mean?

I'm not convinced by the absolute statement you make here. Maybe, this is a 
question I should take to the requirements documents. Consider routing 
protocol A that is slightly more (say 5%) power-consuming than routing 
protocol B. But suppose protocol A gives rise to a data forwarding solution 
that is 50% more power-efficient?

---

Section 3.4 para 2

"As low-power wireless networks can have very low data rates, protocols 
which require a minimum control packet rate can have unbounded control 
overhead."

I know what you mean, but I had to parse several times. How about...

The control overhead is the ratio of control data to payload data. A high 
control overhead indicates that precious network resources (bandwidth, 
power, or CPU) are being consumed by the control protocols instead of being 
used to transmit data. Where payload data rates are very low (as is often 
the case in low-power wireless networks) the control overhead can become 
unbounded for protocols that require some non-zero background control packet 
rate.

---

Section 3.4 para 2

s/never meet the condition can be forced/never meet the condition could be 
forced/

---

Section 4 para 3

"multiple layer 2 hops away"
Really?
Again, I thought we were building an IP routing protocol. If your 
requirement is layer 2 routing, you need to make that visible up front.
But, I can see why you are interested in L2 hops as well as L3 hops since 
they all consume power.

This comes back to the question about whether all nodes are routers. Perhaps 
some repeaters are not routers?

But can't we actually factor the L2 hops into the definition of the L3 hop?

---

Section 4 para 3

"...nodes may only advertise..."
This sounds prohibitive!

---

Section 4 para 4

"Neighbor discovery is a critical component of any routing protocol."
I think I disagree.
It is clear that routing protocols need to know their neighbors. It is not 
clear that this requires that the discovery be part of the routing protocol.

Later you have:
"...key component of many protocols."
This is less strong than the initial sentence.

---

Section 4

"Protocols Today"

Is this a section 4.1 headers?

---

Section 4 "Protocols Today" para 2

I don't think the MPLS TE example is a good one. It is certainly not correct 
that the TED has to be fully distributed around the network.
There are some very good examples of where "stub TE areas" do not need to 
know the TE information for the whole of the rest of the network.

---

Section 4 Table

I'm prepared to bet that a lot of people will be upset by the use of "fail" 
for their favorite protocols. It would seem that "?" is more appropriate in 
many cells.

---

Section 5.1
Is it worth replacing "OSPF" with "OSPF or IS-IS"?

---

Section 14.
Your three ROLL requirements drafts are Normative References, I think. 

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

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 25 Aug 2008 09:13:27 -0700

Adrian,

An excellent note - I agree completely.  We need fewer routing
protocols, not more.

Thanks,

John

>-----Original Message-----
>From: Adrian Farrel [mailto:[email-masked]] 
>Sent: Sunday, August 24, 2008 5:14 AM
>To: [email-masked]
>Subject: [Roll] draft-ietf-roll-protocols-survey-00
>
>Hi,
>
>As one of the two tourists who raised a hand in Dublin to 
>express uneasiness about this I-D becoming a WG draft, I 
>thought I should write a note about my concerns.
>
>I should caveat this by saying that I do appreciate the need 
>for this work, and that the author-team will, I'm sure, do a 
>fine job at delivering what the working group needs. My 
>concerns were much more about getting the direction of the I-D 
>right before accepting it as I think it is often harder to 
>recast an I-D once it is within the working group.
>
>Below, please find my major discussion point. I have also done 
>a review of the draft and found a bunch of issues/questions of 
>more minor importance.
>
>Regards,
>Adrian
>
>===
>
>The analysis of the routing protocols is predicated on what 
>they are currently used for. To some extent this is reasonable 
>- the easiest analysis of a routing protocol is in its 
>operational environment. But to use this analysis as the basis 
>of a decision for use of a protocol in a new environment is 
>not so reasonable. If you want to show that none of today's 
>protocols has been designed for use in the ROLL environment, 
>then I don't suppose anyone will be surprised. However, what 
>we are really interested in is whether any of the existing 
>protocols is suitable for adaptation for use in ROLL, whether 
>the those adaptations would be contrived and technically hard 
>(or flaky), and whether it would be more efficient to design a 
>new protocol.
>
>For an example (and I'm not proposing this as the solution for 
>ROLL), an IGP could easily be adapted to flood on only certain 
>links, to discard certain LSAs, and to build a FIB according 
>to specific rules. This would not be a large change to the 
>protocol, although it would obviously not be interoperable.
>
>To discard from consideration any protocol based on its 
>behavior in a certain environment without setting it in the 
>context of your forwarding paradigm and without examining the 
>potential to adapt a protocol to that environment is wrong. If 
>all you wanted to do was show that no current variant of any 
>existing routing protocol is immediately applicable to ROLL, 
>then that would be easy and would not be a surprise. But to 
>imply that protocols are not open for adaptation is more serious.
>
>Only that your reasons for discarding protocols are poorly 
>founded. You have focused on the operation of the routing 
>protocol, not the purpose of the routing protocol. To give a 
>better understanding of why you are discarding a protocol, you 
>must show what you want to achieve as your forwarding 
>paradigm. The requirements documents make some start at this. 
>For example, draft-ietf-roll-urban-routing-reqs talks about:
>Such considerations are a good start to understanding the 
>forwarding paradigm in ROLL, but would not be good enough to 
>use to devise a new routing protocol, so I don't see how they 
>can be good enough to determine whether an existing protocol 
>should be discarded, modified, or used.
>
>=============
>
>Do we have a commitment from the WG that any new protocol 
>developed will be held to the same standards? That is, that 
>the new protocol MUST achieve a "pass" in very column of the 
>table in section 4. Or is there scope for pragmatism allowing 
>trade-offs in the new protocol such that in some environments 
>it achieves a pass in some columns, and in other environments 
>Why do you include the requirements language boilerplate? I 
>don't think you use (or should use) such language in this document.
>
>---
>
>Section 1
>
>You quote CPU power in MHz. Although that is the practical 
>electronic limit, maybe MIPS would be a better measure.
>
>---
>
>Section 3 para 2
>
>I think your use of "cannot" is correct in the context of the 
>sentence, but I think your I-D examines "does not"
>
>It is OK to discard a protocol that is not flexible enough to 
>handle your requirements. It is not OK to discard a protocol 
>because you don't appear to know how to extend it.
>
>A example comes in the somewhat contentious table in section 4 
>:-) Here, for OSPF, you say that there is a "fail" for 
>conveying node costs.
>But there is already LSA available for carrying node 
>capabilities, and there are opaque LSAs available for carrying 
>additional "unconventional" 
>information.
>
>All this sort of ties to my main point. Of course, the 
>protocols don't do exactly what you want already, but a more 
>thorough survey is needed if you what to use this I-D as the 
>reason for excluding protocols.
>
>---
>
>Section 3.2 para 1
>Is every network node a router? 
>draft-ietf-roll-urban-routing-reqs says "Sensor nodes are 
>capable of forwarding data." If every node is a router and 
>participates in the routing protocol, this creates a very 
>different environment from saying that most sensors are hosts, 
>and some are routers. I appreciate that "capable" does not imply "do".
>
>---
>

---

From: JP Vasseur <[email-masked]>
Date: Wed, 27 Aug 2008 11:23:56 +0200

John,

I do not think that this was Adrian's point. Your feed-back is more than
welcome but please argue a bit more ...

Thanks.

JP.

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 27 Aug 2008 07:45:21 -0700

JP,

I thought that was exactly Adrian's point.

If you evaluate a bunch of routing protocols as they exist today in a
new operational environment and conclude that none of them are
appropriate, then you have no choice but to conclude that you need to
invent at least one, but probably many, new routing protocols.  It's not
like this hasn't been done before.

I took Adrian's note to say that doing this is not sufficient and that
what needed to be done was to characterize the new operational
environment, propose changes needed in each routing protocol to address
the new operational environment, and then evaluate these changes.

Thanks,

John 

>From: JP Vasseur [mailto:[email-masked]] 
>Sent: Wednesday, August 27, 2008 2:24 AM
>To: Drake, John E; Adrian Farrel; [email-masked]
>Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00
>
>John,
>
>I do not think that this was Adrian's point. Your feed-back is 
>more than welcome but please argue a bit more ...
>
>Thanks.
>
>JP.
>
>
>>> As one of the two tourists who raised a hand in Dublin to express 
>>> uneasiness about this I-D becoming a WG draft, I thought I should 
>>> write a note about my concerns.
>>> 
>>> I should caveat this by saying that I do appreciate the 
>need for this 
>>> work, and that the author-team will, I'm sure, do a fine job at 
>>> delivering what the working group needs. My concerns were much more 
>>> about getting the direction of the I-D right before 
>accepting it as I 
>>> think it is often harder to recast an I-D once it is within the 
>>> working group.
>>> 
>>> Below, please find my major discussion point. I have also done a 
>>> review of the draft and found a bunch of issues/questions of more 
>>> minor importance.
>>> 
>>> Regards,
>>> Adrian
>>> 
>>> ===
>>> 
>they are 
>>> currently used for. To some extent this is reasonable
>>> - the easiest analysis of a routing protocol is in its operational 
>>> environment. But to use this analysis as the basis of a 
>decision for 
>>> use of a protocol in a new environment is not so reasonable. If you 
>>> want to show that none of today's protocols has been 
>designed for use 
>>> in the ROLL environment, then I don't suppose anyone will be 
>>> surprised. However, what we are really interested in is whether any 
>>> of the existing protocols is suitable for adaptation for 
>use in ROLL, 
>>> whether the those adaptations would be contrived and 
>technically hard 
>>> (or flaky), and whether it would be more efficient to design a new 
>>> protocol.
>>> 
>>> For an example (and I'm not proposing this as the solution 
>for ROLL), 
>>> an IGP could easily be adapted to flood on only certain links, to 
>>> discard certain LSAs, and to build a FIB according to 
>specific rules. 
>>> This would not be a large change to the protocol, although it would 
>>> obviously not be interoperable.
>>> 
>behavior in a 
>>> certain environment without setting it in the context of your 
>>> forwarding paradigm and without examining the potential to adapt a 
>>> protocol to that environment is wrong. If all you wanted to do was 
>>> show that no current variant of any existing routing protocol is 
>>> immediately applicable to ROLL, then that would be easy and 
>would not 
>>> be a surprise. But to imply that protocols are not open for 
>>> adaptation is more serious.
>>> 
>>> Only that your reasons for discarding protocols are poorly founded. 
>>> You have focused on the operation of the routing protocol, not the 
>>> purpose of the routing protocol. To give a better understanding of 
>>> why you are discarding a protocol, you must show what you want to 
>>> achieve as your forwarding paradigm. The requirements 
>documents make 
>>> some start at this.
>forwarding 
>>> routing protocol, so I don't see how they can be good enough to 
>>> determine whether an existing protocol should be discarded, 
>modified, 
>>> or used.
>>> 
>>> =============
>>> 
>>> Do we have a commitment from the WG that any new protocol developed 
>>> will be held to the same standards? That is, that the new protocol 
>>> MUST achieve a "pass" in very column of the table in 
>section 4. Or is 
>>> there scope for pragmatism allowing trade-offs in the new protocol 
>>> such that in some environments it achieves a pass in some columns, 
>>> and in other environments it achieves a pass in other columns.
>>> 
>>> Why do you include the requirements language boilerplate? I don't 
>>> think you use (or should use) such language in this document.
>>> 
>>> ---
>>> 
>>> Section 1
>>> 
>electronic 
>>> limit, maybe MIPS would be a better measure.
>>> 
>>> ---
>>> 
>>> Section 3 para 2
>>> 
>>> It is OK to discard a protocol that is not flexible enough 
>to handle 
>>> your requirements. It is not OK to discard a protocol because you 
>>> don't appear to know how to extend it.
>>> 
>conveying node 
>>> costs.
>>> But there is already LSA available for carrying node capabilities, 
>>> and there are opaque LSAs available for carrying additional 
>>> "unconventional"
>>> information.
>>> 
>>> All this sort of ties to my main point. Of course, the protocols 
>>> don't do exactly what you want already, but a more thorough 
>survey is 
>>> needed if you what to use this I-D as the reason for excluding 
>>> protocols.
>>> 
>>> ---
>>> 
>>> Section 3.2 para 1
>>> Can you de-fluff this? Some people might think that 250 
>nodes is very 
>>> large
>>> ;-)
>>> 
>>> "network depths"
>capable of 
>>> forwarding data." If every node is a router and participates in the 
>>> routing protocol, this creates a very different environment from 
>>> saying that most sensors are hosts, and some are routers. I 
>>> Associated with the previous point, I think you might spend 
>a little 
>>> more time discussing the definition of a link in ROLL. It is clear 
>>> that in a wireless n/w a link may exist between any two nodes in 
>>> range.
>>> If that is
>>> what you mean, then it would help to make it clear. On the other 
>>> hand, "link" could be defined as an active neighbor relationship 
>>> between a pair of routers. Or something else.
>>> 
>>> This becomes important as we try to understand how the 
>protocol must 
>>> scale, and what it is supposed to do.
>>> 
>>> I presume that the concept of "parallel links" between neighbors is 
>>> going to have no meaning at the moment. That is, you use only one 
>>> frequency in any network. Maybe I presume wrong, in which case, you 
>>> need to refine the definition of "network density" in section 3.1.
>>> 
>>> ---
>>> 
>>> Section 3.2 para 1
>>> I can see why scaling with O(L) may be an issue, but it may 
>depend on 
>>> the definitions of links and routers. Also it may depend on what 
>>> magnitude you expect for L. Perhaps you could give some 
>ball-parks in 
>>> the previous paragraph as you do for N and D. Without that, it is 
>>> hard to justify the claim that scaling with O(L) is a problem.
>>> 
>>> ---
>>> 
>>> Section 3.3
>>> 
>>> I think that this is subjective and unhelpful. Can you rephrase to 
>>> capture a quantifiable requirement?
>>> 
>>> consistent term? It may be less pretty English, but it would be a 
>>> better way to avoid accusations of bias :-)
>>> 
>>> Perhaps...
>>> More precisely, loss responses that require transmissions 
>within the 
>>> network of O(N) fail, while those that are limited to O(L) or O(D) 
>>> pass.
>>> 
>>> ---
>>> 
>>> Section 3.4 para 1
>>> 
>>> "In terms of routing structure, any proposed L2N routing protocol 
>>> ought to support the autonomous organization and 
>configuration of the 
>>> network at the lowest possible energy cost."
>>> 
>>> Why "L2N"? I thought "Networks of low power wireless devices 
>>> introduce novel IP routing issues."
>>> 
>>> question I should take to the requirements documents. Consider 
>>> routing protocol A that is slightly more (say 5%) power-consuming 
>>> than routing protocol B. But suppose protocol A gives rise 
>to a data 
>>> forwarding solution that is 50% more power-efficient?
>>> 
>>> ---
>>> 
>>> Section 3.4 para 2
>>> 
>>> "As low-power wireless networks can have very low data rates, 
>>> protocols which require a minimum control packet rate can have 
>>> unbounded control overhead."
>>> 
>>> The control overhead is the ratio of control data to 
>payload data. A 
>>> high control overhead indicates that precious network resources 
>>> (bandwidth, power, or CPU) are being consumed by the control 
>>> protocols instead of being used to transmit data. Where 
>payload data 
>>> rates are very low (as is often the case in low-power wireless 
>>> networks) the control overhead can become unbounded for protocols 
>>> that require some non-zero background control packet rate.
>>> 
>>> ---
>>> 
>>> Section 3.4 para 2
>>> 
>>> s/never meet the condition can be forced/never meet the condition 
>>> could be forced/
>>> 
>>> ---
>>> 
>>> Section 4 para 3
>>> 
>>> But, I can see why you are interested in L2 hops as well as L3 hops 
>>> since they all consume power.
>>> 
>>> This comes back to the question about whether all nodes are 
>routers. 
>>> Perhaps some repeaters are not routers?
>>> 
>>> It is clear that routing protocols need to know their neighbors. It 
>>> is not clear that this requires that the discovery be part of the 
>>> routing protocol.
>>> 
>>> Later you have:
>>> I don't think the MPLS TE example is a good one. It is 
>certainly not 
>>> correct that the TED has to be fully distributed around the network.
>>> There are some very good examples of where "stub TE areas" do not 
>>> need to know the TE information for the whole of the rest of the 
>>> network.
>>> 
>>> ---
>>> 
>>> Section 4 Table
>>> 
>>> I'm prepared to bet that a lot of people will be upset by 
>the use of 
>>> "fail"
>>> for their favorite protocols. It would seem that "?" is more 
>>> appropriate in many cells.
>>> 
>>> ---
>>> 
>>> Section 5.1

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 27 Aug 2008 17:37:51 +0200

I guess I agree with John. I think this document is incomplete. The 
working group should consider the approach based on extending some 
existing protocol(s) to meet the specific requirements addressed in 
ROLL. To be really useful, the document should include some text 
providing a framework for this approach, aside from the "from scratch" way.

regards,
Emmanuel

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 27 Aug 2008 16:36:37 +0100

Right.

I am not saying that a new protocol is not needed. I am saying that I'd like 
to see some more discussion of what the routing protocol is trying to 
achieve.

The work to describe how the protocol itself must behave is pretty good. But 
the work describing what information must be distributed, how up-to-date it 
must be, and how it will be used is missing.

I am sure that this is all work in progress and will emerge in due course.

A
----- Original Message ----- 
From: "Drake, John E" <[email-masked]>
To: "JP Vasseur" <[email-masked]>; "Adrian Farrel" 
<[email-masked]>; <[email-masked]>
Sent: Wednesday, August 27, 2008 3:45 PM
Subject: RE: [Roll] draft-ietf-roll-protocols-survey-00

JP,

Thanks,

John

---

From: JP Vasseur <[email-masked]>
Date: Wed, 27 Aug 2008 18:38:01 +0200

Hi John,

> I thought that was exactly Adrian's point.

Ok let's have him express his opinion.

> the new operational environment, and then evaluate these changes.

John, I fully respect your opinion. Feel free to propose these changes in
light of the routing requirements expressed in the related WG document.
Please make sure to fully understand them though, these networks have fairly
unique characteristics that do require significant background.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 27 Aug 2008 18:41:31 +0200

Hi Adrian,

On 8/27/08 5:36 PM, "Adrian Farrel" <[email-masked]> wrote:

> The work to describe how the protocol itself must behave is pretty good.

Right.

But 
> I am sure that this is all work in progress and will emerge in due course.

Absolutely, although there is already some of that in the existing documents
and others (such as the routing metrics - an individual submission at this
points). Required protocol characteristics are described (e.g. Constrained
based routing, node constraints, protocol overhead, ...).

Cheers,

JP.

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 27 Aug 2008 09:57:35 -0700

Comment inline 

>Sent: Wednesday, August 27, 2008 9:38 AM
>> invent at least one, but probably many, new routing protocols.  It's 
>> not like this hasn't been done before.
>> 
>> environment, propose changes needed in each routing protocol to 
>> address the new operational environment, and then evaluate 
>these changes.
>> 
>
>John, I fully respect your opinion. Feel free to propose these 
>changes in light of the routing requirements expressed in the 
>related WG document.
>Please make sure to fully understand them though, these 
>networks have fairly unique characteristics that do require 
>significant background.

JD:  I would think this is the responsibility of the authors who are
requesting that their I-D be adopted by the working group.

>>> I do not think that this was Adrian's point. Your feed-back is more 
>>> than welcome but please argue a bit more ...
>>> 
>>> Thanks.
>>> 
>>> JP.
>>> 
>>> 
>operational 
>>>>> This is not to say that inventing a new protocol would be 
>wrong or 
>>>>> not fun.
>developed 
>capabilities, 
>>>>> But can't we actually factor the L2 hops into the 
>definition of the
>>>>> L3 hop?
>>>>> 
>>>>> ---
>>>>> 
>>>>> Section 4 para 3
>>>>>

---

From: JP Vasseur <[email-masked]>
Date: Wed, 27 Aug 2008 19:05:22 +0200

John,

> requesting that their I-D be adopted by the working group.

This is already a WG document and there was a consensus within the WG.

JP.

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 27 Aug 2008 10:47:35 -0700

JP,

Oopsie, my mistake.

However, I think my comment still stands, particularly if the working
group plans to use this I-D for deciding whether to invent at least one,
but probably many, new routing protocols.

Thanks,

John

>Sent: Wednesday, August 27, 2008 10:05 AM
>>> changes in light of the routing requirements expressed in 
>the related 
>>> WG document.
>networks have 
>>> fairly unique characteristics that do require significant 
>background.
>> 
>protocols 
>>>>>>> s/link changes to propagate across/link changes to be 
>propagated 
>>>>>>> across/
>>>>>>> 
>>>>>>> s/O(l)/O(L)/
>>>>>>> 
>>>>>>> ---
>>>>>>> 
>>>>>>> Section 3.3 final para
>>>>>>>

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 27 Aug 2008 20:03:07 +0200

> This is already a WG document and there was a consensus within the WG.

The point here is that such a document is extremely difficult to write, 
especially if it is not balanced with the framework that was mentionned 
earlier in the discussion (about "existing protocol extensions" vs "from 
scratch design").

I think that such a balance is missing in the document, and there is a 
high risk that conclusions may thus be misleading.

For example, there is this infamous "fail/pass" table at the end of 
section 4, which is too quickly justified in Section 13 (Annex A).

It is no secret that in reality it is difficult to be so binary about 
most of the criteria that are being cited here. Just a couple of 
examples I noted at first glance:

- OLSR is said to "fail" the "loss response" criteria. However in the 
quick justification in section 4, nothing is said about link hysteresis 
strategy (see OLSR RFC 3626 section 14.3.) which arguably makes OLSR 
"pass" this criteria.

- OLSR is said to "fail" the "control cost" criteria. However, simple 
fisheye TTL strategy on OLSR control messages makes OLSR "pass" this 
criteria. See this paper "Fish Eye OLSR Scaling Properties" in Journal 
of Communication and Networks, 2004. Actually this paper even proves 
that OLSR can thus reach the Gupta and Kumar bounds in terms of control 
overhead scalability.

But I'm afraid these 2 examples are just the tip of the iceberg if the 
document really about to justify the "fail/pass" table in section 4. For 
now this document is thus blurry and not really usable.

This is why in my opinion the document should be rewritten in a 
different, more balanced state of mind. The aim should be to remain 
constructive with what is already out there in terms of routing 
solutions, and to justify fully what is needed in addition to these 
existing solutions.

Regards,
Emmanuel

---

From: JP Vasseur <[email-masked]>
Date: Wed, 27 Aug 2008 20:21:30 +0200

Hi John,

> but probably many, new routing protocols.

Just to clarify: *should* the WG decide to design a new protocol (which
would mean to re-charter), it will *not* be many protocols for sure. That
would simply be a non sense. See my first presentation at the routing
plenary meeting.

Thanks.

JP.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 28 Aug 2008 14:37:53 +0200

Hi John:

I suspect that this discussion is already solution space thus should happen after rechartering.

NEW to me means that we can't just pick an existing RFC and be done with it. This is what ROLL is chartered to evaluate and this is why the protocols survey is promoted to WG doc.

To work on something NEW we need to recharter. 

IOW, even if the solution is heavily based on existing work, with say, a specific set of features made mandatory (a profile of some sort), and eventually a few new ones added, we need to specify that in an RFC and we need a group chartered to do so. 

Pascal

>From: [email-masked] [mailto:[email-masked]] On Behalf Of Drake, John E
>Sent: mercredi 27 août 2008 19:48
>To: Jean Philippe Vasseur (jvasseur); Adrian Farrel; [email-masked]