At Tue, 30 Apr 2002 15:56:12 +0200, Hesham Soliman wrote: > > Which boxes does it add? I really don't see any more boxes > here. Note, I'm not advocating this particular approach (injecting > routes from the DNS) but I don't agree with your claim above, and I > think it can work.
This approach would bring the DNS server boxes inside the trust boundary of the routers. They're not there now, and if the prospect of bringing them inside that trust boundary doesn't strike terror in your heart, you need to spend more time reading bugtraq. :) > I think something like MLD extensions would be much cleaner. I agree that something like the MLD extensions would almost certainly be a cleaner approach than having the DNS servers play routing games directly. > I believe you :), in fact, since you read the draft (twice now ;) ) > you would have seen that DHCP messages were also considered for the > 'content' part of the discovery. DHCP messages are not discussed in the stateless DNS discovery draft. Perhaps you're referring to the design team analysis draft? Don't worry, I read that too. > I think you're mixing the 'content' of the message used for > discovery and the method used for transporting that message to the > right server. Anycast does the latter. So I don't know why you're > comparing anycast with DHCP. DHCP can also use anycast in theory, I > never tried it. Service discovery via anycast has specific problems that I tried to detail in a previous message. In brief: using anycast in effect stores the configuration in the routing system itself and leaves the client with no recourse if the routing system (for whatever reason) gives answers that are not useful. This might be construed as ok if one assumes that the failure modes are all binary (either everything's working perfectly or everything's so broken that it doesn't matter), but I don't think that assumption is realistic, so the fundamental model of service discovery via anycast seems broken to me. I agree that the choice of message format is pretty much orthogonal to the method used for getting the location query to the entity that's going to answer them. There's a different set of issues involved in the choice of message format, which I'd sum up by saying that I think it'd be better to do configuration using a protocol that was designed for the purpose than it would be to retrofit configuration hacks onto a protocol that was designed to do something else. I don't think it'd be particularly useful to the WG to dive much further down that particular rathole right now, so with your permission I'll stop there. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
