Subject: Re: [Adslmib] Suggested Corrections to Performance Parameters: [Comments on Ver 06 draft VDSL-LINE-MIB]

From: [email-masked]
Date: Wed, 6 Nov 2002 10:28:51 +0200

Hi Umberto,

You're absolutely right regarding to use of 64 bits counters only where
they are really required.

The LOL alarm is not a standard VDSL failure. It is even not a standard
ADSL alarm. The only reason it is left in RFC 2662 is because of backward
compatibility to the original ADSL management model developed at DSL Forum
long before ITU-T published G.997. So, the DSL Forum Operations and Network
Management Working Group decided to leave LOL inside the ADSL Line MIB,
though we could decide to remove it and stay with only the standard
failures and PM counters.

Now, even if leaving the LOL failure in the VDSL MIB is somewhat confusing
(i.e., you don't expect a MIB to invent failures. Do you?) I don't say we
should remove it, because there are VDSL applications that use it. After
all, indicating a LOL failure is still only a single bit in a status
object. So, the status object will be supported by everybody and part of
the applications will also use the LOL bit. We can live with it.

However, when it comes to LOL failure counters then, if anyone insists for
some reason on adding them, he:
- Should not make them mandatory objects. It means they cannot appear in
the vdslGroup with all other counters.
- Should not use "T1E1.4/2000-009R3" or any other VDSL standard as a
reference.

Best reagrds,
Moti Morgenstern

Senior System Engineer
Inovia Telecoms Ltd.
Member of the ECI Telecom group
30 Hasivim St.
Petach Tikva, Israel 49133
Tel.: +972-3-9266258 Fax: +972-3-9268182
e-mail: [email-masked]

                      "Umberto                                                                                                         
                      Bonollo"                 To:      "'Bob Ray'" <[email-masked]>, <[email-masked]>                                
                      <umberto@                cc:                                                                                     
                      nstc.nec.com.au>         Subject: [Adslmib] Suggested Corrections to Performance Parameters: [Comments on Ver 06 
                      Sent by:                 draft VDSL-LINE-MIB]                                                                    
                      adslmib-admin@                                                                                                   
                      ietf.org                                                                                                         

                      06/11/02 09:43                                                                                                   

Hi Bob and Rajesh,

Some comments/suggestions on Ver 06 performance parameters:

1. The following are all in the 0..900 seconds range
within a 15 min interval:
vdslPerfCurr15MinLofs              HCPerfCurrentCount,
vdslPerfCurr15MinLoss              HCPerfCurrentCount,
vdslPerfCurr15MinLprs              HCPerfCurrentCount,
vdslPerfCurr15MinESs               HCPerfCurrentCount,
vdslPerfCurr15MinSESs              HCPerfCurrentCount,
vdslPerfCurr15MinUASs              HCPerfCurrentCount;

but

HCPerfCurrentCount is Counter64 (0..18446744073709551615).
Q1. Do we really need range 0..18446744073709551615 to hold
0..900 value?

2.
Also, vdslPerfCurr15MinInits is :
"Count of the line initialization attempts during this [15 min!]
interval.  This count includes both successful and
failed attempts."
Q2. Does it need such a large range for this ?
Ans2: Unsigned32 (0..65535) is probably OK.
(Remember also that Counter64's don't translate
to SMIv1, so use them sparingly.)

3. Unlike RFC 2662, the variable:
vdslPerfCurr15MinLols        HCPerfCurrentCount,
is missing in the VDSL-LINE-MIB (i.e. Loss of Link Seconds)
even though the alarm for it (Loss of Link) is defined in
in vdslCurrStatus (which is identical to adslAtucCurrStatus of RFC 2662).

Q3. Shouldn't we add: vdslPerfCurr15MinLols?

Regards,
Umberto Bonollo ([email-masked])
NEC Australia
&
Andrew Cheers
NEC Australia

_______________________________________________
Adslmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

_______________________________________________
Adslmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

---

From: "Bob Ray" <[email-masked]>
Date: Tue, 12 Nov 2002 16:59:45 -0600

>they are really required.

I'm not wedded to the use of the 64-bit counters.  The reason I didn't use
the 32-bit variants of the performance counters (RFC2493), is simply that
I didn't want to include both.  I thought that it would be cleaner if we
used
just one or the other.  When I cobbed up the HC-TC MIB, there were still
some questions regarding the semantics of the textual conventions in
RFC2493 (for example, what constitutes an valid count in an invalid
interval?).
By not using RFC2493, I was intentionally leaving myself a method to
introduce
changes and/or clarifications in the future.

--- murky personal opinion follows

Personally, I never thought the choice of MIB representation of an integer
as being 32 bit or 64 bit made any difference in an agent (for those objects
that can be fully represented in 32 bits) unless they ALL can be represented
in 32 bits.  That is, once you've committed to SNMPv2, there is no going
back.
Having ONE Counter64 precludes SNMPv1 compatibility.  On the wire, the BER
encodes them the same way (except for the type flag).  Internally, one could
store them in 32 bits (or 16 or 8) and just set the type to Counter64 when a
64 bit object is encoded for transmission.

--- end murky personal opinion

That said, perhaps the following could/should be converted to Unsigned32 or
the RFC2493 equivalents as appropriate:

	vdslPerfLofs                       Counter64
	vdslPerfLoss                       Counter64
	vdslPerfLprs                       Counter64
	vdslPerfESs                        Counter64
	vdslPerfSESs                       Counter64
	vdslPerfUASs                       Counter64
	vdslPerfInits                      Counter64
	vdslPerfCurr15MinTimeElapsed       HCPerfTimeElapsed
	vdslPerfCurr15MinLofs              HCPerfCurrentCount
	vdslPerfCurr15MinLoss              HCPerfCurrentCount
	vdslPerfCurr15MinLprs              HCPerfCurrentCount
	vdslPerfCurr15MinESs               HCPerfCurrentCount
	vdslPerfCurr15MinSESs              HCPerfCurrentCount
	vdslPerfCurr15MinUASs              HCPerfCurrentCount
	vdslPerfCurr15MinInits             HCPerfCurrentCount
	vdslPerf1DayValidIntervals         HCPerfValidIntervals
	vdslPerf1DayInvalidIntervals       HCPerfInvalidIntervals
	vdslPerfCurr1DayTimeElapsed        HCPerfTimeElapsed
	vdslPerfCurr1DayLofs               Counter64
	vdslPerfCurr1DayLoss               Counter64
	vdslPerfCurr1DayLprs               Counter64
	vdslPerfCurr1DayESs                Counter64
	vdslPerfCurr1DaySESs               Counter64
	vdslPerfCurr1DayUASs               Counter64
	vdslPerfCurr1DayInits              Counter64
	vdslIntervalLofs                   HCPerfIntervalCount
	vdslIntervalLoss                   HCPerfIntervalCount
	vdslIntervalLprs                   HCPerfIntervalCount
	vdslIntervalESs                    HCPerfIntervalCount
	vdslIntervalSESs                   HCPerfIntervalCount
      vdslIntervalUASs                   HCPerfIntervalCount
	vdslIntervalInits                  HCPerfIntervalCount
	vdsl1DayIntervalLofs               Counter64
      vdsl1DayIntervalLoss               Counter64
      vdsl1DayIntervalLprs               Counter64
      vdsl1DayIntervalESs                Counter64
      vdsl1DayIntervalSESs               Counter64
      vdsl1DayIntervalUASs               Counter64
      vdsl1DayIntervalInits              Counter64

> - Should not use "T1E1.4/2000-009R3" or any other VDSL standard as a

Huh?  It's not in there - just as a status bit.  Did I miss something
(again)???

Are there any other issues anyone cares to have brought up in
Atlanta next week????????????????

Regards,
Bob Ray