Subject: [Autoconf] Links, wireless properties and autoconf scope

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 17 Nov 2009 11:56:01 +0100

Hi,

Quite a few e-mails have been sent lately and I'm not sure we are making
any progress, again we have different views and I think we need to reach
a common understanding. I think it's good that everybody provides their
view, because I think that after 5 years we don't have still a clear and
well accepted view of what a MANET is and -- more important -- what is
the scope of AUTOCONF.

Trying to summarize some issues next, to help driving the discussion to
more concrete points...

- LLs usage in MANETs. I see and understand (personal view) that "links"
in wireless MANETs do not exactly behave as wired (Ethernet-alike)
links. However, I don't agree that LLs cannot be used in MANETs (in case
a protocol/application wants to use it). These "links" in MANETs are
more dynamic, short-lived and transitivity is not granted, but we still
have a "link".

- Related to the previous item, IPv6 assumes the existence of "links",
so I agree with Alex that we need to have some better understanding of
what we understand by "link" in autoconf. For me, I see it as a wireless
link (with all its properties) which is very dynamic and non-transitive.
This implies that special care has to be taken when designing some
mechanisms (DAD is one of the most representative ones), but it does not
necessarily preclude the use of link-locals. IP relies on the existence
of a link and therefore, if we don't want to change many core IP
mechanisms, we need to understand what kind of link IP "sees" in a
MANET.

- From the last e-mails I see again that the scope of autoconf is not
clear. I always thought that autoconf was dealing with __IP address
autoconfiguration in MANETs__, but I see (I've already raised this
question/comment) that many people is rather working on "IP over MANET"
and here is where most of the controversy appears. I think the charter
should be more explicit about what changes are allowed to IP standards
in order to allow MANETs get IP address autoconfiguration, otherwise
this is not gonna converge (we may get "rough" consensus, but a
non-negligible set of wg members would likely never agree). If people
feel it is impossible to come up with a practical address
autoconfiguration mechanism without modifying some IPv6 core standards,
then we should go for a "6MANET" working group or something like this.
There address autoconfiguration would be part of the charter (as in
6lowpan).

My two cents, hope it helps instead of creates more confusion and
endless discussions...

Thanks,

Carlos

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 17 Nov 2009 10:02:22 -0800

Hello Carlos,

> well accepted view of what a MANET is and -- more important -- what is

I think there is a very well accepted view of the nature of a MANET.  
There is a conference
series called "MobiHoc" which has published many high-quality papers on 
the subject.
I reviewed many papers for the conference, and I didn't notice the huge 
conceptual stumbling
blocks there that are surfacing on this mailing list.  Maybe it would 
help for the people unclear
on the concepts to read some of those papers.  There is a huge diversity 
of opinion, to be sure,
but at least people don't try to confine ad hoc networks to be single 
hop domains configured by
network administrators.

> more dynamic, short-lived and transitivity is not granted, but we still
Sure, you can use them.  Others should not have to use them.

> what we understand by "link" in autoconf.
I don't think that is likely to get you anywhere.  I recommend you form 
a task
force to settle the issue for your satisfaction.

>  For me, I see it as a wireless

IP relies on the existence of a communications medium equipped with
layer-2 access software (in the device driver) and a standardized
calling sequence for the device driver.

> and here is where most of the controversy appears.

I thought that some people indicated they did not believe IP could
work over a MANET so then we had to have yet another diversionary
discussion.  That doesn't mean the scope of [autoconf] is unclear.

>  I think the charter
> non-negligible set of wg members would likely never agree).
Especially the ones that don't think it's possible to run IP in a MANET.
I think that determining which standards require revision is a problem in
the solution space.

>  If people
Sorry, this is wrong.  [autoconf] is chartered to make practical address
autoconfiguration mechanisms.  It's been shown to be possible.  Now if
we could just get to doing it instead of convincing people that IP can be
run in a MANET.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Nov 2009 19:29:20 +0100

Charles E. Perkins a écrit :
[...]
> There is a conference series called "MobiHoc" which has published 
> many high-quality papers on the subject. I reviewed many papers for 
> the conference, and I didn't notice the huge conceptual stumbling 
>  help for the people unclear on the concepts to read some of those 
> papers.

Are you talking about me?  I too regularly review (for reviews.com)
about ad-hoc networks articles published on more than just MobiHoc and I
end most of my reviews urging everybody to practice more and simulate
less.  That gets published.

Only to come here be told I don't know about MANETs :-(

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 17 Nov 2009 10:45:00 -0800

