Re: [homenet] I-D.ietf-homenet-prefix-assignment

[James Woodyatt <[e-mail]>]

Apologies for the duplicate. It was a manual error, not an automatic one.

On Tue, Oct 7, 2014 at 4:14 PM, James Woodyatt <[e-mail]> 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 <[e-mail]>
> Nest Labs, Communications Engineering
>



-- 
james woodyatt <[e-mail]>
Nest Labs, Communications Engineering