On Feb 26, 2021, at 11:24 AM, Michael Richardson <mcr+i...@sandelman.ca> wrote:
Thanks for the comments, Michael!
> I think that this is a key architectural document on connecting IoT networks,
> although there is some resistance to putting such a specific use case into
> the title.
The reason for this is that I think it’s a perfectly reasonable thing to do
when you just want to connect a router to a pre-existing network so that you
can use services on that network. So I really don’t want to constrain the use
case to IoT. That is certainly the primary driving use case, though.
> 1) Perhaps "Stub Router" should be in the terminology.
> The terms: AIL, NAIL, NAL and OSNR are introduced but aren't really used.
> They aren't really that pneumonic.
> If anything, I'd like a cool TLA for "Stub Router"
SNR? But that confuses OSNR. The reason for all those TLAs is that “Adjacent
infrastructure link” is a lot to type, and so is off-stub-network-routable
prefix. :]
> 2) There is advise about monitoring the RAs from the infrastructure router
> (which is probably the home CPE router), and soliciting them regularly.
> In effect, the Stub Router can't depend that the CPE router will remain
> alive for it's lifetime.
> That is, the RA lifetimes tell the client how long it may use the
> resource, but not how to determine if the router is alive. Of course,
> power can disappear at any time.
> Ted: it seems that maybe neigh-cache entries already have all the timers
> and rechecks needed, and maybe the Stub Router can just watch for
> the NCE going Stale?
That would work, but depends on the stub router implementation being able to
get a notification that this has happened, which means it’s running in the
kernel. I don’t think that’s a likely scenario. Also, NCEs have lifetimes, so
they will also outlive on-link routers.
> 3) _Adjacent infrastructure link (AIL)_ that's the home LAN, right?
> Maybe it would clearer if it was just called that?
The problem is that “home lan” presupposes a very limited use model, and this
is not intended to address just that use model. Stub network routers are
expected to be useful in building infrastructure deployments as well.
> 4) I'd like to add a state machine diagram to 3.1.1/3.1.2.
I think that’s a good idea, although I am not really a fan of state machine
*diagrams* — I’d maybe rather just describe the state machine. Diagrams are
easy to misread. There are actually several state machines, and each I think is
fairly simple, so writing out a list of states, events and state transitions
may be practicable.
> 5) _IP addressability not present on adjacent infrastructure link_ (AIL)
> When the Stub router finds no IPv6 on the "LAN" link, then it advertises
> one. I think that this prefix should be advertised as being _off-link_.
If it’s advertised as off-link, will hosts use it on-link as a source address
for communications? That’s the point of advertising this prefix. We advertise a
route to the stub network’s prefix, but we need a prefix on the adjacent
infrastructure link in order for IPv6 communication to happen.
> To clarify for others: the stub router will have a ULA, and it might
> advertise ULA:0002::/64 on the AIL ("LAN"), and will number it's stub
> network with ULA:0001::/64. It will do this with a PIO that does not
> include a default route.
To be clear, it will advertise an RA that has a router lifetime of zero, which
indicates “not a default router.” The on-link prefixes on the stub network and
the infrastructure network are advertised using PIOs. Reachability from the
stub network to the infrastructure network and vice versa are advertised using
Route Information Options (RIOs).
> On the AIL, where there is also an IPv6 prefix (but not DHCPv6-PD),
> then it just seems like not putting a second ULA on top of the LAN
> for the purpose of communicating within the LAN seems better.
> While the off-link prefix can be used for e2e communications on the
> LAN, I think that the on-link prefix will be preferred.
If there’s already an on-link prefix on the AIL, the stub router doesn’t
advertise an additional prefix—there’d be no point to this. This adds some
complexity to the stub router implementation, but I think makes its presence on
the network a bit less heavy. Particularly if you have multiple stub routers
(e.g., a HomePod Mini stereo pair in several rooms in the house).
> Perhaps this messes with DNS-SD discovery.
That’s not the issue, although we do have to be careful not to propagate
addresses that won’t be reachable from off-link.
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
