Re: Advertisement Interval Vs Timeout

Yeah. It seems like it would be better to advertise "Timeout", and it's 
up to the
advertiser how many advertisements to do per timeout period. But I don't see
that mentioned explicitly, even though the subject of this thread is 
"advertisement
interval vs timeout".

So, if, for instance, you send hellos every second, and therefore people 
time you out
in 3 seconds, you could advertise timeout of 3 seconds, and send as many 
hellos
during that interval as you want, in order to account for lossiness of 
the link.

As Danny said -- the lossiness is an orthogonal aspect of the link, from 
speed.

And as for backward compatibility -- if some people are expecting the 
field to
be "interval between hellos" and others are expecting it to be "time to 
declare me down",
and what is advertised is "time to declare me down", the only bad thing 
that would happen
is that the former listeners will take 3 times as long to declare you down.

Radia


Danny J. Mitzel wrote:
> I'll admit right up front that I haven't been
> following the subsecond timers draft, feel free to
> ignore this question if it's already been discussed.
>
>
> --- Don Provan <[email protected]> wrote:
>   
>> If the master were allowed to send at faster rates,
>> more than three advertisements could be sent per
>> timeout interval, which is what people experimenting
>> with faster timeouts tell us they found was 
>> necessary for stability in that environment.
>>     
>
> I'm not understanding why people experimenting with
> faster timeouts are claiming more Advertisements
> are required to insure VRRP stability?  Stability of
> the protocol as currently written is not dependent on
> the timeout interval it's dependent on the packet loss
> rate (link Bit Error Rate (BER) and/or switch or
> router packet drops).  Are the fast timeout
> experimenters emulating higher BER or non-linerate
> capable switches with high packet drop rates?
>
> I agree that the ability to send Advertisements at a
> higher rate can make VRRP more robust in LANs with
> extremely high BER or congested switches.  I'm just
> trying to understand if there's some claim that this
> is required just because the timeout is scaled down?
>
>
> danny
>
>
>
>
> _______________________________________________
> vrrp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/vrrp
>   


_______________________________________________
vrrp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/vrrp