Hello Alex,

Here's an excerpt from a recent email:

> No no, I am deaf :-)
>
> I tell you why.
>
> Whenever considering a 1000somethings bigger something one has to
> structure them.  And the first setp in structuring is to use
> deterministic links.
>
> Also, whenever considering 1000nodes, there surely will exist _some_ 
> nodes which are given little more functionalities.  I expect these to 
> have several interfaces.
>
> Besides, there's no one single human who could deploy alone a working 
> 1000node IP network.

First, since you are deaf, I am silly for responding.  I might
as well try to convert Texas to humanism.

Second, there are examples of 1000 node networks where
each node is minimal.

Third, a single human could easily deploy a 1000 node sensor
network.

So, in just this one excerpt you have exhibited fundamental
disregard (I won't say ignorance) for existing technology.

In a previous email to you, I exhibited nearly a half-dozen
errors in a _single sentence_.

You insist on necessitating a central role for a "link", in
a network where such the communications medium identified
by such a concept is likely to be varying very quickly in
time and space, sometimes almost unpredictably.  The
experience of others (who do those 1000 node networks)
leads towards certain design decisions that you disregard.

[cf:
> No no, I am deaf :-) 
].

And yet you want to occupy the attention and restrict
the solution space available to practitioners who seem to
have far more experience than you, regardless of your
ability to respond to paper review requests.

Regards,
Charlie P.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 17 Nov 2009 20:07:21 +0100

Hi Charlie,

> on the concepts to read some of those papers.  There is a huge diversity 

I've also reviewed many papers from this or similar conferences and
journals. Even I have published on this topic.

> hop domains configured by

I don't try to do that. I just pointed out the fact that it seems that
we don't have in autoconf a agreed view on what a MANET is (I think we
tried in the past with the draft-ietf-autoconf-manet-architecture and we
failed). So, I agree with you, there is a huge diversity of opinion.

> Sure, you can use them.  Others should not have to use them.

Right.

> force to settle the issue for your satisfaction.

Well, I just tried to be constructive here, doing things for my own
satisfaction is good, but not very constructive :-).

> calling sequence for the device driver.

Well, IPv6 standars discusses about off-link, on-link, etc, so "links"
are critical parts to understand addressing.

> discussion.  That doesn't mean the scope of [autoconf] is unclear.

I do believe IP can work over a MANET (and I have performed experiments
with MANETs in my lab). I'm far from questioning this. My point is that
I think we can run IP over MANET without introducing drastic changes to
IP.

> Especially the ones that don't think it's possible to run IP in a MANET.

Again, I hope you are not referring to me here, because I do believe it.

> I think that determining which standards require revision is a problem in

Well, someone mentioned not using ND at all in MANETs in the last
meeting. I have this kind of example in mind when talking about this.

> we could just get to doing it instead of convincing people that IP can be

I'm sorry you think we are arguing against the feasibility of running IP
in a MANET, this is not true. I'm just trying to understand the best way
of _configuring IP addresses_ in a MANET, with as minimum changes to IP
model/protocols as necessary.

I just tried to help with this thread, but I guess I've failed again.
Maybe I should keep myself quieter from now on...

Thanks,

Carlos

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 17 Nov 2009 11:31:32 -0800

Hello Carlos,

> failed). So, I agree with you, there is a huge diversity of opinion.

All of the failures stem from an attempt to fit a round peg in
a square hole.  Or, to be more precise, to fit the time-varying
nature of the MANET communications medium completely
within the square hole of the IP subnet model.

> satisfaction is good, but not very constructive :-).

But I am pretty sure that focusing on identifying "links" in a MANET
is not constructive.  Been there, done that!  In fact, the whole discussion
about link-layer uniqueness is a red herring if protocol cannot identify
the "link" on which such an address is supposed to be unique.

>> medium equipped with

True.  I have found that IPv6 works great for packetized
communications even across communications media for which
"link"-related terms aren't easily associated with physical reality.
You have almost provided a road map for those parts of the
IPv6 specification that need to be reinterpreted.

> I think we can run IP over MANET without introducing drastic changes to

I agree.  But I think we have to dispense with tight adherence to
previously determined properties of wireline links.

> Again, I hope you are not referring to me here, because I do believe it.

I don't think it was you, but _somebody_ indicated they didn't think it
was possible.

> meeting. I have this kind of example in mind when talking about this.

I'm among those who believe ND will require modification
if it would be used at all.

> in a MANET, this is not true.

