Re: Review of draft-lemon-stub-networks-00

[Ted Lemon <[e-mail]>]

Thanks for the review, Jonathan! I’ve applied your changes to the document where appropriate (will publish an update when posting re-opens). I’ve also called out some discussion points where I don’t yet know what to add to the text.

> On Feb 26, 2021, at 2:07 PM, Jonathan Hui <jonhui=[e-mail]> wrote:
> 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.

This is an interesting point. I would expect the home router to be providing a ULA in this case, for just this reason. You are also assuming that the stub network device is relying on address stability, which perhaps it shouldn’t be. Just because I got address A during service discovery doesn’t mean that address A is still valid a half hour later. If address A suddenly stops working, that’s probably a signal to refresh the DNS Lookup that returned address A to see if it’s now returning address B. Obviously if this is a constrained device we’d prefer it do as little work as possible, but I think it needs to be able to do this or it’s not a functioning device. So if we make this scenario less likely, is that actually a good outcome?

In principle, I think events of this sort can be expected to be infrequent, and so I’m not convinced that hardening the network is a good approach—hardening the node may produce a more resilient service.

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

Yes, there are a lot of places in the document where [citation needed] applies. I’ve fixed this one.

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

I’ve deleted this fragment—I think it was the beginning thought for the next paragraph, and then got forgotten.

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

This is a good point. I’d worried about this but concluded that it was unlikely and also not deadly, but there’s no harm in accounting for it.

I’ve made two changes to the document to address this. First, I emphasized in the existing text that a prefix only triggers deprecation if it has a non-zero preferred lifetime. Secondly, I’ve added the following text:

	    It is also possible that all routers on the link that are capable of advertising prefixes might be following the same
	    protocol of deprecating their own prefix when a valid prefix shows up. To prevent a situation where all routers
	    deprecate their prefix and wait until there are no valid prefixes being advertised before advertising a prefix, each
	    stub router must detect the situation where, having deprecated its own prefix, all of the other prefixes being
	    advertised on the link have also been deprecated.
	    
	    When this situation occurs, each router on the link MUST compare the valid lifetimes of all the prefixes that have been
	    seen. If the router's own prefix expires last, then that router should immediately resume publishing its prefix as a
	    preferred prefix.

	    If a router observes this situation and its prefix is not the one that expires last, it MUST set a timer for
	    UNDEPRECATE_WAIT seconds, while continuing to observe prefix advertisements on the link. If, when the timer expires, the
	    prefix that expires last has not been re-published as a preferred prefix, then that prefix is marked as 'really
	    deprecated', and no longer considered a candidate for de-deprecation.

	    Using the remaining list of prefixes, the router should then apply the same algorithm. It should continue to apply this
	    algorithm until either its prefix becomes the one to re-publish as preferred, or some other router has re-published its
	    prefix as preferred.

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

We could. I don’t know what the number should be, though.

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

Fixed, thanks!

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

Okay. That’s starting to go in the direction of a routing protocol, though. It might be better to just do that, if that’s what we need. The Babel working group has a pretty nice self-configuring routing protocol for just this sort of situation.

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

Yes, this would be particularly important on a constrained network. I will confess that at present we are not doing this. Can you suggest text? :)

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

Send text? :)

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

Fixed, thanks!

> Section 3.6
> - add reference to Discovery Proxy.

Done.

> 
> Section 4.1
> - "traffix" -> "traffic"

Done.

> Section 4.2
> - "WFfi" -> "WiFi"

Done. I also noticed that I’m using WiFi a lot, and the trademarked term is Wi-Fi, so I corrected all of those cases.

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

Ooh, nice catch—I forgot about that. I’ve added this, which describes what we did:

	When the time comes to deprecate one or more prefixes as a result of a network partition healing, only one prefix should
	remain. If there are any GUA prefixes, and if there is no specific configuration contradicting this, the GUA prefix that is
	numerically lowest should be kept, and all others deprecated. If there are no GUA prefixes, then the ULA prefix that is
	numerically lowest should be kept, and the others deprecated. By using this approach, it is not necessary for the routers to
	coordinate in advance.


> Section 6
> - "effected" -> "affected"

I actually meant “effected,” but maybe I should have said “established?” :)

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

Oops.

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

Hm. I added this:

	  This SRP service can be discovered
	  using DNS-SD, using the _dnssd-srp-tls service type. If the stub network requires UDP-based SRP rather than tls-based SRP,
	  the stub router MUST act as a proxy to deliver SRP updates over the tcp+tls transport.

This probably needs to be fleshed out in this document, or else in another dnssd document.