RE: draft-ietf-vrrp-unified-mib-06 - AdvInterval
"Fioramonti, Joseph" <[email protected]>
| Newsgroups | gmane.ietf.vrrp |
|---|---|
| Message-ID | <A1E953027E21E940858E9FD7D2A6480C3A760E@uspitsmsgusr09.win.marconi.com> |
Kalyan, You can't change the units to seconds, because VRRPv3 uses centiseconds. Lets say that in a set operation on a VRRPv2 VR, 50 (centiseconds) is provided for vrrpOperAdvertisementInterval. What shall we do with it? Thanks, --Joe. _____ From: [email protected] [mailto:[email protected]] Sent: Thursday, March 22, 2007 3:05 PM To: [email protected]; [email protected] Subject: RE: [VRRP] draft-ietf-vrrp-unified-mib-06 - AdvInterval Hi Joe, The change was originally made to accommodate sub second timers that was proposed in Timer Enhancements to Reduce Failover Times for the Virtual Router Redundancy Protocol for IPv4 <draft-ietf-vrrp-ipv4-timers-02.txt <http://tools.ietf.org/html/draft-ietf-vrrp-ipv4-timers-02.txt> > It was a mistake to reference to RFC 3768 for this in the unified-MIB. Now that the draft has expired, I can either change the units back to seconds or leave it as cent seconds if some one is going to update the draft. 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? I did not understand what the problem is. If a router implements 3768 and unified MIB, the vrrpOperAdvertisementInterval will return 100/200/300/etc. in centiseconds instead of 1/2/3/etc. seconds. Thanks, Kalyan _____ From: ext Fioramonti, Joseph [mailto:[email protected]] Sent: Thursday, March 22, 2007 7: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