Subject: Re: [forces] AD review issue 2: On LAN speed definition and whetherusing stat counter type

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 21 Dec 2012 16:29:48 +0800

Hi Andrian and others,

On the stat counters, RFC1155 difines couters for MIB by a text description, as:

3.2.3.3.  Counter
   This application-wide type represents a non-negative integer which
   monotonically increases until it reaches a maximum value, when it
   wraps around and starts increasing again from zero.  This memo
   specifies a maximum value of 2^32-1 (4294967295 decimal) for counters.

While YANG model defines some types of counters like: 
       +-----------------------+--------------------------------+
        | YANG type             | Equivalent SMIv2 type (module) |
        +-----------------------+--------------------------------+
        | counter32             | Counter32 (SNMPv2-SMI)         |
        | zero-based-counter32  | ZeroBasedCounter32 (RMON2-MIB) |
        | counter64             | Counter64 (SNMPv2-SMI)         |
        | zero-based-counter64  | ZeroBasedCounter64 (HCNUM-TC)  |

From all these definitions, we can see that all are still based on an integer of 32 or 64.  I just think we might only need a description like RFC1155 to indicate that all components for statistic counters purpose should monotonically increase and wrap till .... But to unlimit implementations, I suggest not limiting couters to 32bits only. I also tend not to define a specific 'counter' element in the ForCES FE model (actually it is insufficient to define a new counter type for stat purpose, rather to let FE model define a counter might be right if we do need such type).

thanks,
Weiming

>>>  >> > Looking at the stats I see they use simple integer types.  Indeed you
>>>  >> > don't have atomic types for counters. But I can't find anywhere in the
>>>  >> > document that talks about what happens when counters wrap or how to
>>>  >> > record a discontinuity.
>>>  >>
>>>  >> Maybe defining a specific atomic counter with full definition on
>>> wrap and
>>>  >other
>>>  >> properties is a very good treatment. Lets follow to discuss. Thanks.
>>>  >
>>>  >Again. Suggest to look at what MIB and YANG modules do for wrapping
>>> counters,
>>>  >fast counters (that need 64 bits), and discontinuities.
>>> 'uint64' is a built-in atomic type in RFC5812.  There are no range
>>> restrictions
>>> and special enumerated values in the statistic information type, so we
>>> havn't defined
>>> a new atomic type.
>>> Indeed there is no place to mention 'counter' in current lfb lib. If we
>>> think this is an
>>> implementation-specific problem, can we omit this definitiion?
>>> Best regards!
>>> Yours,
>>> Chuanhuang
>