Subject: Re: RFC2493 update

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

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

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

---

From: Orly Nicklass <[email-masked]>
Date: Wed, 10 Oct 2001 18:44:12 +0200

Kaj and Ray,

In the list of open issues for 2493/4 there was the following request:

"

5.2. Request for uniformity:

>"Also, at this time, I'm not keeping all 96 15-min statistics

>intervals...I wish that all RFC MIBs would define keeping the interval

>stats in the same way. They all are philosophically trying to achieve

>the same thing, but each standard (RFC2495/2496, RFC2662 (ADSL), ATMF

>IMA MIB, etc.) seems to have some particular idiosyncrasies that keep a

>MIB developer up late at night..."

After reviewing those MIBs and of hdsl2/g.shdsl mib, it look likes each has
its own way of handling the intervals, current count, validity support,
threshold, timing (15min, 1 day), total, 24 hours, far end counters, etc.
They have overlap of concept but not in all details. I was trying to see if
there is away to make something common out of all those without breaking
current implementation, and it is not simple. To get them all to the same
level, it can be done just in additive way as Kaj mentioned but that is
going to add more on storage and on processing. So the question  is, where
do we want to get with it. If we get changes in 2493/4 but not in any of the
others, or if we do not agree on one common way, there is no point to start
all those changes, maybe not even at the TC level.

Orly
-----------------------
Orly Nicklass, Ph.D
Associate VP, R&D
RAD Data Communications, Ltd.

[email-masked]

-----Original Message-----
From: Kaj Tesink [mailto:[email-masked]]
Sent: Wednesday, October 10, 2001 6:14 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: RFC2493 update

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

Kaj Tesink <[email-masked]> 

10/10/2001 09:28 AM 
        
        To:        [email-masked] 
        cc:        [email-masked] 
        Subject:        Re: RFC2493 update 

Hi. 

to solicit input. can you let me know what exact updates on 2493 you're
looking 

kaj 

Regards, 
Bob Ray 
Verilink Corporation 

Kaj Tesink 
Telcordia Technologies 

Kaj Tesink
Telcordia Technologies

---

From: [email-masked]
Date: Wed, 10 Oct 2001 11:51:05 -0500

>needed syntax better.

I agree with this statement completely.  Perhaps the CounterBasedGauge64
of rfc2856?

> 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. 

A suggestion:

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

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

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

The descriptions would have to have snmpv1 references removed as they
would no longer apply (no counter64 or derived objects in v1).

there
>with the same needs and suggestions.

No problem here, but I'm not subscribed to that list.  I've copied the 
list in any case.

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

Ok.

Bob Ray
Verilink Corporation

---

From: [email-masked]
Date: Thu, 11 Oct 2001 13:05:56 -0500

>lets go

I should have one ready for first examination in about two hours...
I'll send it to you guys to look over and amend as you see fit.

Bob Ray
Verilink Corporation