Valdis.Kletnieks@vt.edu wrote:
According to the end to end argument, the only possible solution to the problem, with no complete or correct alternatives, is to let hosts directly participate in IGP activities.
That's only for hosts that are actively trying to communicate on more than one interface at a time,
Note that the end to end argument has the following statement I omitted to quote: (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.) That is, there are incomplete solutions by intermediate systems which sometimes work.
and even then quite often the *actual* right answer isn't "run an IGP", it's "insert static routes for the subnets you need to reach via the other interface"(*).
With manual configuration, you can do anything. But, aren't we talking about autoconfiguration?
If it's a laptop that has both a wireless and a wired connection active, usually a simple "prefer wired" or "prefer wireless" is sufficient.
Usually? Can you see the word "complete" in the end to end argument?
Quick sanity check on the hypothesis: Does Windows ship with an IGP enabled by default?
Sanity check with Windows? Are you sure?
If not, why does the net continue to function just fine without it?
It is often incomplete and incorrect unnecessarily requiring manual reconfigurations.
(*) If you think I'm going to run an IGP on some of my file servers when "default route to the world out the public 1G interface, and 5 static routes describing the private 10G network" is actually the *desired* semantic because if anybody re-engineers the 10G net enough to make me change the routes, I have *other* things to change as well, like iptables entries and /etc/exports and so on. I don't *want* an IGP changing that stuff around wiithout the liveware taking a meeting to discuss deployment of the change.
If you are saying SLAAC is not enough in your case with complicated manual management, I don't think I have to argue against you on how to simplify it. Masataka Ohta