Subject: RE: [VRRP] Reviving draft-ietf-vrrp-ipv4-timers-02

From: "Fioramonti, Joseph" <[email-masked]>
Date: Fri, 30 Mar 2007 11:27:31 -0400

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-masked]] 
Sent: Thursday, March 29, 2007 7:46 PM
To: [email-masked]; [email-masked]; [email-masked]
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-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: "Hott, Robert W CIV NSWCDD, W13" <[email-masked]>
Date: Fri, 30 Mar 2007 11:11:35 -0500

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-masked] (E-mail)

-----Original Message-----
From: Fioramonti, Joseph [mailto:[email-masked]] 
Sent: Friday, March 30, 2007 11:28
To: 'Don Provan'; [email-masked]; Fioramonti, Joseph;
[email-masked]
Cc: Hott, Robert W CIV NSWCDD, W13
Subject: RE: [VRRP] Reviving draft-ietf-vrrp-ipv4-timers-02

Don,

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-masked]]
Sent: Thursday, March 29, 2007 7:46 PM
To: [email-masked]; [email-masked]; [email-masked]
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.

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

---

From: "Don Provan" <[email-masked]>
Date: Fri, 30 Mar 2007 11:08:23 -0700

Ah, yes, it's all coming back to me now....

Right, Joe, the significant change I'm supporting is the one
Bob originally floated last year: changing the protocol to
send the timeout time instead of the interval. My claim is
that the timeout is the number required for protocol function.
The original protocol mistakenly sent the interval, and that
forced the 3 retransmission requirement to be hardcoded not
merely in the application, but all the way back in the protocol
spec.

Practical experience (not mine, and I don't remember whether
it was Bob or someone else) revealed that, with very small
timeouts, higher retransmission counts increased stability.
The choice is to encode the retransmission count in the
packet (which is what the -02 spec does), or recognize that
the retransmission cycle time is irrelevant to the protocol
operation and leave it out of the protocol, replacing it with
the timeout.

I propose the latter as a simplification. I agree it is a change
from all previous versions including RFC-3768. And what makes
that worse is, as I recall, the entire spec is written around
the ticker as the core of the protocol behavior, so it might
take some doing to rewrite the change, particularly while
retaining the original mode as the default configuration, even
though the actual change is really minor in terms of how an
implementation works.

On the other hand, draft-ietf-vrrp-ipv6-spec-08 is still
a draft. May I suggest that *it* be changed so the interval
field becomes a timeout field? That would allow it to support
higher retransmission counts as well. (In fact, are there
any other differences between the two protocols, other than
the obvious differences in the addresses? I haven't paid
much attention at all to IPv6, so I don't remember why we're
working on them as independent versions.)

But I just think it's the way to go: the protocol changes by
one field difference between the two packet types, and, if
anything, the new field use is more obvious and easier to
understand in the new mode.

Let me point out that I was the principle antagonist to the
idea that the retransmission count should be configurable.
I opposed the idea because I wasn't convinced that the
complexity added to the protocol was really worth it. With
this change, the protocol isn't effected: the number of
retransmission is a simple configuration parameter the
administrator of each router can set to their tastes. Two
admins of two cooperating routers don't even have to agree
on the rate, as long as they agree on the timeout.

-don