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

I could live happily with Don's proposal.

 

--Joe.

 

  _____  

From: Don Provan [mailto:[email protected]] 
Sent: Friday, March 23, 2007 2:55 PM
To: 'Fioramonti, Joseph'; [email protected]; [email protected]
Subject: RE: [VRRP] draft-ietf-vrrp-unified-mib-06 - AdvInterval

 

Personally, I think having a variable unit is going the wrong way. I think
the object should be in centiseconds, and the rest of the issues should just
be dealt with:

 

1. Always round up.

2a. Make the object a 16 or 32 bit number: don't encode any protocol limit
in the MIB object.

2b. Explain in the description that the number will be capped by the
protocol. Personally, I think this can be a general statement without
explicitly saying what the caps are.

3. Suggest that the operational number, after rounding and capping, should
be returned, but allow (via SHOULD) for a legal implementation to return the
exact number set even if the operational number is different. Or vice versa:
it doesn't strike me as particularly important which approach we encourage,
but we should pick one.

 

-don

-----Original Message-----
From: Fioramonti, Joseph [mailto:[email protected]]
Sent: Friday, March 23, 2007 5:46 AM
To: '[email protected]'; [email protected]
Subject: RE: [VRRP] draft-ietf-vrrp-unified-mib-06 - AdvInterval

Steve's suggestion certainly eliminates the question that I raised, and I
could live with it if that was the final consensus.  Maybe I'm thinking too
hard about this, but it does not seem so clean to overload the object like
that.  How do you feel about adding a units object?

 

Thanks,

--Joe.

 


  _____  


From: [email protected] [mailto:[email protected]] 
Sent: Thursday, March 22, 2007 4:25 PM
To: [email protected]; [email protected]
Subject: RE: [VRRP] draft-ietf-vrrp-unified-mib-06 - AdvInterval

 

hi Joe,

 

You can't change the units to seconds, because VRRPv3 uses centiseconds.

 

Thats true, sorry about that.

 

Lets say that in a set operation on a VRRPv2 VR, 50 (centiseconds) is
provided for vrrpOperAdvertisementInterval.  What shall we do with it?

 

Now I see the problem :). I liked steve's suggestion :

 

 

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.

 

 

Thanks

Kalyan

 

 

 


  _____  


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