Date: Sat, 17 Nov 2007 08:43:56 -0800 From: Julian Elischer <julian@elischer.org> To: Marko Zec <zec@icir.org> Cc: Reinhard Haller <reinhard.haller@interactive-net.de>, Bruce M Simpson <bms@incunabulum.net>, Robert Watson <rwatson@freebsd.org>, freebsd-current@freebsd.org Subject: Re: 7.0-BETA2 routed and multicast registration Message-ID: <473F1A4C.4020009@elischer.org> In-Reply-To: <200711171428.13522.zec@icir.org> References: <4732110D.3090808@interactive-net.de> <200711171227.21855.zec@icir.org> <473EE26E.6050905@incunabulum.net> <200711171428.13522.zec@icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Marko Zec wrote: > On Saturday 17 November 2007 12:45:34 Bruce M Simpson wrote: >> Marko Zec wrote: >>> Note that with a recent port of Quagga multicast doesn't work as >>> well, so now we don't have neither RIP nor OSPF support there which >>> is kind of funny. Though I think it's not only the missing RFC1724 >>> support in the kernel that is crippling mcast support in Quagga... >> We all know that major point releases are the place for changes like >> this to happen. >> >> It's been over 6 months since these changes were committed, and >> heads-up messages were sent to the appropriate lists. I guess the >> bigger question is, why is this a problem now? >> >> The reasoning behind the change is quite clear, to support IP >> multicast in new network environments, e.g. mobile and ad-hoc IP, as >> well as supporting source-specific multicast, we SHOULD be following >> a published API which supports those environments, rather than >> relying on a hack which was clearly only ever intended as a temporary >> workaround, and highly specific to FreeBSD's IP implementation. >> >> RFC 3678 specifies such an API. It is over 3 years old. Andre had >> given backing to deprecating the 0.0.0.0/8 hack when I announced my >> intentions on -net. > > Nobody is questioning the benefits of having RFC 3678 support added to > the kernel, but quickly skimming through that document I can't find a > line stipulating that it should deprecate older interfaces already in > use. What is the exact benefit of deprecating the 0.0.0.0/8 hack (i.e. > RFC 1724 compliant ifnet addressing), i.e. why couldn't we have support > for both the new and the old interface for legacy applications, given > that the interfaces don't seem to be in conflict? probably we should have the hack, clearly marked and disabled by default. > > Marko > >> Also, supporting a published API brings FreeBSD back up to par with >> its competitors in this area (i.e. Linux, Windows). Otherwise, we >> perpetuate a kludge at the expense of progress in other areas of >> IPv4/IPv6. >> >> If you check the archives for -current you'll see that Ian Frieslich >> had contacted the Quagga maintainers about the change, the outcome of >> this discussion I don't know. 3rd party applications are beyond >> FreeBSD's control, or mine, for that matter. [*] >> >> I did however spend time on routed support, which I am happy to do as >> it hasn't been moved to ports (it is still part of the base system), >> and made it clear that this patch was available to work from, and >> that people were most very welcome to contact me about the matter to >> get RFC 3678 support into these applications. >> >> Now, my situation is not so free and fluid, as I am in the thick of a >> new project and have sadly little free time as it is to do work >> outside the scope of that project. >> >> If we collectively are satisfied that this change is a change too far >> on this occasion, then I retract my objection to ip_multicast_if() >> being re-imported, on the grounds that its deprecation has >> inadvertently broken user applications, on the grounds that 6 months >> was, apparently, not enough notice for the maintainers of these >> applications to take action. >> >> However, I register a very strong technical objection to this patch >> on the grounds that this is an area where open source networking >> needs to move ahead. POLA wasn't violated on this occasion, as the >> scope of the work happened entirely within -CURRENT, and the >> appropriate individuals were notified of the changes. >> >> These are the facts as I see them, I am very happy to hear feedback >> from others. >> >> Sadly I can't get actively involved in proactively fixing the >> situation at the present time i.e. at the level of code, and >> besides... that's going to require communication and coordination >> between all the people involved, the lack of which it seems has >> created an unnecessary situation. >> >> very best, >> BMS >> >> [* The Quagga maintainers should know better -- Linux is after all >> their main development platform, and it has supported RFC 3678 for >> some time now.] > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?473F1A4C.4020009>