Le 24/03/2015 19:01, Juliusz Chroboczek a écrit :
Before we lose this, let it be noted that we seemed to have arrived
at "no" for an answer to whether we want to deal with
non-transitive networks, *as part of this particular routing
protocol discussion*.
This is what the protocol comparison draft has to say on the
subject:
We believe that IBSS may be out of scope for Homenet, but we expect
that people will attempt to use the Homenet protocols in IBSS mode,
whether we like it or not.
Well, you can put IBSS out of scope for homenet WG, but nobody can stop
one to set an IBSS mode in a home network.
This is a confusion about the use of the term 'home networking and
homenet WG'.
Without special ND handling, Hidden nodes will fail DAD, and you
can't expect to get a mac address for a node you don't get
multicast to.
I agree. If we assume unmodified clients, then IBSS is only suitable
for router-to-router links. However, I think that Homenet needs a
killer feature, and almost-zeroconf router-to-router wireless links
might be it.
There are a few such killer features but they dont seem to be considered
in homenet WG.
To find one it is very easy: express a problem you have encountered.
Buy a modern home device bring it home and tell what was the difficulty
in setting it up. There are many simple problems immediately exposed:
how is IPv6 running (is it NAT? is it PD? is it ULA? is it running DHCP?).
Ask your DSL operator what IPv6 and how. In France there are now two
IPv6-enabled DSL operators for the user lambda (not professional) and
you'll see how they need some feature. For example Free IPv6 DSL only
allows setting routes manually by filling in forms in a webpage -
automate that. Orange IPv6 DSL is nascent yesterday - what are the
problems there?
(Now I happen to believe that if Homenet is successful, we will get
modified clients -- think Android -- but I realise that this opinion
does not necessarily reflect the consensus of this group.)
I *don't* think meshes are out of scope for homenet. I do think
meshes need a mesh routing protocol.
I disagree. If you accept that a small mesh is a cheap and
convenient way to establish a router-to-router link, then you'll want
to avoid the tricky issues that come with running multiple routing
protocols (bidirectional redistribution at two distinct points within
the network, oh boy).
Multiple routing protocols is inevitable IMHO. To deal with it is like
dealing with OSPF and BGP - make them talk to each other.
(But then, I'm pretty much bound to disagree. The desire to have a
single routing protocol that you let loose on a highly heterogeneous
network and it just works is the main driver behind Babel.)
A single routing protocol is a good goal to state at WG meeting decision
time. But it often leads to actually new protocol which will be the
one. We've seen that recently with RPL - that's the one. There is even
a set of requirements for it in the home networks (RFC).
Should we enumerate all routing protocols which are 'the one'?
we would be talking about AP / BSS, not ad-hoc / IBSS [...]
Massively reduced marginal links (because when you start losing
beacons between AP and Client, you'll be deassociated.)
I strongly disagree. By default, the Linux Intel driver will
perform recalibration after it misses 5 beacons in a row. You can
have a perfectly functional yet clearly marginal link in AP/STA
mode.
Maybe yes, with that particular driver.
Alex
-- Juliusz
_______________________________________________ homenet mailing list
homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
