RE: Reviving draft-ietf-vrrp-ipv4-timers-02

Don,

I agree with your point #1.

I believe that your points #2 and #3 assume what is stated in your point #4.
Are you proposing that we configure and advertise the master down timeout,
rather than the advertisement interval?  My biggest problem with that is
that it differs from what is done in RFC 3768 and in the IPv6 draft.  I
think that it would be better to work towards aligning them.

Also there was the question of allowing the count of lost advertisements to
be configurable, rather than hard coded at 3.  There was discussion last
summer that any more than 3 were unnecessary.  Did we arrive at consensus?

Thanks,
--Joe.

-----Original Message-----
From: Don Provan [mailto:[email protected]] 
Sent: Thursday, March 29, 2007 7:46 PM
To: [email protected]; [email protected]; [email protected]
Cc: 'Hott, Robert W CIV B35-Branch'
Subject: [VRRP] Reviving draft-ietf-vrrp-ipv4-timers-02

> Please let me know what will be the major changes 
> to draft-ietf-vrrp-ipv4-timers-02
> So I can add them to the MIB.

Well, let's get an idea....

As I look over the draft, I remember why I lost interest
in it: it seems like extreme overkill for such a simple
change. So I'd like to float the following simplifications
and see if the list can agree on them after a year to
think about it:

1. Eliminate the requirement for interaction between slow
and fast VRRP implementations: an implementation that
supports fast timers MUST be configurable to run either
fast or slow, but all members of the VR must run in the
same mode. (I'm thinking the modes would be differentiated
on the wire via the proposed new packet type, so mismatched
routers would ignore (for slow) or complain about (for fast)
the other router's packets, and the VR would fall into VRRP's
standard "ships in the night" failure mode.)

2. Eliminate the requirement to support timeouts less
than 1 centisecond.

3. Eliminate the requirement to support timeouts greater
than 2.55 seconds in fast mode. Longer timeouts can be
supported by running in slow mode.

4. Eliminate the requirement that all VRs clocks tick
at the same rate: only the timeout time should be
carried in the protocol packet; the tick rate (i.e.,
the packet transmission rate) should be a configuration
option local to the implementation. (I don't see any
particular advantages for cooperating routers to use
different tick rates, I just see no reason for the
protocol to enforce a uniform rate.)

As I look back on the most recent e-mail on this from
last summer, it seems as if #4 was actually approaching
a consensus, but the others may be quite contentious.

-don provan



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