Subject: Re: [Autoconf] various (was: [Fwd: Re: identifying links for CP's 4 node example])

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Oct 2009 19:41:59 +0200

Charles, thanks for reminding me this message.  I take the freedom to 
copy the list, in reply.

Our conversation stopped because...

Charles E. Perkins a écrit :
>>> At time T_1, a second later, the neighborhoods
>>> are as follows:
>>>
>>>                      A --------- C --------- B --------- D
>>>
>>> Please explain how you identify the links upon which
>>> your assignment of link-local addresses are valid, and
>>> indicate a compatible assignment of link local addresses,
>>
>> I assume in your sketch that C and B each has two interfaces, and that 
>> a single segment is 50m long and that the link-layer technology is wifi.
> 
> The way I think of it, C and B have a single network interface.

My part of our conversation stopped here.

We have very different assumptions on the number of network interfaces a 
node has in AUTOCONF.  You believe 1, I believe more.

The DT document does not say how many there are.  I think it should.

I already suggested to clarify this - "how many interfaces does an 
AUTOCONF node has"?

> Each 
> segment is
> only meant to signify a relatively reliable signal path.  A packet 
> transmitted by
> C would be detectable by both A and B (almost) simultaneously, if we 
> disregard
> propagation delays.  Link-layer technology isn't specified, but WiFi 
> would give
> good intuition.
> 
>>
>> How to identify the links?  Each link (a segment) is a different SSID. 
>> This is a field in each 802.11 header of each packet.
> 
> Do you mean to specialize your solution to situations where the SSID
> can be used to identify intended recipients?

Right... do you mean to generalize AUTOCONF to everything else which we 
don't know what is?

>> The above (mine?) link definition is ok for the purpose of my 
>> prototype.  This is straightforward and should not be forbidden.
> 
> I'm quite sure no one would forbid such a
> model of link establishment.  That would be
> wrong.

Here I agree with you.

It's like you don't forbid what I'm doing, but you don't want to mention 
it either (in the DT document).  SO I can live with it.

>> As for the change in topology from A-B-C-D to A-C-B-D from T_0 to T_1 
>> - your challenge should dissected in the separate steps:
>>
>> A-B-C-D        T_0
>> A- -B-C-D      T_1
>> A -B- -C-D     T_2
>> A -C- -B- -D   T_3
>> A-C- -B-  -D   T_4
>> A-C-B- -D      T_5
>> A-C-B-D        T_6
>>
>> At T_1 A and B realize they can no longer talk  to each other.  They 
>> do so with NUD.
>>
>> At T_2 B and C realize can't reach each other.  Also NUD.
>>
>> At T_3 C and D realize can't reach each other.  Also NUD.
>>
>> At T_4 A and C realize they can talk to each other.  By using periodic 
>> NAs, RSs, RAs.
>>
>> At T_5 B and C can talk, they discover that also with NA.
>>
>> Finally, at T_6 B and D talk (also discover that with NA).
> 
> The timeouts for these operations are not compatible with
> the expected rate or motion.  If the internodal distances are
> 50 meters, then the transition time between the illustrated
> two network configurations would not likely be as low as
> 1 second.

Er?  Why is it so?  What do you mean?

What kind of expected rate of motion to you expect?  And what kind of 
coverage areas do you expect?

>  Then you might have enough time for occasionally
> correct operation  -- but I'm sure there would be failures
> anyway.
> 
> If the transition happens in 1 second, your RAs need to
> arrive perhaps as often as 100ms apart.  If there were
> 20 nodes instead of 4, your advertisement period might
> be as low as 5ms.  You would have a massive problem
> with collisions of advertisements unless you synchronize
> and stagger the RAs.  The synchronization problem by
> itself will cause you to age prematurely.

Charles - I do this in the lab with three nodes sending RAs.  20 nodes 
is not much further away.

If there is a risk of a  massive collision problem with RAs I can think 
of re-using the RA sending in an exponential back-off manner to avoid 
collisions.  Not sure to which extent is it implemented, and if it is 
not, we will look into it.

> You can't rely on NUD.  For example, it requires
> active signaling:
>> Receipt of other Neighbor Discovery messages such as Router
>>    Advertisements and Neighbor Advertisement with the Solicited flag set
>>    to zero MUST NOT be treated as a reachability confirmation. 
> 
> So if you want to overlay active confirmations on top
> of the passive one-way path verifications, you will
> compound the problems mentioned above that are
> due to frequent transmissions of RAs.

Nein, Charles.  I believe in the solid robustness of the IP stacks I am 
using.  If these things you talk about happen, I can correct them by 
either re-specifying, or better implementing.

Until I see these problems in practice I can't agree with you.  I would 
even challenge you whether you talk implementation experience here, or 
logical extension of conceptual aspects.

> Basically, even for four nodes, I think you are hosed,
> and for 20 nodes, it borders on insanity.  We have
> been able to show operation of AODV for
> thousands of nodes.  Still needs improvements!
> But, if we were MANDATED to run RAs and NUD,
> it would be absolutely and irretrievably unattainable.

Charles, ok, you make it sound scaring.  What happens in my lab is very 
friendly.

LArger tests are planned (to the extent of  what wifi link layer allows 
- surely not thousands).

If I had 1000s of nodes then I would _subnet_ this with routers in the 
middle -- for sure!  That means at least bridging, and most probably 
routing.  That means several interfaces on a node.

There exists practically no digital wireless link layer I am aware of 
which supports thousands of nodes within direct IP reach, same subnet, 
all-node-multicast link-local scope.

AODV - is a good thing from what I read.  I have never tried it in practice.

SOmetimes people ask why don't I use AODV or OLSR on the mobile routers 
in vehicles I talked about - and then I say maybe they're too heavy for 
what's needed in some particular cases. And I am afraid there's no 
consensus on either one.

>> This can be achieved as follows:
>> -on each interface of each node pre-configure a unique /64 subnet
>>  prefix.
> I'd say one per node.

I disagree.  One prefix per interface is better.

>> -designate A and D to send Router Advertisements with prefixes that
>>  should be interpreted as to install in the receivers' routing tables
>>  (an extended "intepretation" of RFC4191 "more specific routes").
>> -designate B and C to also send such extended RAs but _only_ if there
>>  isn't already somebody else sending such an extended RA on that link,
>>  or if a new NA is heard from a neighbor it hasn't seen before.
> 
> In the initial configuration, when does B learn that it can
> communicate directly with C?  As long as C is happy with
> D and B is happy with A, they might never learn about
> each other.

When NUD says so.

[...]

>>> Do you think we should restrict
>>> work in [autoconf] to be applicable only to such networks
>>> in which that restriction is valid?
>>
>> Of course, I don't agree restricting work.  I don't agree forbidding 
>> link-local addresses either.
> 
> I don't remember anyone forbidding link-local addresses.

Unrecommending them is what DT document does.  It's not forbidding, it 
is not recommending.

>>> Do you have any intuition about the scalability of the
>>> system resulting from your definitions?
>>
>> Hmm... tough question.  I believe the method I presented above should 
>> scale well provided (1) all nodes are pre-configured with prefixes 
>> unique and (2) MAC addresses are unique.  But I have of course some 
>> doubts.
>>
>> But whereas you're very specific A-B-C-D to A-C-B-D you don't say how 
>> would you like it to scale: would it always be rectilinear scaling 
>> (max 2 interfaces per node)?  Something else?
> 
> I'm not sure what rectilinear scaling would be, but I would
> not expect most networks to necessarily conform to any
> rectilinear layouts.

Depends on the scenario - vehicles on a highway, wagons of a train, and 
others are very much rectilinear topologies.

>  The other networks are, however, much
> harder to draw with ASCII stick figures.

YEs.

I do about the ones I need.  IT helps me understanding and communicating 
them.

The ones we don't understand and don't communicate - will never fly.

>>> What if you discovered that your definitions resulted in a
>>> system that was three orders of magnitude less scalable than
>>> an alternative that did not impose a requirement for assigning
>>> unique link-local addresses? -- or, a system that, effectively,
>>> didn't even define any broadcast-oriented links at all?
>>
>> This is speculation from your part.  You are asking to compare against 
>> something that you don't say what is.
> 
> I'm thinking about AODV-style networks with hundreds
> or thousands of nodes.

Any subnetting into those?  (just curious).

Thanks,

Alex

>> (no offence pointing at 'you' - it is more or less intended response to
>>  previous comments :-)
> 
> Absolutely no offense taken, and thanks for the time you
> spent to make the reply.
> 
> Regards,
> Charlie P.
> 
> 
> _______________________________________________
> Autoconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/autoconf
> 
> 
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 22 Oct 2009 12:17:54 -0700

Hello Alex,

Alexandru Petrescu wrote:
>>> I assume in your sketch that C and B each has two interfaces, and 
>>> that a single segment is 50m long and that the link-layer technology 
>>> is wifi.
>>

Hmmm....  hard to build bridges that way...

>
> We have very different assumptions on the number of network interfaces 
> a node has in AUTOCONF.  You believe 1, I believe more.
>

Where are these other interfaces?  I understand about radio
transmissions, spectrum utilization, channel assignment, and
all that.  If you just have one radio channel, I am pretty sure
that you will get into deep trouble trying to model it as
numerous network interfaces.

Which is not to make any limitations on the number of
subnet prefixes you may choose to assign to that singular
interface.  But multiple _network interfaces_?  I guess they
must all be virtual :-).

>>> How to identify the links?  Each link (a segment) is a different 
>>> SSID. This is a field in each 802.11 header of each packet.
>>
> Right... do you mean to generalize AUTOCONF to everything else which 
> we don't know what is?

I have a good imagination, and I can't imagine what this means.
The discussion I have had is based on systems I have been involved
with actually building.

> It's like you don't forbid what I'm doing, but you don't want to 
> mention it either (in the DT document).  SO I can live with it.

The document needs to specify certain things -- hopefully, a
minimal number of things.  In my opinion, it needs to avoid
any attempt to enumerate the total universe of possibilities.
Instead it should just make the fewest number of mandates
so that we can get a clearer picture of the solution space.

>
>>> As for the change in topology from A-B-C-D to A-C-B-D from T_0 to 
>>> T_1 - your challenge should dissected in the separate steps:
>>>
>>> A-B-C-D        T_0
>>> A- -B-C-D      T_1
>>> A -B- -C-D     T_2
>>> A -C- -B- -D   T_3
>>> A-C- -B-  -D   T_4
>>> A-C-B- -D      T_5
>>> A-C-B-D        T_6
>>>
>>> At T_4 A and C realize they can talk to each other.  By using 
>>> periodic NAs, RSs, RAs.
>>>

I mean, NUD won't work, and NA won't help, at the speeds
of interest.

> coverage areas do you expect?

Vehicular motion should be squarely within our jurisdiction,
as one example.  WiMAX or LTE, with a more rational
approach to link establishment, or WiFi on the streetlamps,
should be possible.

> is not much further away.
It's a factor of six away.  And your failure phenomena grow
quadratically in two dimensions.  So we're already talking
almost two orders of magnitude (check your log tables).
And twenty nodes is nothing.

>
> If there is a risk of a  massive collision problem with RAs I can 
> think of re-using the RA sending in an exponential back-off manner to 
> avoid collisions.  Not sure to which extent is it implemented, and if 
> it is not, we will look into it.
Please report your findings.

> Nein, Charles.  I believe in the solid robustness of the IP stacks I 
> am using.

I notice that your belief system extends to DHCP and NA.  Other 
practitioners
who have checked the underpinnings of these belief systems have reached
other conclusions.

>   If these things you talk about happen, I can correct them by either 
> re-specifying, or better implementing.

I think you ought to do that before fixing into concrete the
reliability of your belief system.

>
> Until I see these problems in practice I can't agree with you.  I 
> would even challenge you whether you talk implementation experience 
> here, or logical extension of conceptual aspects.

It is true that I have not implemented AODV with thousands of
nodes.  It has been simulated to over ten thousand nodes.
Even with the improved scalability afforded by non-adherence
to NUD/NA/..., the scalability stinks.  If we are further crippled
by the aforementioned devices, the scalability will be limited to
merely laboratory curiosities.

> Charles, ok, you make it sound scaring.  What happens in my lab is 
> very friendly.
Three nodes.

>
> LArger tests are planned (to the extent of  what wifi link layer 
> allows - surely not thousands).

You are designing for (single-subnet ??) WiFi.  I didn't think this was 
a WiFi-only
group.  I also think we have to allow for multi-hop transmissions beyond 
the range of
any one node in the network.  Do you disagree?

> routing.  That means several interfaces on a node.

I like routing.  I think it's a great idea.  I think it is wrong to
establish the uniqueness of link-layer addresses by routing.
Of course, uniqueness by fiat seems to work for those who
have it handy.

> all-node-multicast link-local scope.

This is exactly the point.  We want to have large deployments
NOT all on the same subnet!  Do you only want single-subnet
deployments??
> AODV - is a good thing from what I read.  I have never tried it in 

AODV needs major improvements.  I know what needs to
be done, but I can't do it right now.  [hint to Thomas :-)]
>
> SOmetimes people ask why don't I use AODV or OLSR on the mobile 
> routers in vehicles I talked about - and then I say maybe they're too 
> heavy for what's needed in some particular cases. And I am afraid 
> there's no consensus on either one.

They are too heavy -- but compared to DAD and NUD, they are
light as a feather.

> I disagree.  One prefix per interface is better.

Then we're back to figuring out why a node with a single
radio channel should have multiple network interfaces.

>> D and B is happy with A, they might never learn about

I'm pretty sure you can't do that at scale.

> Unrecommending them is what DT document does.  It's not forbidding, it 

So why would the document recommend them?  Why
can't we just leave them alone?

> Depends on the scenario - vehicles on a highway, wagons of a train, 
> and others are very much rectilinear topologies.
They are _vaguely_ rectilinear, sometimes.
I recall that this has some impact when designing
techniques for fixing locations and interpolating,
but not too much help for routing.

> I do about the ones I need.  IT helps me understanding and 
> communicating them.
>

Do you mean to say that we can only understand rectilinear
networks?  Then I insist that you must speak for yourself, and
furthermore that [autoconf] must not place this restriction.

> Any subnetting into those?  (just curious).

Yes, we made extensive investigation into the
requirements for subnetting.  It was an interesting
exercise, to figure out various implications on ICMP
and so on.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Oct 2009 23:10:41 +0200

Charles, I again loose focus.

Let me summarize.  We (CP and yours truly) don't agree on the following: 
the number of ifaces on a node, the necessity to consider
specific topologies and movement descriptions, ND is good or not for
here, scalability of RAs on same link, DHCP is good or not for here,
size of subnets and number of nodes, necessity to limit or not to WiFi, 
number of intermediary hops.

We agree on some minor things which won't lead me anywhere.

For link-locals, Charles suggests we should leave them alone.

Alex
PS: below answers I owe to your questions, FWIW.

> transmissions, spectrum utilization, channel assignment, and all 
> that.  If you just have one radio channel, I am pretty sure that you 
> will get into deep trouble trying to model it as numerous network 
> interfaces.
> 
> Which is not to make any limitations on the number of subnet prefixes
>  you may choose to assign to that singular interface.  But multiple 
> _network interfaces_?  I guess they must all be virtual :-).

