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

Hi Don, 

I'm am okay with all of these changes. 

Steve Nadas 

-----Original Message-----
From: Don Provan [mailto:dprovan <at> bivio.net] 
Sent: Thursday, March 29, 2007 7:46 PM
To: Kalyan.Tata <at> nokia.com; Joseph.Fioramonti <at> marconi.com; vrrp <at> ietf.org
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"

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

Hi Don, 

I guess elaborates point 4 of the last email.  I'm okay with this as
well. 

Regards, 
Steve Nadas  

-----Original Message-----
From: Don Provan [mailto:dprovan <at> bivio.net] 
Sent: Friday, March 30, 2007 2:08 PM
To: 'Hott, Robert W CIV NSWCDD, W13'; 'Fioramonti, Joseph';
Kalyan.Tata <at> nokia.com; vrrp <at> ietf.org; 'Fioramonti, Joseph'
Cc: 'Chappell, Brett L CIV NSWCDD, W13'; 'Odonoghue, Karen F CIV NSWCDD,
W13'
Subject: RE: [VRRP] Reviving draft-ietf-vrrp-ipv4-timers-02: timeout
vsinterval

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

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

Hi Bob, 

>From a "futureproofing" point of view, we had some interest in
sub-centisecond.  But centisecond meets our needs and a new packet type
can always be used for sub-centisecond if and when it becomes needed. 

Regards,
Steve Nadas   

-----Original Message-----
From: Hott, Robert W CIV NSWCDD, W13 [mailto:robert.hott <at> navy.mil] 
Sent: Friday, March 30, 2007 12:12 PM
To: Fioramonti, Joseph; Don Provan; Kalyan.Tata <at> nokia.com; vrrp <at> ietf.org
Cc: Chappell, Brett L CIV NSWCDD, W13; Odonoghue,Karen F CIV NSWCDD, W13
Subject: RE: [VRRP] 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

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

Don,

With regard to your observation that the entire spec is written around the
advertisement interval, the calculation of the skew time would need to be
addressed.  Complicating matters (slightly), in the latest VRRPv3 draft
backups accept and apply the masters advertisement interval.  Presumably any
backup would do the same for the timeout value.  This was a change that had
been discussed for VRRPv2 as well.

Steve

-----Original Message-----
From: Don Provan [mailto:dprovan <at> bivio.net] 
Sent: Friday, March 30, 2007 12:08 PM
To: Hott, Robert W CIV NSWCDD, W13; Fioramonti, Joseph;
Kalyan.Tata <at> nokia.com; vrrp <at> ietf.org; Fioramonti, Joseph
Cc: Chappell, Brett L CIV NSWCDD, W13; Odonoghue, Karen F CIV NSWCDD, W13
Subject: RE: [VRRP] Reviving draft-ietf-vrrp-ipv4-timers-02: timeout
vsinterval

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.

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

All,

Two points...

1.  I think that it would be cleaner to add units now, rather than to go to
a new packet-type in the future.  If I receive a packet with units that I
don't understand, I can (complain and) ignore the advertisement, reverting
to ships in the night.

2.  We have two intervals of time (advertisement and expiration), and are
discussing which is more important - I think that they are both important.
The count of lost advertisements is related.  I think that the protocol will
be more general and future-proof if we allow the intervals to be separately
configured:
  - The advertisement interval (with units) is for the use of the master.
  - The timeout interval (with units) is for the use of the backup.
Why don't we configure and advertise both?  We could require that the
timeout interval be greater than the advertisement interval.

Thanks,
--Joe.

-----Original Message-----
From: Stephen Nadas (RL/TNT) [mailto:stephen.nadas <at> ericsson.com] 
Sent: Monday, April 02, 2007 1:24 PM
To: Hott, Robert W CIV NSWCDD, W13; Fioramonti, Joseph; Don Provan;
Kalyan.Tata <at> nokia.com; vrrp <at> ietf.org
Cc: Chappell, Brett L CIV NSWCDD, W13; Odonoghue,Karen F CIV NSWCDD, W13
Subject: RE: [VRRP] Reviving draft-ietf-vrrp-ipv4-timers-02

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

Joe,

1. I don't see any interesting difference between how you will
react to a mismatched unit and how you already react to a packet
type you don't understand. The advantage of depending only on
the packet type is that we don't waste time and effort changing
the protocol to carry a unit. Keep in mind that there's a lot
more to adding a unit field than just defining a few bits in
the header. For one thing, we need to describe how you should
react to a mismatched unit...

2. The question isn't which interval is more important nor which
should be configured: they both are important and both should be
configurable. The question is what functional reason does the
protocol have for carrying the advertisement interval?

