Ted's stub network document: draft-lemon-stub-networks{,-ps}

[Michael Richardson <[e-mail]>]

Ted posted draft-lemon-stub-networks-ps awhile ago, and I have attempted to
collaborate with him on it.  There was a goof in the XML, so when he posted
-01 of the document, it was named draft-lemon-stub-networks, and overwrote
his previously uploaded solution document.

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 Problem Statement is at:
   https://www.ietf.org/archive/id/draft-lemon-stub-networks-01.html

The solution document is at:
   https://datatracker.ietf.org/doc/draft-lemon-stub-networks/00/?include_text=1

Ted shared a (google) document with me to edit, but I'm not sure if he wants
that as the canonical place to contribute.

Here are some of my comments/questions about this document:

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"

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?

3) _Adjacent infrastructure link (AIL)_  that's the home LAN, right?
   Maybe it would clearer if it was just called that?

4) I'd like to add a state machine diagram to 3.1.1/3.1.2.

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_.

   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.
   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.

   Perhaps this messes with DNS-SD discovery.



--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide