RE: VRRPv3 and Timer Enhancements Drafts - advertisement format

Steve,
	I agree with your observation that the IPv6 specification could be adjusted to support the type of changes that were suggested in draft-ietf-vrrp-ipv4-timers-02. Steve Bates asked about aligning IPv4 and IPv6 specifications many months ago. As an end user, I see the need for this capability but I am not sure the need for the capability has taken hold within this list. I know that this capability has been added in various ways by several vendors. I would like to see it standardized (for both IPv4 and IPv6).

	draft-ietf-vrrp-ipv4-timers-02 needs to be updated to discuss which timers to use. Steve Bates proposed enhancements for timer granularity and posed the question regarding the need for passing the advertisement count.

	Personally, I like the idea of not passing an advertisement count. I suggested passing a failover time, instead of an advertisement interval. My thought was that implementations could send advertisements as often as they like but if an advertisement was not heard with the failover time, the implementation would assume the master went away.

	The list has been silent regarding draft-ietf-vrrp-ipv4-timers-02 and it looks like raft-ietf-vrrp-ipv6-spec-07 is being evaluated for "proposed standard". I do think that IPv4 and IPv6 could be aligned but I am not sure if there is a desire to do so and if the ideas for subsecond timers (discussed on the list and in the draft) are widely accepted.

	With regard to your recommendations for aligning IPv4 and IPv6, if we were to proceed with passing the granularity, count, and interval, I might suggest co-locating the reserved areas. I wonder if 16 bits would be enough for the Advertisement Interval. Especially if you are going to add more bits to the granularity.

	If you moved away from transmitting the advertisement count, then granularity and failover time would only be needed. If you could get rid of the first reserved bits, then you would not have to add the extra 32 bits.

	I think your suggestion of bringing the two in sync is a good suggestion. I am just not sure if there is a general desire to standardize the feature.

Bob Hott

Robert (Bob) W. Hott
NSWC-DD
Code B35, Bldg. 1500A/122A
17320 Dahlgren Road
Dahlgren, VA 22448-5100
540-653-1497 (W)
540-653-8673 (FAX)
[email protected] (E-mail)


> -----Original Message-----
> From: Stephen Nadas (RL/TNT) [mailto:[email protected]]
> Sent: Wednesday, July 26, 2006 15:58
> To: [email protected]
> Subject: [VRRP] VRRPv3 and Timer Enhancements Drafts - advertisement
> format 
> 
> 
> Hi, 
> 
> I was reading draft-ietf-vrrp-ipv4-timers-02 as well as 
> draft-ietf-vrrp-ipv6-spec-07.  I have two comments:   
> 
> 1) It seems that the VRRP advertisement format in the IPv6 
> spec could be very similar to the format as proposed in 
> draft-ietf-vrrp-ipv4-timers-02 (except version=3, not 2).  
> 
> The advantages are similar parsing, support of second, 
> centisec, and millisec timers, and adding support for 
> specifying the number of lost packets before declaring 
> failure.  This would also set up the IPv6 spec to also 
> support fast timers (version=3, type = 2) - and if this 
> is the direction it seems that for IPv6 the two drafts 
> could then be merged.    
> 
> 2) Also, there is some discussion on the list about 
> whether a wider AIG field is good in order to support more 
> granular timer units (microsecs was mentioned) - I think 
> for this to be useful a larger advertisement-interval (20 
> bits) is needed as well.  Something like the below seems 
> fairly future proof in terms of fast timers (note AIG 
> is wider by a bit and Adv-Cnt could be wider as well if 
> that is desirable). 
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |Version| Type  | Virtual Rtr ID|   Priority    | Count IP Addrs|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  (rvsd) |Adv Cnt| AIG |               Adver Int               |  
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |        (rvsd)                 |          Checksum             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |       IPv4 Address (1) or start of IPv6 Address(1)            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                            .                                  |
>    |                            .                                  |
>    |                            .                                  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |       IPv4 Address (n) or end of IPv6 Address (n)             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Comments please.
> 
> Regards,
> Steve    
> 
> Stephen Nadas                           Ericsson IPI       
> [email protected]              920 Main Campus Dr. 
> Voice:  +1-919-472-9935 Fax: x/9999     Suite 500 
> Mobile: +1-919-522-0991 ECN: 802 29935  Raleigh, NC 27606
> 
> 
> _______________________________________________
> vrrp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/vrrp
> 

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