On Aug 11, 2017, at 12:07 PM, Juliusz Chroboczek <j...@irif.fr> wrote: >> This is a refrain I've heard from you, Juliusz and Markus, which I actually >> find a bit disturbing: the desire not to really solve the problem because >> it's >> not trivially easy. > > If I were in a bad mood, I'd say that the three of us prefer simple, robust > solutions that solve actual problems to complex, brittle hacks that are > not going to be implemented anyway.
Forgive me, Juliusz, but I don't lecture you on routing protocols, do I? You are objecting to something that you don't see the need for, but the reason you don't see the need for it is not that there isn't a need for it. It's that you haven't clearly understood the problem. Now, you could certainly point the finger of blame at me for failing to explain it adequately, but I would appreciate it if you could do me the courtesy of not assuming that I am just trying to come up with a "complex, brittle hack that's not going to be implemented anyway" for my own amusement. >> Think about the routing problem. We need source-specific routes. We're >> extending babel to add them. Why is that? Couldn't we have just relied >> on happy eyeballs to eliminate the bad routes? > > No, we couldn't. Happy eyeballs (or MP-TCP, or MP-QUIC, or MP-Mosh) uses > the services provided by source-specific routing. They work in combination. > > (Come on, Ted. You already knew that.) Yes, I did, and that was precisely my point. We need source-specific routing because happy eyeballs doesn't solve the problem: we want to support multi-homing, and that requires a more complex solution than would be needed if we could mandate that homenets have only a single connection to the internet. Mandating that homenets only have one Internet link would make the solution substantially less complex. Source-specific routing, however, is an incomplete solution. Having chosen the correct route based on the source address, we still have the problem that one provider connection may be better than another for connecting to a particular destination, and there may be no way to figure that out using the default source address selection algorithm, or even by using a more detailed source address selection algorithm configured by DHCP. Indeed, this is likely, not unlikely. > This has nothing to do with the amount of flash or RAM. It has everything > to do with having protocols that can be implemented in finite time and > with a only a finite number of bugs, and with building networks that can > survive whatever bugs remain. I agree that we should not propose solutions that can only be implemented in an infinite amount of time. But we already have implementations of MPvD support from several vendors. So it's not even the case that the amount of time required to do this is long. It's already mostly done for several important hosts, and one of those hosts is a Linux host, so the solution that works there will also work on regular Linux. Implementing this on the router is straightforward. I believe that it could actually be done with no changes to dnsmasq, although a better solution would make some changes, because doing so would make configuring it easier. What I find completely perplexing about this conversation is that you, Markus and Toke, all of whom I know to be smart people, think this is hard. What is hard about it? I think the reason you think it's hard is simply that you don't know how to do it. The unknown always seems hard. That's something that we can fix by describing in the document how to do it. If, after that, you still think it's hard, (a) I will be very surprised, and (b) we can think about whether it's worth the trouble. _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
