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