Nothing about protocol operation requires that the cooperating
routers agree on the advertisement interval: they only need to
agree on the timeout. So what's the point of carrying the
interval and defining how a peer should react to various
advertisement interval values? Better to simplify the protocol
and not worry about issues that can be left up to the
implementation.

-don

> -----Original Message-----
> From: Fioramonti, Joseph [mailto:Joseph.Fioramonti <at> marconi.com]
> Sent: Tuesday, April 03, 2007 11:22 AM
> To: 'Stephen Nadas (RL/TNT)'; Hott, Robert W CIV NSWCDD, W13;

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

Don,

Please see my responses in-line.

Thanks,
--Joe.

> -----Original Message-----
> From: Don Provan [mailto:dprovan <at> bivio.net]
> Sent: Tuesday, April 03, 2007 3:18 PM
> To: 'Fioramonti, Joseph'; 'Stephen Nadas (RL/TNT)'; 'Hott, Robert W CIV
NSWCDD, W13';
> Kalyan.Tata <at> nokia.com; vrrp <at> ietf.org
> Cc: 'Chappell, Brett L CIV NSWCDD, W13'; 'Odonoghue,Karen F CIV NSWCDD,
W13'
> Subject: RE: [VRRP] Reviving draft-ietf-vrrp-ipv4-timers-02
> 
> Joe,
> 
> 1. I don't see any interesting difference between how you will
> react to a mismatched unit and how you already react to a packet
> type you don't understand. The advantage of depending only on
> the packet type is that we don't waste time and effort changing
> the protocol to carry a unit. Keep in mind that there's a lot
> more to adding a unit field than just defining a few bits in
> the header. For one thing, we need to describe how you should
> react to a mismatched unit...

The reason to add units is not that we need it today (we don't).  Its
because someone might need it in the future.

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

> The reason to add units is not that we need it today (we don't).  Its
> because someone might need it in the future.

If someone needs smaller units or larger units or different units
in the future, we have a plan: they should use a different packet
type for exactly the same reasons we are using a different packet
type.

If, on the other hand, no one ever needs different units in the
future, then we'd be wasting effort implementing them now.

> RFC 2338/3768 and draft-ietf-vrrp-ipv6-spec-08 both say that 
> the purpose for
> sending the advertisement interval is to troubleshoot 
> misconfigured routers.
> I assume that would still be at least a part of the purpose.  
> Do you have
> some other purpose in mind?

The exist protocol versions mistakenly think the advertisement
interval needs to be synchronized, but that's only because the
advertisement interval and the timeout interval are synonymous
for the current protocol's purposes: in essence we were always
checking the timeout interval, but we were doing it by
comparing the value divided by 3. As you yourself pointed out,
the correlation no longer holds because both intervals need
to be independently configurable. When we revisit the
assumptions of the existing protocols now that we realize the
two variables are independent, it's plain that only the timeout
interval needs to be synchronized for correct protocol behavior.

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

> 
> > The reason to add units is not that we need it today (we don't).  Its
> > because someone might need it in the future.
> 
> If someone needs smaller units or larger units or different units
> in the future, we have a plan: they should use a different packet
> type for exactly the same reasons we are using a different packet
> type.
> 
> If, on the other hand, no one ever needs different units in the
> future, then we'd be wasting effort implementing them now.
> 
> > RFC 2338/3768 and draft-ietf-vrrp-ipv6-spec-08 both say that
> > the purpose for
> > sending the advertisement interval is to troubleshoot
> > misconfigured routers.
> > I assume that would still be at least a part of the purpose.
> > Do you have
> > some other purpose in mind?
> 
> The exist protocol versions mistakenly think the advertisement
> interval needs to be synchronized, but that's only because the
> advertisement interval and the timeout interval are synonymous
> for the current protocol's purposes: in essence we were always
> checking the timeout interval, but we were doing it by
> comparing the value divided by 3. As you yourself pointed out,
> the correlation no longer holds because both intervals need
> to be independently configurable. When we revisit the
> assumptions of the existing protocols now that we realize the
> two variables are independent, it's plain that only the timeout

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

> Given that, then do we even need to send the timeout interval?
> Would it be valid to have different timeout periods configured?

I do not think it would be valid, no. I think there are several
ways that mismatched timeouts could lead to problems, exactly
the same problems that led to the existing specification
requiring confirming the Advertisement Interval.

By the way, I've been talking as if there's an existing concept
of "timeout interval", but actually it would be an addition.
Master_Down_Interval would be Timeout_Interval + Skew_Time.
And while Advertisement_Interval would be configurable, as we've
agreed, it would be limited to being no greater than
Timeout_Interval / 3.

-don

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp