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

Don (and others),
	It is interesting that the work on the MIB was what it would
take to get discussions regarding the sub-second timers for VRRP (for
IPv4) going. As a new participant with the VRRP working group, I felt as
though there was little interest the work that was being proposed for
sub-second timers for IPv4. I know there is a desire from the end-user
perspective (U.S. Navy for one).

	Looking at Don's list of items, I don't have a problem with his
first item (ships in the night). I know I was trying to play both ways
for new implementations but his recommendation would make things easier.
With regard to his second item, I know there was interest voiced for
failover times faster than a centisecond. Some of the discussion
centered around "future-proofing" the failover capability. Item 3 really
depends upon how you will deal with the timers and the granularity.

	Just before things got quite with the draft, the discussion were
heading towards an approach of specifying the failover time and moving
away from the advertisement interval being propagated. The number of
advertisements could be configured locally - but the real issue was the
maximum time before declaring the master down not how many
advertisements that could be missed (3 x advertisement interval). I
personally like this approach but it is definitely a move away from the
IPv6 approach.

	If you are going to have a new packet type, I think the group
should consider specifying the failover time (instead of the
advertisement interval) in the new packet type. I also think specifying
the time granularity (seconds, centiseconds, or milliseconds) should be
considered. The advertisement period would be locally configured
(failover time / 3 could be the default if not configured).

	As an end user, I would certainly like to see this capability in
VRRP for IPv4 and it would certainly be nice if the same capabilities
are present for IPv6.

Bob Hott

ATTN ROBERT W. HOTT
NAVAL SURFACE WARFARE CENTER 
DAHLGREN DIVISION CODE W13
BLDG 1500
17214 AVENUE B SUITE 100
DAHLGREN VA 22448-5147

540-653-1497 (W)
540-653-8673 (FAX)
[email protected] (E-mail)


-----Original Message-----
From: Fioramonti, Joseph [mailto:[email protected]] 
Sent: Friday, March 30, 2007 11:28
To: 'Don Provan'; [email protected]; Fioramonti, Joseph;
[email protected]
Cc: Hott, Robert W CIV NSWCDD, W13
Subject: RE: [VRRP] 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