Either.

I prefer to start with at least two physical interfaces per node when
doing routing.  If not possible then see whether the link-layer can
offer two virtual interfaces on a single physical interface (wifi can).

If that is not possible either... hard to see doing IP routing any further.

[...]

>> think of re-using the RA sending in an exponential back-off manner 
>> to avoid collisions.  Not sure to which extent is it implemented, 
>> and if it is not, we will look into it.
> 

Well yes, in the future, maybe.  I am not sure whether I do it here or
in MEXT.  I am not sure whether anyone needs it at all anyways.  My
developments are good for me, for my work and for my projects.

If I had to struggle 1 year now to get the link-locals accepted here
imagine when I post a draft making exclusive use of them :-)

Look at Carlos draft saying LLs are a MUST, which is just a reiteration
of existing things - immediate pushback :-(

[...]

> You are designing for (single-subnet ??) WiFi.

YEs, it is exchanging RAs on a single subnet WiFi, which has no prefix
on it other than the link-local addresses and prefix fe80.

It is egress interfaces of Mobile Routers, ifaces put together in 
"ad-hoc" mode.  The ingress ifaces are also wifi but different essids, 
different channels, no "ad-hoc" mode, etc.

The nodes "behind" the Mobile Routers use global IP addresses, yet their
egress interfaces are exclusively link-locally addressed.

> I didn't think this was a WiFi-only group.

Ok.

> I also think we have to allow for multi-hop transmissions beyond the
> range of any one node in the network.  Do you disagree?

Depends what you mean by multi-hop.  There are some star topologies 
which have very few IP hops in between (2, 3max) and which can work if 
the inner core is exclusively link-locally addressed.

This is a goal which is reachable.

But once you start talking multi-hop like unlimited number of IP hops in 
between, with thousands of nodes, with arbitrarily varying topologies 
that even a simple human can't describe - this goal is not reachable.

>> If I had 1000s of nodes then I would _subnet_ this with routers in 
>> the middle -- for sure!  That means at least bridging, and most 
>> probably routing.  That means several interfaces on a node.
> 

Well I don't propose to establish the uniqueness of link-layer addresses 
by routing.  They're inherently unique because of the nature of the 
considered link layer - wifi.

>> There exists practically no digital wireless link layer I am aware 
>> of which supports thousands of nodes within direct IP reach, same 
>> subnet, all-node-multicast link-local scope.
> 
> This is exactly the point.  We want to have large deployments NOT all
>  on the same subnet!  Do you only want single-subnet deployments??

I want the _core_ of my MR-to-MR communications to be exclusively 
link-locally addressed.  IT is small in terms of number of intermediary 
hops.  It is understandable.  It does not use thousands of nodes on that 
core.

There are of course several subnets, and one of them is the "core" if I 
can name it so.

There is no magic in what I propose.

[...]

>>>> This can be achieved as follows: -on each interface of each 
>>>> node pre-configure a unique /64 subnet prefix.
>>> I'd say one per node.
>> 
> Then we're back to figuring out why a node with a single radio 
> channel should have multiple network interfaces.

I would go as far as putting two such nodes together such that I can get 
two interfaces on the union node and IP route between them naturally.

>> Unrecommending them is what DT document does.  It's not forbidding,
>>  it is not recommending.
> 
> So why would the document recommend them?  Why can't we just leave 
> them alone?

Ok!  LEave them alone.  State in the document "we leave the LLs alone".

Unfortunately now it unrecommends them.

[...]

>>> The other networks are, however, much harder to draw with ASCII 
>>> stick figures.
>> 
>> YEs.
>> 
> Do you mean to say that we can only understand rectilinear networks? 
> Then I insist that you must speak for yourself, and furthermore that 
> [autoconf] must not place this restriction.

WEll, I meant that rectilinear topologies like this:

   Node1----Node2----Node3---....---Noden

Where intermediary nodes each has 2 interfaces are easy to understand 
and deploy IP on them.  "Rectilinear" is probably not the right term, 
because I don't impose a restriction on the physical disposition - they 
could be in a circle too, for example.

But I require that each of the intermediary nodes has two interfaces.

This topoology is easy to understand and deploy IP on.

And yes I speak for myself.  And yes, I know you don't want to restrict 
to _any_ kind of particular topology, be that rectilinear, circle or any 
other form or shape, and that there exist imagination enough to come up 
with topologies which nobody else has ever imagined before.  IT's a good 
research topic.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 22 Oct 2009 14:53:59 -0700

Hello Alex,

> Charles, I again loose focus.

I can help.

>
> Let me summarize.  We (CP and yours truly) don't agree on the 
> following: the number of ifaces on a node,

I do not restrict to multiple interfaces, and you do.

> the necessity to consider
> specific topologies and movement descriptions,

I think autoconf should not be restricted to particular topologies,
and you seem to.  I do not think we should restrict movements,
and your implication is that you do think we should.

> ND is good or not for

Well, I showed why they won't work.

> size of subnets and number of nodes, necessity to limit or not to 
> WiFi, number of intermediary hops.

I do not restrict, and you seem to restrict.

> For link-locals, Charles suggests we should leave them alone.

To be more precise, I think we should make it clear that link-local
addresses are not required because uniqueness is not necessarily
guaranteed (and difficult to assure) for non-IEEE interfaces.

> If that is not possible either... hard to see doing IP routing any 

Well, we did it, and lots of other people did it.  If you want to see
it, there are numerous papers.  It's not hard to see.

> imagine when I post a draft making exclusive use of them :-)
Post away.  I hope you test it on more than three nodes.

