RE: VRRPv3 and Timer Enhancements Drafts - advertisement format

Hi, 
Pls see "> SJN " inline.
Thanks,
-Steve  

-----Original Message-----
From: Hott, Robert W CIV B35-Branch [mailto:[email protected]] 
Sent: Thursday, July 27, 2006 9:59 AM
To: Stephen Nadas (RL/TNT); [email protected]
Subject: RE: [VRRP] 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).

>SJN I agree w/you.

	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.

> SJN I think it can work either way.  
> SJN AdvCnt*AdverInt is one way to set FailOverTime; I see no reason
not
> SJN to just send it directly.  So I'm ok w/either approach.  

	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.

> SJN (oops, I should have looked at the ID tracker on ipv6-spec-07...) 
> SJN Since ...ipv6-spec-07 is in the process, to me this means, 
> SJN practically, it maybe simpler to advance fast timers separately.

> SJN (and the alignment could be handled as needed with new message 
> SJN types) 

	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.

> SJN so, let's reset then. maybe microseconds is really overkill.  
> SJN 16 bits (in fact, 14) can handle 10E-4 sec (tenth of microsec).  
> SJN Will we really need a failover time smaller than 1/10000 sec? 
> SJN Today fast failover for us is e.g. 150 millisec (so this coding 
> SJN would provide for 3 orders of magnitude smaller failover times) 
> SJN if this is okay, AIG can stay 2 bits, the currently unused 
> SJN setting can mean 1/10000, and 14 bits carry failovertime.  Don't 
> SJN need extra 32 bits: 
> SJN             
> SJN    0                   1                   2                   3
> SJN    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
> SJN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> SJN    |Version| Type  | Virtual Rtr ID|   Priority    | Count IP
Addrs|
> SJN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> SJN    |AIG|         Adver Int         |          Checksum
|
> SJN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> SJN    |       IPv4 Address (1) or start of IPv6 Address(1)
|
> SJN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> SJN    |                            .
|
> SJN    |                            .
|
> SJN    |                            .
|
> SJN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> SJN    |       IPv4 Address (n) or end of IPv6 Address (n)
|
> SJN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


	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