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

Don,

Please see my responses in-line.

Thanks,
--Joe.

> -----Original Message-----
> From: Don Provan [mailto:[email protected]]
> Sent: Tuesday, April 03, 2007 3:18 PM
> To: 'Fioramonti, Joseph'; 'Stephen Nadas (RL/TNT)'; 'Hott, Robert W CIV
NSWCDD, W13';
> [email protected]; [email protected]
> 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 protected]]
> > Sent: Tuesday, April 03, 2007 11:22 AM
> > To: 'Stephen Nadas (RL/TNT)'; Hott, Robert W CIV NSWCDD, W13;
> > Fioramonti, Joseph; Don Provan; [email protected]; [email protected]
> > 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 protected]]
> > Sent: Monday, April 02, 2007 1:24 PM
> > To: Hott, Robert W CIV NSWCDD, W13; Fioramonti, Joseph; Don Provan;
> > [email protected]; [email protected]
> > 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 protected]]
> > Sent: Friday, March 30, 2007 12:12 PM
> > To: Fioramonti, Joseph; Don Provan; [email protected];
> > [email protected]
> > 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 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
> >
> > _______________________________________________
> > vrrp mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/vrrp

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