I am willing to believe you are not among those making this argument.

>  I'm just trying to understand the best way

Here, necessity is defined by the range of applicability.  In order to
expand the range of applicability to large and/or highly mobile network
populations of wireless nodes, modifications are going to be required,
and the concept of "link" as defined in the IPv6 specifications is not
helping.

> Maybe I should keep myself quieter from now on...

I don't ask anyone to be quieter, but I like it better when they
are not deaf.

Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 17 Nov 2009 20:40:42 +0100

> if it would be used at all.
I think we had already some suggestion how to deal with it...

a) If you have unique MAC addresses, use them for IP generation and be happy.
b) If you have a good source of random numbers, use them for IP generation and 
be happy.
c) If you don't have any of this, maybe a protocol to generate some random 
input in the mesh would be a sollution (just continue with b).

Henning Rogge

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 17 Nov 2009 20:47:29 +0100

> input in the mesh would be a sollution (just continue with b).

This is not modification of ND, IMHO. Current specs allow to do any of
this.

Carlos

---

From: Henning Rogge <[email-masked]>
Date: Tue, 17 Nov 2009 20:54:46 +0100

Am Dienstag 17 November 2009 20:47:29 schrieb Carlos Jesús Bernardos Cano:
> > a) If you have unique MAC addresses, use them for IP generation and be
> > happy. b) If you have a good source of random numbers, use them for IP
> > generation and be happy.
> > c) If you don't have any of this, maybe a protocol to generate some
> > random input in the mesh would be a sollution (just continue with b).
> 
The modification we would need would have to go into DAD (to check if we good 
a collision). Instead of directly listening to other DAD checkers using our 
interface IP, we would have to programm a DAD which detects if TWO of it's 
neighbors are using the same IP and send some kind of "please change this IP" 
message as a broadcast. This should be enough to get the ABC-Problem under 
controll.

In moving networks with changing connectivity we have of course to do this 
constantly.

Henning Rogge

---

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

> Second, there are examples of 1000 node networks where

Charles - there's no network of 1000 sensors I am aware of that runs IP 
and that uses exclusively 1-interface routers and /128 prefixes per 
their interfaces.

> Third, a single human could easily deploy a 1000 node sensor

Tell about an example.

> You insist on necessitating a central role for a "link", in

YEs - link is of paramount importance.

You also need a communication medium but you simply don't want 
4861-links, that's all.

You avoid defining them and always claim you and only you understand its 
non-understandable behaviours.  You sometimes use it to explain some 
protocol design choices, but I can't understand these choices because I 
simply don't understand what you mean by non-deterministic links and 
time/space variation of stuff.

> leads towards certain design decisions that you disregard.

Hmmm... tell me about one such 1000node network running IP on each node 
and 1-interface routers exclusively, and /128 prefixes-per-interfaces... 
never seen one.

I believe it exagerated.

If it ran by your AUTOCONF rules then each node would have a host-based 
route for every other node (i.e. 1000 entries in each node memory), or, 
sensor nodes are so restricted in memory that their stack takes much of 
the place.

That's why I believe your 1000node claims exagerated.

>> No no, I am deaf :-) 

YEs, and I stay deaf to these statements that don't follow.

> ability to respond to paper review requests.

Hmm... at some point I get bored...

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 17 Nov 2009 13:23:20 -0800

Hello Alex,

Alexandru Petrescu wrote:
> Charles - there's no network of 1000 sensors I am aware of that runs 
> IP and that uses exclusively 1-interface routers and /128 prefixes per 
> their interfaces.

Ohio State University.

Rutgers University/GENI

Others may give you other citations.

>> Third, a single human could easily deploy a 1000 node sensor

Dropping motion sensors from an airplane.

> You also need a communication medium but you simply don't want 

Not "simply".  Not "that's all".  Not just me.

>
>
> You avoid defining them and always claim you and only you understand 
> its non-understandable behaviours.

This is a totally false and unwarranted accusation.

>   You sometimes use it to explain some protocol design choices, but I 
> can't understand these choices because I simply don't understand what 
> you mean by non-deterministic links and time/space variation of stuff.

Those words have well-defined meanings.  I personally do not
use the terminology "non-deterministic".  Maybe you are confusing
me with someone else.

>
>
> Hmmm... tell me about one such 1000node network running IP on each 
> node and 1-interface routers exclusively, and /128 
> prefixes-per-interfaces... never seen one.

See above.

