On 26.8.2015, at 12.39, Henning Rogge <[email protected]> wrote: > My problem is not with the prefixes assigned to the interfaces of HNCP > routers itself, my problem is with the prefixes provided to attached > hosts. > > If I understand HNCP right then the "uplink" will announce a prefix > which should be used by all routers for the attached hosts. > > The problem will appear if HNCP learns about this prefix through DNCP > but the routing protocol cannot provide a route to the uplink (because > hysteresis decided one of the links is too bad). > > I wonder if HNCP routers should apply all addresses/prefixes to its > local interfaces, but should check for an existing route to the HNCP > router that announce the prefix before providing it via DHCP or RA to > hosts.
I think this ties it too tightly to a RP; routes _can_ appear and disappear over time after all, so if you follow this logic to it’s logical conclusion, you would have to make decision that e.g. 95% of the time, this delegated prefix has functioned and it does not flap frequently, so we can subdelegate it. Leading to relatively much state duplicated both within RP (hysteresis) and HNCP daemon (long-term route validity/flap statistics/..). I would personally rather just say ’too bad’ in such a network :) YMMV of course. I would not personally mind _implementations_ that did this, given they knew they used RP with hysteresis, but I disagree with sticking this in base spec itself. Cheers, -Markus _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
