Subject: [Adslmib] thoughts on the next vdsl mib draft

From: "Bob Ray" <[email-masked]>
Date: 25 Jun 2002 13:53:16 -0000

Hi.  

I've been pondering the latest draft and wonder what you guys think
of the following list of possible changes to the -03 draft of the
VDSL MIB and the -01 draft of the HC-TC MIB.

--------------------------------------------------------------------

1.  REFERENCE clauses in object definitions need improving to reflect
multiple standards.  Earlier versions referenced only T1E1, but
with ITU and ETSI documents now referenced, need improvements here.
Some of the new objects (added with latest revision) do not have
REFERENCE clauses at all.  

2.  UNITS clauses need to be cleaned up a bit.  For example, some say
"dB", while others say "dBm", some say "milli-seconds" while others
say "ms", some say "byte", others say "octets", etc.  

3.  Consider adding additional TEXTUAL-CONVENTIONs to HC-TC MIB to define 
   15 minute time elaped
   15 minute valid intervals
   15 minute invalid intervals
    1 day time elapsed   (xxx1DayIntervalMoniSecs)
    1 day valid intervals
    1 day invalid intervals

4.  Consider adding additional TEXTUAL-CONVENTIONs to VDSL MIB to
define band number, band start and band stop for the band entry tables.

5.  Possible additional text describing the nature of the band tables
and profiles.  I added some with the -03 draft but it may need more.
As it stands, I think only 3 or 4 people can follow my twisted 
definitions.  If this helped with job security, I'd probably leave it
alone, but we all know it doesn't  :(((((

--------------------------------------------------------------------

Numbers 2 and 3 are straightforward (that is, I can do it without help).
I would dearly like volunteers for numbers 1, 4, and 5.  

Regards,
Bob Ray

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

---

From: "Bob Ray" <[email-masked]>
Date: 25 Jun 2002 18:26:01 -0000

Faye Ly wrote:

>I will be more than happy to help if you can please point me to the right
>documents.
>
>Also do we really need HC for valid and invalid intervals?
>
>Best,
>
>-faye

a) Thanks!!!!
b) We don't need 64-bit resolution on interval counts, but thought
perhaps we could define textual conventions for them versus the
approach in rfc2493 of defining them via comment.  That is, 

HCPerfValidIntervals ::= TEXTUAL-CONVENTION
        STATUS  current
        DESCRIPTION "blah blah blah"
        SYNTAX Unsigned32(0..96)

HCPerfInvalidIntervals ::= TEXTUAL-CONVENTION
        STATUS  current
        DESCRIPTION "blah blah blah"
        SYNTAX Unsigned32(0..96)

HCPerfMonitorSecs ::= TEXTUAL-CONVENTION
        STATUS  current
        DESCRIPTION "blah blah blah"
        SYNTAX Unsigned32(0..86400)

Hdsl2ShdslPerfIntervalThreshold ::= TEXTUAL-CONVENTION
        STATUS  current
        DESCRIPTION "blah blah blah"
        SYNTAX Unsigned32(0..899)

along with changing the description of HCPerfCurrentCount and
HCPerfIntervalCount such that they would work for fixed intervals
which differ from 15 minutes (i.e. be useful for 20 minute intervals
or 24 hour intervals).

I did sort of the same thing in the HDSL2/SHDSL MIB...

Regards,
Bob Ray

---

From: "Bob Ray" <[email-masked]>
Date: 25 Jun 2002 18:41:42 -0000

Sundar Subramanian writes:

>I have a question regarding the vdslLineType object in the vdsl draft MIB:
>
>The possible values for vdslLineType are enumerated as:
>
>            noChannel(1),         -- no channels exist
>            fastOnly(2),          -- fast channel only
>            slowOnly(3),          -- slow channel only
>            either(4),            -- either fast or slow channel exist
>            both(5)               -- both fast and slow channels exist
>            }
>
>There is no mention of an Interleave Channel. How would I represent my VDSL
>line if I have it channelized as an Interleave ?? 

I think you are right (and I think Moti owes you a beer).  Perhaps we need
a BITS structure instead of an enumeration?  That is,

    vdslLineType OBJECT-TYPE
        SYNTAX       BITS
            {
            vdslTypeFast(0),     -- fast channel
            vdslTypeSlow(1),
            vdslTypeInterleave(2)
            }
        MAX-ACCESS   read-only
        STATUS       current
        DESCRIPTION
            "Defines the type of VDSL physical line
            entity that exists, by defining whether and how
            the line is channelized.  If the line is channelized,
            the value will be other than noChannel(1).  This
            object defines which channel type(s) are supported.

            In the case that the line is channelized, the manager
            can use the ifStackTable to determine the ifIndex for
            the associated channel(s)."
        REFERENCE    "T1E1.4/2000-009R3"    -- Part 1, common spec
        ::= { vdslLineEntry 2 }

Thoughts????

Regards,
Bob Ray

---

From: [email-masked]
Date: Wed, 26 Jun 2002 08:46:55 +0300

Hi,

No beer today.

A VDSL frame can have a fast channel (0-180 octets) and a slow channel
(20-200 octets). 'Slow' is synonym to 'Interleaved' and we use the 'new'
term becuase it is the one being used by the standards.

The enumeration type is correct because it follows the adslLineType object
of rfc2662.

Moti

                      "Bob Ray"                                                                                                        
                      <bob.ray@knology         To:      [email-masked]                                                               
                      .net>                    cc:                                                                                     
                      Sent by:                 Subject: RE: [Adslmib] thoughts on the next vdsl mib draft                              
                      adslmib-admin@ie                                                                                                 
                      tf.org                                                                                                           

                      25/06/02 21:41                                                                                                   

    vdslLineType OBJECT-TYPE
        SYNTAX       BITS
            {

Thoughts????

Regards,
Bob Ray

---

From: [email-masked]
Date: Wed, 26 Jun 2002 09:34:37 +0300

Hi,

Few more comments regarding the latest draft:

1) For vdslCurrSnrMgn object: We changed the units from 0.1dB to 0.25dB and
we also should change the range from -640..640 to -127..127 (-31.7 to
+31.75dB)
2) For vdslCurrAtn object: We changed the units from 0.1dB to 0.25dB and we
also should change the range from 0..630 to 0..255 (0 to +63.75dB)
3) For vdslCurrOutputPwr object: There was no reason to change the units
from 0.1dB to 0.25dB
4) For vdslLineConfTargetSnrMgn object: We changed the units from 0.1dB to
0.25dB and we also should change the range from 0..310 to 0..127 (-31.7 to
+31.75dB)
5) For vdslSCMConfProfileBands object: It is incorrect to add the
'upstreamU0' to the enumeration type. The concept is that each VTU can have
either 'oneBand' or 'twoBands' specified in vdslSCMConfProfileBands. This
configuration refers to D1, U1, D2, and U2 basic bands. In ADDITION, in
case we want to use U0 for either upstream or downstream, then we set
vdslLineConfBandU0Usage object accordingly. In case U0 is employed on
downstream direction then the first downstream band (D1) is simply wider
but the NUMBER of downstream bands remains unchanged. In case we employ U0
for upstream then it is added to the basic upstream bands, thus we have
U0+U1, U0+U2 or U0+U1+U2 combinations.  Bottom Line: Omit the 'upstreamU0'
option only from vdslSCMConfProfileBands and leave it as is elsewhere.

Thanks,
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]