On Fri, Feb 22, 2013 at 09:41:42AM +0900, Lorenzo Colitti wrote: > On Fri, Feb 22, 2013 at 4:23 AM, Fred Baker (fred) <[email protected]> wrote: > > > This is that separate email. As I start, may I make the most direct > > possible apology to my colleagues with other approaches. I'm going to say > > that I think you're "wrong", and say why. That is in the spirit of open > > discussion in which we have a technical disagreement. BTW, you should be > > aware that I have a fair set of people who are telling me I'm wrong as > > well, hopefully in the same spirit. Some of them are pretty irritated with > > me, and I have gotten irritated with them. > > > > For what it's worth, as as a co-author of draft-troan-homenet-sadr-00, I > don't think there is a disagreement. The draft cites your work, because we > (or at least, I) think that the correct approach is in fact one where the > routing protocol passes around source+destination routing pairs.
+1 > The reason why the draft also proposes a simplified version of SADR that > integrates with prefix assignment protocol is that it's possible to > implement this without having to make substantial changes to OSPF. > Extending the routing protocols will be a long and possibly hard road, and > we feel that the group should at least consider the possibility of an > approach with better time-to-market and lower barrier to implementation - > especially since the alternatives being proposed are hierarchical DHCPv6 PD > and NPT66. The risk is that we make the perfect the enemy of the good and > we end up with NPT66, which means that we will have thrown away the chance > for end-to-end IPv6 connectivity and will have to build apps in IPv6 just > as we did in IPv4 - forever trying to guess what their addresses are, which > magic packet incancation will work, and which third-party server is the > best to relay packets through. I have the fear that this will come around and do some ass-biting. This is a very subjective opinion of course, but I think it's reasonable to assume that if this ships, it will stick around for years to come. Lots of people never update their CPEs (which is obviously bad and leads to security problems, but we can't will that away...) So, even if we later go the "full-blown" way, we'll have to be interoperable with those will-be Simple SADR relicts. > On the OSPF vs. IS-IS choice... well, if we had an implementation of ISIS > that could run on home networking devices, or if there was at least one on > the horizon, things would be very different. There are in fact 2 implementations of IS-IS that may run on home networking devices, in different states. - BIRD seems to be interested in adding IS-IS due to interest from SPs. A branch exists, but not much progress has been made: [https://redmine.labs.nic.cz/projects/bird/repository?utf8=%E2%9C%93&rev=isis] - (Disclaimer: I'm the Quagga maintainer) Quagga has had bad IS-IS support for a long time. It has been overhauled and that overhaul was integrated in April 2012. I've had the pleasure of declaring it "beta" in the last release, although we're still squashing bugs here and there. [http://savannah.nongnu.org/forum/forum.php?forum_id=7501] Both BIRD and Quagga are readily available on OpenWRT derivatives and should run reasonably fine on limited-resources CPE devices. Both are released under the GNU GPL (v2+). -David _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
