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

[Ted Lemon <[e-mail]>]

The question of how to manage changes in the stub-router-advertised AIL
prefix turns out to be a real can of worms. As I mentioned in my previous
note, we wound up punting on this for Thread by using the Thread Extended
PAN ID (xpanid) to generate the AIL prefix. Since this is constant for all
BRs that are on the same Thread mesh, it eliminates the need to remember
what was advertised previously.

This would not work for WiFi networks, but possibly we could use the SSID
for this case? Maybe there's not enough randomness in it, but since it only
has to be unique to the AIL, and can't be routed, perhaps that's okay. Is
there any other equivalent thing we could do? I'm highly inclined to just
get rid of the "try to remember old prefixes" text, because our experience
is that this approach failed pretty often, resulting in reachability
problems that took significant time to resolve.

Of course we still have to handle the case where there are two stub
networks on the wire, but the document already handles that. I think the
document should say that even if a particular stub router doesn't actually
publish the AIL prefix, because a usable prefix or a winning stub router
prefix was present, we should always configure it to be on-link. There
could still be edge cases here when there are /three or more/ stub routers
on the same AIL, but I think that's a sufficiently weird that we don't need
to care about it. The whole point of this is to create a stable
configuration, and the simple fact that more than one router is advertising
the same prefix based on its stub network should minimize the number of
times we have an AIL prefix renumbering.


On Mon, Jul 24, 2023 at 8:48 AM Ted Lemon <[e-mail]> wrote:

> On Fri, May 19, 2023 at 7:02 AM Michael Richardson <[e-mail]>
> wrote:
>
>> Darren Dukes \(ddukes\) <ddukes=[e-mail]> wrote:
>>     > 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.
>>
>> Also I just thought as I read this, what if the prefix length on a prefix
>> changes?
>> I am thinking of a situation where a process and/or human inadvertedly
>> advertises the entire /56 that they got from upstream, and then changes
>> their
>> mind, fixes things and advertises only the :0::/64 of it.
>>
>
> This is a good point—thanks for raising it. I will add text. I didn't find
> the text in this section to b exclusive of multiple prefixes, but modified
> it a bit to make it clear that there could be multiple prefixes.
>
> -             The stub router may receive a router advertisement
> containing a usable on-link prefix on the AIL.
> -             If the advertised prefix is different than the prefix the
> stub router is advertising as the on-link usable
> -             prefix, and the Stub Router bit is not set in the prefix
> option for the prefix, the stub router moves the interface to
> +             The stub router may receive a router advertisement
> containing one or more usable on-link prefixes on the AIL.
> +             If any of these prefixes are different than the prefix the
> stub router is advertising as the on-link usable
> +             prefix, and the Stub Router bit is not set in the prefix
> option for that prefix, the stub router moves the interface to
>
>
>>     > 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”?
>>
>> Both are accurate, but the former is more clearly a reminder to IoT
>> device people.
>>
>
> I added this sentence, which I think connects the dots a bit more clearly:
>
>    The OSNR prefix in this case is not known to the infrastructure network
>    routing fabric, so even though packets might be able to be forwarded to
> the intended destination, there would be no
>    return path.
>
>