Re: SLAAC renum -- revised algorithm (Fwd: New Version Notification for draft-gont-6man-slaac-renum-04.txt)

[Fernando Gont <[e-mail]>]

On 12/3/20 11:42, Philip Homburg wrote:
> In your letter dated Thu, 12 Mar 2020 11:33:39 -0300 you wrote:
>> Yes, this is noted in the I-D where we say LTA_IVALID_DEFAULT could be
>> 1800 seconds if we wanted to be more conservative.
> 
> Please write drafts that actually work when implemented. 

Please be constructive.


> If you know that
> the values in your draft can causes failures why put them in?

Any values that you put may cause trouble under given circumstances. For 
instance, you could be simply unlucky and have all multicasted RAs that 
are sent to be lots. There's *nothing* that warrants that that's not the 
case.

So, in engineering, we always operate on probability and statistics.



>> 1) Keep "as is", since in order for this to happen, this woudl require:
>>    + that implementations use a non-defualt value for MaxRtrAdvInterval,
>> *and*
> 
> That is specifically allowed
> 
>>    + that they spread PIOs among multiple RA messages, *and*
> 
> Also allowed

There's a recommendation that you SHOULD send all information in the 
smallest possible number of packets. You're supposend to go against 
SHOULDs if you really know what you are doing.


> 
>>    + one of such messages with PIOs get lost
> 
> It is safe to assume that every once in a while a RA gets losts.

It is also allowed for an arbitrarily large number of packets to get lost.



[...]
>> 3) Keep the current default timer, but not that an implementation may
>> want to send a unicast RA to the router when expiration is imminent
>> (this is probably in RFC4861, already)
> 
> Sending unicast RAs is way more complex than my algorithm, so I don't see
> the point.

Could you explain the complexity of sending a unicast RS?

I don't know how you consider the the measuring part of your algorithm 
any more simpler thatn firing a unicast RS.

Besides, your alggorithm does make assumptions about how information in 
RAs is spread, and also about packet loss. Why are you fine with those 
assumptions?

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