On 31.8.2015, at 14.17, Henning Rogge <[email protected]> wrote: > On Mon, Aug 31, 2015 at 12:44 PM, Markus Stenberg > <[email protected]> wrote: >> Let’s assume a shared link with 2 homenet routers (rid1, rid2) and 1 host >> (foo). >> >> Given no election, use of e.g. mDNS to determine hosts/services would result >> in the host showing under both rid1.home and rid2.home. That isn’t a problem >> in naming case (you have IP => name, and name => IP resolving), but for >> service discovery it kind of sucks. > Okay, I see the problem with the hierarchical namespace when two when > we have this "host switched to multiple HNCP routers" situation. > > It would be great if we would get one common (m)DNS name for the host, > even if it got multiple IP addresses.
I agree, and I would add that it stayed constant when the host moves.. (this brings us firmly to dns-update / node name TLV territory though I think) > Would it be a solution to use a DNS "second level" name for each > ethernet segment with hosts attached but NOT include the routers into > the DNS name? If you connect two homenet routers to the same ethernet > segment, they should know because they see each others HNCP packets > (unless its a LEAF interface... which contradicts the switched > situation a little bit). Both sides could agree on a common "Link > segment” name and announce the host with "host1.link-segment.home". Sure, you can define link segment name election mechanism and use per-link names (they are even mentioned as an option in draft-ietf-homenet-stenberg-hybrid-proxy-zeroconf; see also why doing that zeroconf might be bad idea), but I am not sure it is any cleaner than just electing single router to be responsible for it and using per-link+router names. That draft is intentionally NOT referred to in HNCP itself due to hybrid proxy dependency. Cheers, -Markus _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
