RE: draft-ietf-vrrp-unified-mib-06 - AdvInterval

I strongly recommend that the answers to these questions get documented
in the
DESCRIPTION clause of the OBJECT.
 
Bert


________________________________

	From: Fioramonti, Joseph [mailto:[email protected]] 
	Sent: donderdag 22 maart 2007 15:27
	To: '[email protected]'
	Subject: [VRRP] draft-ietf-vrrp-unified-mib-06 - AdvInterval
	
	

	Folks,

	 

	I have a question about the units intended for the AdvInterval.

	 

	In RFC 2787 we have seconds:

	 vrrpOperAdvertisementInterval OBJECT-TYPE

	     SYNTAX       Integer32 (1..255)

	     UNITS        "seconds"

	     MAX-ACCESS   read-create

	     STATUS       current

	     DESCRIPTION

	         "The time interval, in seconds, between sending

	         advertisement messages. Only the master router sends

	         VRRP advertisements."

	     DEFVAL       { 1 }

	     ::= { vrrpOperEntry 11 }

	 

	The above is deprecated by draft-ietf-vrrp-unified-mib-06, which
has centiseconds:

	       vrrpOperationsAdvInterval OBJECT-TYPE  

	           SYNTAX       TimeInterval (1..4096)  

	           UNITS        "centiseconds"  

	           MAX-ACCESS   read-create  

	           STATUS       current  

	           DESCRIPTION  

	               "The time interval, in centiseconds, between
sending  

	               advertisement messages. Only the master router
sends  

	               VRRP advertisements."  

	           REFERENCE " RFC 3768 section 5.3.7" 

	           DEFVAL       { 100}  

	           ::= { vrrpOperationsEntry 9 }  

	 

	It references RFC 3768 section 5.3.7 which has seconds:

	   The Advertisement interval indicates the time interval (in
seconds)

	   between ADVERTISEMENTS.  The default is 1 second.  This field
is used

	   for troubleshooting misconfigured routers.

	 

	When the device is managed by vrrpOperationsTable rather than by
vrrpOperTable the advertisement interval is given in centiseconds.
However in RFC 3768 the advertisement interval is in seconds.  What is
the intention with respect to the conversion of centiseconds to seconds
for RFC 3768 and IPv4?  Here are my three favorite alternatives:

	1.  Round (or truncate) centiseconds to seconds.  Run a
seconds-based advertisement timer.  (if we round/truncate what do we
report in a get?)

	2.  Actually run a centiseconds-based advertisement timer, but
the advertisement interval carried in ADVERTISEMENTS is rounded up to
the next higher second.  (this would be a nice way to get sub-second
failover for IPv4)

	3.  Reject values of centiseconds not evenly divisible by 100.

	 

	Thanks,

	--Joe.

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