do we need number of retries in VRRP3?
2005-02-01 00:03:29 GMT
Although I’m quite familiar with VRRPv2 but new to VRRPv3 because there is no such demand till recently. We had implemented VRRP like protocol in our product for long time and have added lots of enhancements to the basic protocol. VRRP is a simple protocol working well for a simple network topology, which it is designed for. But it has some significant drawbacks in any production network with some level of complexity.
After reading the draft <draft-ietf-vrrp-ipv6-spec-07.txt>, I have some questions and post here one by one hoping they can get answered.
1) The draft changes the advertisement interval from unit of second in VRRPv2 to centi-second. This is great improvement. Thanks for the change. One of the big operation issues with VRRPv2 is the minimum 3 seconds fail-over time while our customers are asking sub-second failover. But the operational experience tells us that if we shorten the interval (say 200ms), we may want to increase the number of retries (say from 3 to 4 or even 5) to compensate the potential delay or loss. So the fixed retry of 3 times (as defined in master_down_time) sometimes may not be good. Is it possible to use the 4-bit rsvd field to carry this info?
2) In section 6.4.3 it states the master- MUST respond to ND Router Solicitation message for the virtualBut in section 6.4.2 it does not state the backup- MUST NOT respond to ND Router Solicitation message for the virtual Has the author left that out for any good reason? Otherwise, developers may get confused because everything else is kind of opposite in the two sections. 3) In section 7.4 for the interface ID, there is one restriction about using the virtual MAC to derive the interface ID. But it dose not state the reason. I was thinking exactly to derive the interface ID from the VMAC. This is to leave the interface ID derived in the normal manner for addresses of local management. What is the harm of this approach? Thanks in advance.
_______________________________________________ vrrp mailing list vrrp <at> ietf.org https://www1.ietf.org/mailman/listinfo/vrrp