> of existing things - immediate pushback :-(

The point is that we can't use existing things.

> on it other than the link-local addresses and prefix fe80.

And you don't want to allow other people to design more
general systems??

> different channels, no "ad-hoc" mode, etc.

Hmm...  no "ad-hoc" mode.... hmmm....   a very poor
fit for [manet] routing protocols.

> egress interfaces are exclusively link-locally addressed.
What if there aren't any nodes "behind" any other nodes?

> This is a goal which is reachable.

There are many good reachable goals -- goals which HAVE been reached
in previous work.  Goals that go far beyond this terrible restriction.  
Goals
that deal with networks with _no_ "inner core".  Do you deny that
these goals are worthwhile to reach with standardized solutions?

>
> But once you start talking multi-hop like unlimited number of IP hops 
> in between, with thousands of nodes, with arbitrarily varying 
> topologies that even a simple human can't describe - this goal is not 
> reachable.

It has been reached.  Your statement is wrong.

> Well I don't propose to establish the uniqueness of link-layer 
> addresses by routing.  They're inherently unique because of the nature 
> of the considered link layer - wifi.

That should be a separate document, maybe from a separate group,
with people who want a more restricted focus.  And even with the
restricted focus I predict it will fail if you rely on ND and DHCP.

> link-locally addressed.  IT is small in terms of number of 
> intermediary hops.  It is understandable.  It does not use thousands 
> of nodes on that core.

I don't want to mandate reliance on any such core.
I thought we were dealing with _ad-hoc_ networks.

>
> There are of course several subnets, and one of them is the "core" if 
> I can name it so.
>
What you propose is needlessly restrictive to impose on
all working group solutions.

> I would go as far as putting two such nodes together such that I can 
> get two interfaces on the union node and IP route between them naturally.

Not very economically viable.  Mandating this is a
prescription for almost certain failure.

> Unfortunately now it unrecommends them.

To be precise, it points out where the dangers lie.

> because I don't impose a restriction on the physical disposition - 
> they could be in a circle too, for example.
>
That's a really really bad idea I think.

> This topoology is easy to understand and deploy IP on.

Why not restrict to topologies of only two nodes?

Or even just one node?

Those topologies are even easier to understand.

>
> And yes I speak for myself.  And yes, I know you don't want to 
> restrict to _any_ kind of particular topology, be that rectilinear, 
> circle or any other form or shape, and that there exist imagination 
> enough to come up with topologies which nobody else has ever imagined 
> before.  IT's a good research topic.

It's a good topic for standardization.  And, to be perfectly
frank, you cannot identify the topology of the Internet
either.  I can't imagine wanting to restrict the Internet to
conform to only certain topologies.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Oct 2009 00:38:10 +0200

Discussions on restrictions,

I propose numerous constraints on the size and type of the topology such 
that the topic can be tackled.

Charles proposes to not have any restriction of this kind.

Charles finally uses a strong argument: there are no restrictions on the 
Internet topology either, so supposedly there should be no restrictions 
in the AUTOCONF topology either.

Are we developing a new Internet here in AUTOCONF?

Charles also expresses doubts: even if such restrictions are in place, 
the use of ND and DHCP is not promissing.

Alex

Charles E. Perkins a écrit :
>> If I had to struggle 1 year now to get the link-locals accepted
>> here imagine when I post a draft making exclusive use of them :-)
>> Look at Carlos draft saying LLs are a MUST, which is just a
>> reiteration of existing things - immediate pushback :-(
> 
>> YEs, it is exchanging RAs on a single subnet WiFi, which has no
>> prefix on it other than the link-local addresses and prefix fe80.
> 
> And you don't want to allow other people to design more general
> systems??
> 
>> 
>> "ad-hoc" mode.  The ingress ifaces are also wifi but different
>> essids, different channels, no "ad-hoc" mode, etc.
> 
> Hmm...  no "ad-hoc" mode.... hmmm....   a very poor fit for [manet]
> routing protocols.
> 
>> 
>> The nodes "behind" the Mobile Routers use global IP addresses, yet
>> their egress interfaces are exclusively link-locally addressed.
>>> I also think we have to allow for multi-hop transmissions beyond
>>> the range of any one node in the network.  Do you disagree?
>> 
>>  which have very few IP hops in between (2, 3max) and which can
>> work if the inner core is exclusively link-locally addressed.
>> 
> in previous work.  Goals that go far beyond this terrible
> restriction. Goals that deal with networks with _no_ "inner core".
> Do you deny that these goals are worthwhile to reach with
> standardized solutions?
> 
>> 
>> But once you start talking multi-hop like unlimited number of IP
>> hops in between, with thousands of nodes, with arbitrarily varying
>>  topologies that even a simple human can't describe - this goal is
>> not reachable.
> 
>>>> If I had 1000s of nodes then I would _subnet_ this with routers
>>>> in the middle -- for sure!  That means at least bridging, and
>>>> most probably routing.  That means several interfaces on a
>>>> node.
>>> 
>>> I like routing.  I think it's a great idea.  I think it is wrong
>>> to establish the uniqueness of link-layer addresses by routing.
>> 
>> addresses by routing.  They're inherently unique because of the
>> nature of the considered link layer - wifi.
> 
> That should be a separate document, maybe from a separate group, with
> people who want a more restricted focus.  And even with the 
>> intermediary hops.  It is understandable.  It does not use
>> thousands of nodes on that core.
> 
> I don't want to mandate reliance on any such core. I thought we were
> dealing with _ad-hoc_ networks.
> 
> 
>> 
>> There are of course several subnets, and one of them is the "core"
>> if I can name it so.
>> 
> What you propose is needlessly restrictive to impose on all working
> group solutions.
> 
>> 
>>> 
>> I would go as far as putting two such nodes together such that I
>> can get two interfaces on the union node and IP route between them
>> naturally.
> 
> Not very economically viable.  Mandating this is a prescription for
> almost certain failure.
> 
>>> 
>>> So why would the document recommend them?  Why can't we just
>>> leave them alone?
>> 
>> Where intermediary nodes each has 2 interfaces are easy to
>> understand and deploy IP on them.  "Rectilinear" is probably not
>> the right term, because I don't impose a restriction on the
>> physical disposition - they could be in a circle too, for example.
>> 
>>  circle or any other form or shape, and that there exist
>> imagination enough to come up with topologies which nobody else has
>> ever imagined before.  IT's a good research topic.
> 
> It's a good topic for standardization.  And, to be perfectly frank,
> you cannot identify the topology of the Internet either.  I can't
> imagine wanting to restrict the Internet to conform to only certain
> topologies.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 23 Oct 2009 00:45:21 +0200

Dear Alex,

I think that the point Charlie is trying to make is, that the  
constraints and restrictions that you propose do not correspond to the  
reality of the MANETs that are in operation today....

How do the MANETs that you build look, Alex?

Thomas

On Oct 23, 2009, at 12:38 AM, Alexandru Petrescu wrote:

> I propose numerous constraints on the size and type of the topology  
> such that the topic can be tackled.
>
> Charles finally uses a strong argument: there are no restrictions on  
> the Internet topology either, so supposedly there should be no  
> restrictions in the AUTOCONF topology either.
>
> Charles also expresses doubts: even if such restrictions are in  
> place, the use of ND and DHCP is not promissing.
>
> Alex
>
>
>> There are many good reachable goals -- goals which HAVE been  
>> reached in previous work.  Goals that go far beyond this terrible

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Oct 2009 01:07:03 +0200

Hi Thomas,

> How do the MANETs that you build look, Alex?

The one network that I have now running in the lab and which may tempt 
somebody to call a MANET has 3 Mobile Routers.  That's it.  It's very 
stable physically, it's very constrained and is all planned in advance - 
it has nothing of the unplanned "adhoc"iness of unconstrained MANETs. 
Moreover it relies very much on the use of IPv6 link-local addresses.

Why?

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 23 Oct 2009 01:10:13 +0200

On Oct 23, 2009, at 1:07 AM, Alexandru Petrescu wrote:

>> constraints and restrictions that you propose do not correspond to  
>> the reality of the MANETs that are in operation today....
> The one network that I have now running in the lab and which may  
> tempt somebody to call a MANET has 3 Mobile Routers.  That's it.   
> It's very stable physically, it's very constrained and is all  
> planned in advance - it has nothing of the unplanned "adhoc"iness of  
> unconstrained MANETs. Moreover it relies very much on the use of  
> IPv6 link-local addresses.
>
> Why?

Just observing that this is a very very different from a typical MANET  
in pretty much every possible way.

Thomas

>>> I propose numerous constraints on the size and type of the  
>>> topology such that the topic can be tackled.
>>>
>>> Charles finally uses a strong argument: there are no restrictions  
>>> on the Internet topology either, so supposedly there should be no  
>>>>> It is egress interfaces of Mobile Routers, ifaces put together  
>>>>> in "ad-hoc" mode.  The ingress ifaces are also wifi but different
>>>> with
>>>>> I want the _core_ of my MR-to-MR communications to be  
>>>>> exclusively link-locally addressed.  IT is small in terms of  
>>>>> number of intermediary hops.  It is understandable.  It does not  
>>>>> use

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 23 Oct 2009 01:14:52 +0200

> IPv6 link-local addresses.

It just hit me....

MANET = Mobile Ad hoc NETwork

Your lab-network is stable (so not Mobile) and planned in advance (so  
not Ad hoc).

I'd suggest not extrapolating MANET behavior based on your  
observations from this (non-MANET) lab-network of yours.

Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Oct 2009 01:27:16 +0200

Thomas Heide Clausen a écrit :
>> stable physically, it's very constrained and is all planned in advance 
>> - it has nothing of the unplanned "adhoc"iness of unconstrained 
>> MANETs. Moreover it relies very much on the use of IPv6 link-local 
>> addresses.
>>
>> Why?
> 

Well ok, it's a good observation.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Oct 2009 01:32:23 +0200

Thomas Heide Clausen a écrit :
> I'd suggest not extrapolating MANET behavior based on your observations 
> from this (non-MANET) lab-network of yours.

Ok, suggestion taken.  You'll be surprised but I feel more comfortable 
calling it a "non-MANET lab-network of mine" :-)

Alex