Subject: [Iotops] Ted's stub network document: draft-lemon-stub-networks{, -ps}

From: Michael Richardson <[email-masked]>
Date: Fri, 26 Feb 2021 11:24:37 -0500

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 <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Feb 2021 12:01:32 -0500

On Feb 26, 2021, at 11:24 AM, Michael Richardson <[email-masked]> wrote:

Thanks for the comments, Michael!

> although there is some resistance to putting such a specific use case into

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

>   and rechecks needed, and maybe the Stub Router can just watch for

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.

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

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

>   network with ULA:0001::/64.  It will do this with a PIO that does not

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

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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 26 Feb 2021 17:36:48 +0000

Just addressing the administrivia point ...

>    https://datatracker.ietf.org/doc/draft-lemon-stub-networks/00/ 

Ted asked for the Secretariat to fix this and both INT Area ADs have approved getting this fixed. I'll make sure 6man and homenet are notified if this happens.
Barbara

---

From: Ted Lemon <[email-masked]>
Date: Sat, 27 Feb 2021 15:19:12 -0500

Since I’m updating the document...

> On Feb 26, 2021, at 12:01 PM, Ted Lemon <[email-masked]> wrote:
>> 2) There is advice about monitoring the RAs from the infrastructure router

I’ve added this, but please suggest better wording:

	    As an alternative to the vicarious router discovery process described here, the stub router could monitor the presence
	    of the router advertising the on-link prefix in the neighbor cache. If the neighbor cache entry becomes stale, this
	    could be an indication that the prefix is also stale. If the neighbor cache entry goes stale, the router would need to
	    try to refresh it, and if that fails, then the stub router must begin advertising its own on-link prefix on the stub
	    network.

> 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 s…

This is noted, and on the to-do list, but not today. :)