Subject: Re: RFC2493 update

From: Kaj Tesink <[email-masked]>
Date: Wed, 10 Oct 2001 12:14:14 -0400

At 10:14 AM 10/10/01 -0500, you wrote:

>In essence, what we desire are to replace gauge32 with counter64.

i thought you would say that.
one issue is that in the very beginning of the trunk mibs (RFC123x)
we went through this issue of counters vs gauges. in fact the early rfcs had
counters and we ended up ripping it all out because gauges reflected the
needed syntax better. i understand your needs though.
replacing these syntaxes now would break current implementations. i'd like
an approach that is more additive instead of replacement.
can we continue to copy this to the atommib list; there may be some folks there
with the same needs and suggestions.

as to the valid/non-valid issue - that was heavily debated
at the time and this is what we ended up with. perhaps the list can comment
on this as well

kaj

>Pretty simple, really.  I would prefer a 2 page draft but I doubt the
>powers that be would allow such... brevity.  <grin>.
>
>I have some arguments with the valid/invalid interval counters,
>perferring instead to just have holes in the tables.  We're using this
>approach in the hdsl2/shdsl draft.  The short argument is that
>having an interval flagged as invalid renders any counts in that
>interval meaningless without far more expansive presentation
>as to why the interval is invalid.
>
>So.. instead of transmitting and storing numbers which are inherently
>meaningless (other than some implied value in saying "this number
>is meaningless"), we just don't transmit them.
>
>In any case, the utility of rfc2493 remains, just that we need more bits!
>
>Bob Ray
>
>"Experience is not what happens to a man; it is what a man does
>with what happens to him."  Aldous Huxley.
>
>
>
>Kaj Tesink <[email-masked]>
>
>10/10/2001 09:28 AM
>
>         To:        [email-masked]
>         cc:        [email-masked]
>         Subject:        Re: RFC2493 update
>
>
>At 08:14 AM 10/10/01 -0500, you wrote:
>
>Hi.
>
>I've included variants of your textual conventions into a draft currently
>working it's way through IESG last call (hdsl2/g.shdsl mib, adslmib
>working group).  A prior product of our working group also used a variant
>of your TCs (rfc2662).
>
>I'm in the process of writing yet-another-draft, this time for vdsl and
>must again produce a variant of your TCs.  This time, I must extend them
>to be 64-bit (Counter64) because of the higher speeds involved.  I would
>certainly prefer writing a general purpose version rather than another
>mib-specific version.
>
>Have you or your working groups produced a similar high speed update
>to RFC2662?  If not, would you mind terribly if I produce one?  Would you
>care to author or co-author the beast?  Time is fairly compressed for
>me right now as I must get the vdsl draft in for Salt Lake City.  That
>would mean another draft for the TCs as well to be done eom.
>Bob,
>
>your request may be very timely, since the atommib wg is in the process
>of moving these specs along on the standards track, including 2493.
>i have not seen high speed specs that use 2493. i copy this to the list
>to solicit input. can you let me know what exact updates on 2493 you're 
>looking
>for? i'll be glad to help.
>
>kaj
>
>ps note that 2493 uses Gauges not Counters
>
>
>
>Regards,
>Bob Ray
>Verilink Corporation
>
>"Experience is not what happens to a man; it is what a man does
>with what happens to him."  Aldous Huxley.
>
>
>
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
>Kaj Tesink
>Telcordia Technologies
>Email  [email-masked]
>Tel    732.758.5254
>Fax    732.758.2269
>Postal 331 Newman Springs Rd
>        Red Bank, NJ 07701
>        USA
>
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
>

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies
Email  [email-masked]
Tel    732.758.5254
Fax    732.758.2269
Postal 331 Newman Springs Rd
        Red Bank, NJ 07701
        USA

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 10 Oct 2001 10:44:14 -0700 (PDT)

On Wed, 10 Oct 2001, Kaj Tesink wrote:

> At 10:14 AM 10/10/01 -0500, [Bob Ray] wrote:
> 
> can we continue to copy this to the atommib list; there may be some folks
> there with the same needs and suggestions.

Some time ago the SMIv2 rules were relaxed (some of us would say broken :)
to allow the equivalent of 64-bit gauges via textual conventions whose
base type is Counter64.  See

2856 Textual Conventions for Additional High Capacity Data Types. A.
     Bierman, K. McCloghrie, R. Presuhn. June 2000. (Format: TXT=20954
     bytes) (Status: PROPOSED STANDARD)

This was intended as a short-term fix for the lack of a real Gauge64 or
Unsigned64 in SMIv2.  Frankly I am not pleased with this "solution" but
it's what the community decided to do.  Based on this precedent, it would
probably be acceptable to define a set of 64-bit TCs analogous to those
in RFC 2493.  Note well that these would have to be new TCs, not
refinements of the ones in RFC 2856, because a TC can't refine a TC.
In particular, the following are illegal:

> HSPerfCurrentCount ::= TEXTUAL-CONVENTION
>            STATUS        current
>            DESCRIPTION   ""   
>            SYNTAX        CounterBasedGauge64
> 
> HSPerfIntervalCount ::= TEXTUAL-CONVENTION
>            STATUS        current
>            DESCRIPTION   ""
>            SYNTAX        CounterBasedGauge64
> 
> HSPerfTotalCount ::= TEXTUAL-CONVENTION
>            STATUS        current
>            DESCRIPTION   ""
>            SYNTAX        CounterBasedGauge64

Let me echo Kaj's admonition that this effort should not be viewed as
a replacement for RFC 2493, but rather should be a new document that
defines a new set of TCs to fill a different need.  MIBs that do not
require 64-bit interval counts can and should continue to use RFC 2493.
Stuff that depends on RFC 2493 has been deployed.  Doing away with it
would needlessly break too many things.

> at the time and this is what we ended up with. perhaps the list can comment

xyzValidIntervals should really have been named xyzMaxIntervalIndex, and
xyzInvalidIntervals should really have been named xyzMissingIntervals.
The former tells you, in effect, how long you've been collecting
interval data.  The latter counts the number of "holes" in the
interval table.

> >is meaningless"), we just don't transmit them.

Actually, leaving holes for intervals for which no data is available
is exactly what implementations the current trunk MIBs are expected 
to do.  As explained above, xyzInvalidIntervals is badly named.  All
it really does is to count the holes.

There is a per-interval flag (not defined in the TCs in RFC 2493,
see e.g.  RFC 2558) to indicate whether the data in the interval
is not invalid in the sense of T1.231-1997 Section 9.1.2.2.  These
have names of the form xyzIntervalValidData.  These flags are cleared
for intervals for which suspect is available.  We put these flags in
because they are required by T1.231.

> >In any case, the utility of rfc2493 remains, just that we need more bits!

I suggest making a new MIB module called HC-PerfHist-TC-MIB with the
64-bit versions of the TCs from RFC 2493.  You don't have to include
any text about xyzValidIntervals and xyzInvalidIntervals -- if you
don't think that they are useful, then leave them out.

Mike