Consider a hypothetical router that has the regular automatic default behavior of commissioning a new standalone network while discovering any existing networks that it already possesses the credentials to join. Now consider what happens when devices of this category are continually losing and regaining their connectivity with the rest of the wireless network in the home. Let's imagine this happens many times per hour. How many days does it take before all your constrained-resource hosts have no space left in their route tables for all the deprecated but still valid ULA prefixes?
I suggest it will not take very long at all. Any reasonably implemented host will be dropping them before they expire anyway, but hosts will be forced to use a crude heuristic to decide which prefix to expire first, e.g. lowest valid lifetime then first-in first-out? Routers are more knowledgeable about which prefixes are the locally generated ones and which ones are delegated. On Tue, Oct 14, 2014 at 4:40 PM, Dave Taht <dave.t...@gmail.com> wrote: > On Tue, Oct 14, 2014 at 2:40 PM, James Woodyatt <j...@nestlabs.com> wrote: > > On Tue, Oct 14, 2014 at 2:35 PM, Ted Lemon <mel...@fugue.com> wrote: > >> > >> > >> When we talked about this previously, I think the idea was that when two > >> networks with two sets of ULA prefixes merge, you deprecate one of them. > >> [...] > > > > > > Naturally, you deprecate one of them, but my concern is that they never > > expire if the objective is for a ULA prefix to be invariant. So how many > > times can a network join with others before it runs out of space for > > deprecated and redundant but unexpired and invariant ULA prefixes? > > > > 2^56 times I think... > > ... but the network itself would expire long before then. :) > > What's a more reasonable bound? What's the bound before a given > network would collapse from multicast joins alone? > > -- > > james woodyatt <j...@nestlabs.com> > > Nest Labs, Communications Engineering > > > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > > > > > > -- > Dave Täht > > thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks > -- james woodyatt <j...@nestlabs.com> Nest Labs, Communications Engineering
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