>
>
> If it ran by your AUTOCONF rules then each node would have a 
> host-based route for every other node (i.e. 1000 entries in each node 
> memory), or, sensor nodes are so restricted in memory that their stack 
> takes much of the place.

No, each node only requires host routes for destinations
required by its applications.

> That's why I believe your 1000node claims exagerated.

You must be trying to convince me that proactive link-state
protocols have larger memory requirements.

> YEs, and I stay deaf to these statements that don't follow.

Whenever I am having a technical discussion, I try to understand
how the arguments which are presented can be interpreted so
that they make sense.

> Hmm... at some point I get bored...

I'm long past bored.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Nov 2009 23:29:27 +0100

Charles E. Perkins a écrit :
>>> Second, there are examples of 1000 node networks where each node
>>> is minimal.
>> 
>> Charles - there's no network of 1000 sensors I am aware of that
>> runs IP and that uses exclusively 1-interface routers and /128
>> prefixes per their interfaces.
> 
> Ohio State University.

It's a big University, what of if more exactly?

Is this claim similar to the recent claim that said large networks in 
Vienna, and yet there are two-interface routers?

> Rutgers University/GENI

I do follow GENI and what I see is invitations to conferences - should I
accept these invitations?  And I don't see networks of 1000s IP
1-interface sensors.

> Dropping motion sensors from an airplane.

Again - I agree with you in the sense they represent great goals, ideal
in a sense.

However, I don't see it happening as you describe it, i.e. IP on each
sensor dropped from planes.

And I did see sensor networks.

>> You avoid defining them and always claim you and only you
>> understand its non-understandable behaviours.
> 

Politeness here ok - no accusation.

>>  can't understand these choices because I simply don't understand
>> what you mean by non-deterministic links and time/space variation
>> of stuff.
> 
> Those words have well-defined meanings.  I personally do not use the
> terminology "non-deterministic".  Maybe you are confusing me with
> someone else.

You continue saying these ABC-links are different than existing links,
with a timespace vocabulary proper to only the pure PHY-inclined.  Not
that they're not right, but they simply don't use IP - they use OFDMA
MIMO and such.

>> host-based route for every other node (i.e. 1000 entries in each
>> node memory), or, sensor nodes are so restricted in memory that
>> their stack takes much of the place.
> 
> No, each node only requires host routes for destinations required by
> its applications.

Cross-layer violation?

How about decoupling both the layer-7 (apps) _and_ the layer-0 (PHY)
from AUTOCONF?

Let me say I refuse completely to agree on this cross-layer violation:
applications dictate which route should be present or not.  Applications
use sockets to send/rcv data that's all.  I don't want to fiddle beneath
them.  I did enough fiddling with below apps Mobile IP to know what I'm
talking about.

> You must be trying to convince me that proactive link-state protocols
> have larger memory requirements.

You may like me to, but no.  Not my intention was that.

I simply don't agree with the app-dictates-routes.

There will always exist apps unaware of the supposed routing fiddling.
The only interface they assume is their Socket, which is very good.
That Socket doens't know MANET.

BEsides, I don't want my app blocked until some routing protocol
finds its paths through a 1000node unstructured maze.

These are enough basic things for me to be in full disagreement with the
MANETs as presented.

The only way to get past that is to decouple MANET from AUTOCONF.

Alex

> Whenever I am having a technical discussion, I try to understand how
> the arguments which are presented can be interpreted so that they
> make sense.
> 
> 
>> 
>>> And yet you want to occupy the attention and restrict the
>>> solution space available to practitioners who seem to have far
>>> more experience than you, regardless of your ability to respond
>>> to paper review requests.
>> 
> Regards, Charlie P.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 18 Nov 2009 00:12:03 +0100

> Charles E. Perkins a écrit :

<SNIP>

