Subject: [VRRP] VRRPv3 and Timer Enhancements Drafts - advertisement format

From: "Stephen Nadas \(RL/TNT\)" <[email-masked]>
Date: Wed, 26 Jul 2006 16:58:29 -0300

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-masked]              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-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: "Hott, Robert W CIV B35-Branch" <[email-masked]>
Date: Thu, 27 Jul 2006 08:58:51 -0500

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-masked] (E-mail)

> -----Original Message-----
> From: Stephen Nadas (RL/TNT) [mailto:[email-masked]]
> Sent: Wednesday, July 26, 2006 15:58
> To: [email-masked]
> Subject: [VRRP] VRRPv3 and Timer Enhancements Drafts - advertisement
> format 
> 
> 
> Hi, 
>

---

From: "Stephen Nadas \(RL/TNT\)" <[email-masked]>
Date: Thu, 27 Jul 2006 11:35:24 -0400

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

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

> 1) It seems that the VRRP advertisement format in the IPv6 spec could 
> be very similar to the format as proposed in
> 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 
> 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