Re: I-D Action: draft-gont-6man-slaac-renum-02.txt

[Fernando Gont <[e-mail]>]

Hello, Philip.

Thanks for the input! In-line---

On 9/3/20 09:34, Philip Homburg wrote:
>> Yes, this certainly has the potential of decreasing robustness.
>> You have just about 12 hours until the submission deadline for a
>> better proposal!
> 
> Here is a sketch of how the algorithm could be improved.
> 
> My assuption is that the affected home routers send all information in one
> RA, but some other routers split information over an unknown number of
> RAs. The algorithm rapidly expires information in the first case, and
> takes longer in the second case.
> 
> The first part is to detect if all information is sent in one RA. For
> the first n (currently 10) RAs received from a router, check if those RAs
> advertise the same list of prefixes. 

Questions (not objections):

* Is there a rationale for "10"? Or is it mostly "routers couldn't 
reasonably send SLAAC config split into that many RAs"?

* Are these "measurements" something you'd continually perform, or 
something you'd only do on e.g. a link-up event?

* Would a connectivity glitch reset these measurements?

* WHile measuring, do you assume "split RA" or "non-split RA"?



> If this is not the case then set a
> SPLIT_RA to record this fact.
> 
> When an RA arrives and there are prefixes that were previously advertised
> by the current router and are not in the current RA then
> - if SPLIT_RA is set, deprecate the old prefixes if they were last seen at
>    least as long as the router lifetime (if the router is not a default
>    router then do nothing).

When using "deprecate", do you mean:
1) unprefer, or,
2( invalidate

If #1, what would trigger invalidation? A receipt of a similar RA?


> - if SPLIT_RA is not set and the prefix was last seen more than a short
>    while ago (currently one minute) then set the preferred lifetime to
>    a short timeout (current also one minute).

Since this bullet implies that RAs are not split, what would be the 
rationale for "setting the preferred lifetime to a short timeout"?

And, as before: if this simply unprefers the address, what would 
actually invalidate it? Receipt of a similar RA?



> I prefer explicit timeouts over counting packets.

FWIW, counters are simpler. That's why we used them here.


> So far, I have been conservative when it comes to invalidating prefixes
> (I just mark them deprecated). Setting the valid lifetime to the router
> lifetime should be fine. Though I think it is better if higher level
> protocols detect broken connections and take action.

Part of invalidating prefixes is to remove associated routes. If you 
don't, you don't get to talk to new "owners" of the stale prefix.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492