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:[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