[homenet] Review of draft-lemon-stub-networks-00

Jonathan Hui <jonhui@google.com> Fri, 26 February 2021 19:07 UTC

MIME-Version: 1.0
From: Jonathan Hui <jonhui@google.com>
Date: Fri, 26 Feb 2021 11:07:08 -0800
Message-ID: <CAGwZUDthsDwLQZE_8AgY0DUXiThTGci3S6EjdsPDb8Wgr7JEBQ@mail.gmail.com>
To: homenet@ietf.org, iotops@ietf.org, 6man@ietf.org
Content-Type: multipart/alternative; boundary="0000000000003080b505bc41fa2c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/vaZpAnGtXNGIVzHleXr_jh9JecU>
Subject: [homenet] Review of draft-lemon-stub-networks-00
Precedence: list

I have reviewed this document.

I believe this document addresses a key problem in connecting constrained
networks to more traditional networks. The Thread Group and Project CHIP
(both IPv6 based) require this guidance to be successful. At the same time,
I agree this document has broader applicability than constrained stub
networks. Thanks, Ted!

Some comments/questions below:

Section 3.1
- "In this case, the stub router SHOULD NOT provide addressability on the
adjacent infrastructure link." - I wonder if there are scenarios where the
existing addressing is not stable (e.g. when provided by an external
entity). Constrained devices would rather avoid having to determine that an
existing IPv6 address is unreachable and discover the new IPv6 address.
Having the stub router guarantee stable IPv6 addressing can reduce overhead
on stub network devices. For example, I'm wondering if it's useful for the
stub router to provide a ULA prefix if only a GUA prefix is being
advertised and no ULA prefix exists.

Section 3.1.1
- "router discovery" - Should we capitalize and explicitly reference RFC
4861?
- "a usable prefixes" -> "a usable prefix"

Section 3.1.2
- "IP addressability becomes present on adjacent infrastructure link" - was
more text intended here?

Section 3.1.3
- This section describes how to avoid creating duplicate on-link prefixes.
Should we also discuss how to avoid deprecating multiple on-link prefixes
simultaneously in the case that duplicates do occur? In particular, how do
we ensure convergence on one prefix?

Section 3.3
- "Stub routers MUST advertise reachability to stub network OSNR prefixes
on any AIL to which they are connected." Should we consider limiting which
stub routers advertise reachability if there are a large number of stub
routers?

- "reachability to all such links" should be "reachability to all such
prefixes"?

Section 3.4
- "If the stub router is not advertising itself as a default on the stub
network, it MUST advertise reachability to any prefixes that are being
advertised as on-link on AILs to which it is attached." I think we should
consider reachability to other stub networks in addition to the AIL. In
this case, the stub router must also advertise reachability to prefixes
advertised in RIOs.

Also, similar to Section 3.3, should we consider limiting which stub
routers advertise reachability if there are a large number of stub routers?

- "Consequently, stub routers SHOULD be configurable to not advertise
themselves as default routers on the stub network." In some cases, I think
it may be possible for a stub router to automatically determine that there
is another stub router attached to the same stub network but not the same
AIL.

Section 3.5
- "be able to discovery devices" -> "be able to discover devices"
- add references to SRP, Advertising Proxy, etc.

Section 3.6
- add reference to Discovery Proxy.

Section 4.1
- "traffix" -> "traffic"

Section 4.2
- "WFfi" -> "WiFi"

Section 5
- Should we recommend some way to deterministically converge on one prefix
when deprecating?

Section 6
- "effected" -> "affected"

Section 6.2
- "off-mesh" -> "Off-Stub-Network"

Section 6.3
- How does the infrastructure advertise availability of the SRP service? If
out of scope, maybe state that?

--
Jonathan Hui

[homenet] Review of draft-lemon-stub-networks-00 Jonathan Hui
Re: [homenet] Review of draft-lemon-stub-networks… Ted Lemon