Re: [Snac] draft-ietf-snac-simple-01 review comments

[Ted Lemon <[e-mail]>]

I've added this issue to the github tracker in addition to your pull
request—thanks for that!

https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/29

On Thu, May 18, 2023 at 8:06 PM Ted Lemon <[e-mail]> wrote:

> On Thu, May 18, 2023 at 6:54 PM Darren Dukes (ddukes) <ddukes=
> [e-mail]> wrote:
>
>> Hello Ted and Jonathan, I reviewed this draft and found it very readable
>> and clear.
>>
>
> Thanks!
>
>
>> 1 – The term beacon is used in a few places, but I think what you mean is
>> RA. If this is the case then BEACON_INTERVAL may be better defined as
>> RA_INTERVAL, and s/beacon/RA/g may simplify the terminology.  If I’m off
>> course please let me know.
>>
>
> Thanks, this is a good point. That term is coming from my implementation,
> and I can see why it would be confusing.
>
> 2 – Section 5.1.2.4 – doesn’t account for receipt of multiple prefixes, is
>> there a reason for that? It seems to say any prefix received that is not
>> equal to the currently advertised prefix results in STATE-DEPRICATING or
>> changes in the advertising on the stub network.
>>
>
> That's also a really good point. Of course we need to consider each usable
> on-link prefix if more than one shows up in an RA!
>
>
>> 3 – section 5.2.1 discusses stub router restarts.  I assume the two stub
>> routers are connected to the same AIL **and** to the same stub network.  I
>> also assume the remembered prefix time includes remembering the prefix...
>> The text doesn’t state this clearly.
>>
>
> Actually, the two stub routers might not be connected to the same stub
> network, and that should be okay. The point is to stabilize the on-link
> prefix on the AIL if it's provided by a stub router. If stub routers A and
> B are connected to the same AIL, only one will advertise an on-link prefix.
> If that one reboots, the other will remember that that prefix is on-link,
> so it will do the right thing with responses send to hosts on that prefix.
> The goal is to make sure that the router that rebooted _also_ considers
> that prefix on-link, even though it's never seen an RA. I think this
> section needs a bit of work; the clarifications you've requested would be
> part of that, but it was useful to re-think this based on your comments as
> well, because I think I see how to make this work in a relatively clean way.
>
>
>> The WG comments were good, but I would add that the remembered prefix is
>> immediately usable again if it’s a generated ULA, as mentioned in 5.2.2.
>> For any other stored prefix, would we not be better off to just follow the
>> state machine, because we don’t know if we’ve changed infrastructure
>> networks while shut down?
>>
>
> If we are not advertising the prefix on the link, because there's a usable
> prefix on the link, and we get a message from the stub network for an
> address on the remembered prefix, there are the following possibilities
> that I can think of:
>
> 1. The prefix is a DHCP prefix, meaning it's routable and doesn't belong
> to the stub router. In this case, the stub router could try to renew it; if
> that succeeds, it could assume that the prefix is valid on the AIL and
> forward packets to that prefix to the AIL. If that fails, it assumes the
> prefix is only reachable through a router, so it forwards the packet using
> its routing table, and hopes for the best.
> 2. The prefix is a prefix generated by that stub router. In this case, if
> the stub router is on a different AIL, it's immaterial, since the prefix
> isn't routable. So the stub router can assume that that prefix is on-link
> and forward packets for that prefix to the link; if they reach their
> intended destination, great. If not, nothing is lost.
> 3. The prefix is a stub-network-specific prefix. As an example, Thread
> uses the thread XPANID, which is a 48-bit number unique to a Thread network
> and its set of credentials, to generate a ULA prefix for the AIL. This
> means that if there are several stub routers connected to the same AIL and
> the same Thread network, they will all always advertise the same ULA on the
> AIL if there's no usable prefix there. This has a really nice benefit of
> increasing the stability of numbering on the wire in the presence of stub
> router reboots. This prefix isn't routable, so if the stub router gets
> connected to a different AIL, there's not much it can do about it. It's not
> actually clear what to do in this situation, since if there's another stub
> router still connected to the old AIL, we have ambiguous routing to that
> prefix on the stub network. In the case of Thread, we don't consider this a
> serious concern, since thread has similar locality to home networks: if you
> can't reach the home router, you probably can't reach the thread network
> you were connected to before either.
>
>
>> 4 – Section 5.2.3 mentions “cloud services will not be reachable via
>> IPv6”.  How is this relevant to DHCPv6 PD? Is it more accurate to say “any
>> address outside the stub network will not be reachable via IPv6”?
>>
>
> No, IPv6 addresses on the AIL will be reachable. We need a DHCPv6 prefix
> on the stub network to participate in IPv6 routing on non-adjacent links
> northbound of the stub network.
>
>
>> 5 – Section 8. Should you add NAT64 as a service provided by Stub Routers?
>>
>
> Good point.
>
> Thanks for the review! Either Jonathan or I will do an update based on
> these comments (and any further comments that come as part of this
> conversation)!
>
>