>>> node and 1-interface routers exclusively, and /128 prefixes-per- 
>>> interfaces... never seen one.
>> See above.
>>> If it ran by your AUTOCONF rules then each node would have a host- 
>>> based route for every other node (i.e. 1000 entries in each

Fortunately, MANETs are just like the rest of the Internet, also in  
that regard.

> Let me say I refuse completely to agree on this cross-layer violation:

Fortunately, there is none.

> them.  I did enough fiddling with below apps Mobile IP to know what  

Fortunately, no fiddling is needed.

> I simply don't agree with the app-dictates-routes.

Fortunately, they don't no more than they do in the Internet.

> finds its paths through a 1000node unstructured maze.

Fortunately, this is not the case.

> These are enough basic things for me to be in full disagreement with  

It would appear, that the things you imagine above do not hold for  
MANETs.

> The only way to get past that is to decouple MANET from AUTOCONF.

No, not at all.

Thomas

> _______________________________________________
> Autoconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/autoconf

---

From: Ricardo Schmidt <[email-masked]>
Date: Tue, 17 Nov 2009 20:21:39 -0300

Here we have a good example: http://www.cs.wayne.edu/~hzhang/
1,400-node mesh network at Wayne State University.

On Tue, Nov 17, 2009 at 7:29 PM, Alexandru Petrescu
<[email-masked]> wrote:
>>>> Third, a single human could easily deploy a 1000 node sensor network.
>>>
>>> Tell about an example.
>>
>>> route for every other node (i.e. 1000 entries in each

---

From: Ricardo Schmidt <[email-masked]>
Date: Tue, 17 Nov 2009 20:22:12 -0300

Sorry all, the link was wrong:
http://www.cs.wayne.edu/~hzhang/

-- 
Ricardo Schmidt

MSc candidate in Computer Science / UFPE
BSc in Computer Science / UPF

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 17 Nov 2009 15:52:08 -0800

Hello Alex,

> sensor dropped from planes.

Well, that's the way it can happen.

> And I did see sensor networks.

Sensor nets can run IP.

> Politeness here ok - no accusation.

Polite, impolite, rude, or downright vicious --
the statement is still totally false.

> that they're not right, but they simply don't use IP - they use OFDMA

I'm not the one talking about links.  As far as IP is concerned, all that
is needed is to formulate a packet that can be delivered to the next hop,
and issue a call on the proper device driver to deliver it.

No mind-torquing at all is required to understand this.

And you are wrong to suggest that time variations are irrelevant
to IP.  As I recall, most routing protocols have timing parameters.

I hope you will form a design team to work out a suitable
ecology for understanding the meaning of the word "link"
in your desired environment.

>> No, each node only requires host routes for destinations required by

Absolutely not.  The applications require no changes at all.

> How about decoupling both the layer-7 (apps) _and_ the layer-0 (PHY)

Considering that they were never coupled, no problem.

> them.

This is a very convenient strawman for your wrath.

> That Socket doens't know MANET.

Finally -- a point of 100% agreement between us.

> finds its paths through a 1000node unstructured maze.

Nobody likes to wait.

> These are enough basic things for me to be in full disagreement with the

But that's the way MANETs _are_.

> The only way to get past that is to decouple MANET from AUTOCONF.

That would be dumb.

Regards,
Charlie P.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 18 Nov 2009 09:47:32 -0000

> message as a broadcast. This should be enough to get the ABC-Problem
under 

That's not sufficient. What happens if two nodes three or more hops away
pick the same address? That's still a problem that needs solving if you
are going to e.g. route with DYMO or OLSRv2.

********************************************************************
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: Henning Rogge <[email-masked]>
Date: Wed, 18 Nov 2009 10:54:36 +0100

On Wed November 18 2009 10:47:32 Dearlove, Christopher (UK) wrote:
> > message as a broadcast. This should be enough to get the ABC-Problem
> > under controll.
> 
I was talking only about linklocal IPs. If you choose the same LL-IP three 
hops away OLSR or DYMO should not care (as long as they support unroutable 
addresses).

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-263,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Nov 2009 14:19:59 +0100

[Thomas - please make your mails such I see them with fixed-length font 
(like Courrier), not variable-length fonts (like Times Roman). 
Displaying variable-length font emails breaks my view.

I believe this may come from your use of quoted-printable MIME encoding 
instead of base64 MIME encoding.

HEre we talk English, 7bit ASCII is sufficient, no need to encode it 
with MIME.  If you really want to encode it with MIME then use base64 
encoding (instead of quoted-printable) or 8bit encoding, it covers a 
much wider range of characters.

If you need both English and French on the same MUA, you could still 
make your readers see fixed-font length by not using MIME but 8bit 
transport - most MTAs and MUAs are 8bit capable since some time now.

For example,
RFC2045:
> For this reason, at least two encoding mechanisms are
>    necessary: a more or less readable encoding (quoted-printable) and a
>    "dense" or "uniform" encoding (base64).

That "more or less"... means I see "=20" instead of a CR.  I ... err... 
don't like it at all.]

Back to our subject.

Thomas Heide Clausen a écrit :
> Fortunately, MANETs are just like the rest of the Internet, also in that 
> regard.

Well, not true.  Most applications are not aware about there being a 
route or not.  The apps I currently use are not blocked more than 1-2s 
at worst until a path is found.  And that is Internet scale.

Generally speaking, the apps on end nodes are generally blocked mainly 
by the ND use for the default route.  HEre - you don't even talk default 
routes, and not talking ND either.

You don't even ack the fact that pure ND should happen with whatever 
addresses AUTOCONF generates.  You are ready to modify ND, or to even 
replace it with something else.

SO I really think we have different view on this aspect too.

> Fortunately, there is none.

It _is_ a cross-layer violations for apps to depend on the existence on 
routes.

> Fortunately, no fiddling is needed.

Hmmm... how does my firefox browser running on a MANET host know a route 
exist or not to a destination?

> Fortunately, they don't no more than they do in the Internet.

Well again, my apps on my laptop has little idea about the presence of 
routes in its routing table or in the Internet.  All the kernel does is 
use a default route and ND for that.  You don't ack any of the two

Ronald questioned at the last meeting about this use of ND, and you 
manage to respond something but it showed non-interest from your part.

> Fortunately, this is not the case.

Which part of that is not the case?

> It would appear, that the things you imagine above do not hold for MANETs.

No, it appears we just exchanged a yes-no pair of messages on which I 
struggle to explain things and to which you say 'no'.

That is not explanation.

That is not consensus.

That is a Chair imposing stuff.

Alex

>> [email-masked] <mailto:[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Nov 2009 14:23:30 +0100

> 1,400-node mesh network at Wayne State University.

Please digest that page info for me.

Is it 1400 nodes?  Or area of 1400m times something? (the slides say so)

Is each node running IP?  IPv6?

Is each node having a single interface?

That is what I am looking for.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 18 Nov 2009 14:03:10 -0000

> I was talking only about linklocal IPs.

If autoconf is to be useful, we need it to create addresses with
MANET wide scope (at least) and uniqueness in that scope. That needs
something more than a two hop approach. Maybe you can get a two hop
approach to work and create LL addresses with that (dynamically
changing) scope. And if that's useful to you, fine. But to route
across a MANET with autoconfigured addresses needs more than that.
And that's what the WG needs to create if it's to be useful.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 18 Nov 2009 15:16:21 +0100

> And that's what the WG needs to create if it's to be useful.
I completely agree with you, creation of manet-unique IPs is the more 
important part of this WG. But I think we will be able to get the LL-Problem 
done too with a little bit creative work.

Henning Rogge

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 18 Nov 2009 17:03:57 +0100

On Nov 18, 2009, at 2:19 PM, Alexandru Petrescu wrote:
<SNIP>

> route or not.  The apps I currently use are not blocked more than  
> 1-2s at worst until a path is found.  And that is Internet scale.

As MANETs are *exactly* like the other parts of the Internet in this  
respect, you either disagree with the Internet or agree with MANETs  
here.

> Generally speaking, the apps on end nodes are generally blocked  
> mainly by the ND use for the default route.  HEre - you don't even  
> talk default routes, and not talking ND either.
>
> addresses AUTOCONF generates.  You are ready to modify ND, or to  
> even replace it with something else.
>

> It _is_ a cross-layer violations for apps to depend on the existence  
> on routes.

Fortunately, they do not depend on this in a MANET either. A MANET is  
just like the Internet in this regard.

> Hmmm... how does my firefox browser running on a MANET host know a  
> route exist or not to a destination?

It doesn't. I am *this second* writing this email using a stock Apple- 
issue laptop with nothing but std. applications.  My Firefox, Safari,  
Mail et. al. do not know that they are connected across a MANET  
routing domain, any more than they would know if they were connected  
over an OSPF domain.....

So, no fiddling is needed.

> Well again, my apps on my laptop has little idea about the presence  
> of routes in its routing table or in the Internet.
>  All the kernel does is use a default route and ND for that.  You  
> don't ack any of the two

I am connected to the Internet via a MANET right now. You don't ack  
that that works just fine.

> manage to respond something but it showed non-interest from your part.

Ronald has a point, which is very relevant when we go to the next  
phase: designing solutions.

> Which part of that is not the case?

All parts.

> No, it appears we just exchanged a yes-no pair of messages on which  
> I struggle to explain things and to which you say 'no'.
>
> That is not explanation.
>
> That is not consensus.
>

Many people have tried to explain matters, but it seems that these  
explanations fall on deaf ears. It is hard not to get more than a  
little frustrated.

Thomas

>>>> how