Apologies for the duplicate. It was a manual error, not an automatic one. On Tue, Oct 7, 2014 at 4:14 PM, James Woodyatt <[email protected]> wrote:
> Everyone— > > I have skimmed I-D.ietf-homenet-prefix-assignment, and I have some > questions and a concern about the topic of ULA Prefix Generation and > specifically the requirements language used in section 9.1. > > > > <https://tools.ietf.org/html/draft-ietf-homenet-prefix-assignment-00#section-9.1> > > 9.1 > <https://tools.ietf.org/html/draft-ietf-homenet-prefix-assignment-00#section-9.1>. > ULA Prefix Generation > > A router MAY generate a ULA prefix when the two following conditions > > are met. > > o It is the Network Leader (Section 4.4 > <https://tools.ietf.org/html/draft-ietf-homenet-prefix-assignment-00#section-4.4>). > > o No other ULA delegated prefix is advertised by any other router. > > A router MUST stop advertising a spontaneously generated ULA prefix > > whenever another router is advertising a ULA delegated prefix. > > The most recently used ULA prefix SHOULD be stored in stable storage > > by all routers and reused whenever choosing a new ULA delegated > > prefix. If no ULA prefix can be found in stable storage, it MUST be > > randomly generated, or generated from hardware specific values. > > > The requirements keywords in this section make for a pretty serious > interop clash with Thread networks <http://threadgroup.org/>, which > generate their own ULA prefix based on a method defined by its current > conventions. > > If a Thread border router cannot publish its ULA prefix into the HOMENET > routing domain, unless it is the Network Leader (which it almost certainly > never will be), then this language would seem to force Thread border > routers not to use HOMENET standard protocols, and instead to implement > some kind of non-standard tunneling overlay between devices inside the > Thread mesh and hosts on the rest of the home network. > > Is that what the working group wants to happen? What is the intended > purpose of this requirement? Is there a way the intended purpose can be > served without breaking interop with Thread networks? > > (My apologies if I missed the relevant discussion. I was trying to pay > attention, but regular life has been assailing me with other concerns over > the last year or so. I'm on top of things now, though.) > > -- > james woodyatt <[email protected]> > Nest Labs, Communications Engineering > -- james woodyatt <[email protected]> Nest Labs, Communications Engineering
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
