RE: draft-ietf-vrrp-unified-mib-06 - AdvInterval
"Steve Bates" <[email protected]>
| Newsgroups | gmane.ietf.vrrp |
|---|---|
| Message-ID | <[email protected]> |
Do we need the "units" clause at all or can we provide an "or" condition like we do with the alaVrrp3AssoIpAddr inetAddress? If we do any type of rounding we won't be able to reach the VRRPv2 maximum of 255 seconds. The interpretation of the field and it's maximum value could be determined based on the version. If words to that effect in the description were sufficient that would be my vote. Steve _____ From: Fioramonti, Joseph [mailto:[email protected]] Sent: Thursday, March 22, 2007 8:27 AM 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