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

From: "Fioramonti, Joseph" <[email-masked]>
Date: Tue, 3 Apr 2007 16:39:56 -0400

Don,

Please see my responses in-line.

Thanks,
--Joe.

> -----Original Message-----
> From: Don Provan [mailto:[email-masked]]
> Sent: Tuesday, April 03, 2007 3:18 PM
> To: 'Fioramonti, Joseph'; 'Stephen Nadas (RL/TNT)'; 'Hott, Robert W CIV
NSWCDD, W13';
> [email-masked]; [email-masked]
> 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.

> 
> 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?

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?

> 
> 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:[email-masked]]
> > Sent: Tuesday, April 03, 2007 11:22 AM
> > To: 'Stephen Nadas (RL/TNT)'; Hott, Robert W CIV NSWCDD, W13;
> > Fioramonti, Joseph; Don Provan; [email-masked]; [email-masked]
> > Cc: Chappell, Brett L CIV NSWCDD, W13; Odonoghue,Karen F CIV
> > NSWCDD, W13
> > Subject: RE: [VRRP] 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:[email-masked]]
> > Sent: Monday, April 02, 2007 1:24 PM
> > To: Hott, Robert W CIV NSWCDD, W13; Fioramonti, Joseph; Don Provan;
> > [email-masked]; [email-masked]
> > Cc: Chappell, Brett L CIV NSWCDD, W13; Odonoghue,Karen F CIV
> > NSWCDD, W13
> > Subject: RE: [VRRP] 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:[email-masked]]
> > Sent: Friday, March 30, 2007 12:12 PM
> > To: Fioramonti, Joseph; Don Provan; [email-masked];
> > [email-masked]
> > 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
> > 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 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
> >
> > _______________________________________________
> > vrrp mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/vrrp

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

---

From: "Don Provan" <[email-masked]>
Date: Tue, 3 Apr 2007 14:23:32 -0700

> 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.

> 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.

Two cooperating routers having different advert intervals is
no longer a misconfiguration. It's just an implementation
decision, not a problem that needs troubleshooting.

-don