Subject: [Adslmib] vdslChanCurrTxRate [Further comments on Ver 04 of IETF VDSL Draft MIB]

From: "Umberto Bonollo" <[email-masked]>
Date: Wed, 16 Oct 2002 17:08:42 +1000

Hi Bob,

Similar to RFC 2662,
we suggest you add the following variable to the end of the
vdslChanTable to record the actual transmit data rate of the fast channel
and
of the interleave channel from the VTU-C side and from the VTU-R side:

         vdslChanCurrTxRate  OBJECT-TYPE
             SYNTAX      Gauge32
             UNITS       "kbps"
             MAX-ACCESS  read-only
             STATUS      current
             DESCRIPTION
                 "Actual transmit data rate on this channel."
         ::= { vdslChanEntry 3 }

The reason for the above is that ifSpeed for ifTypes 124 and 125
can't represent the VTU-R side upstream transmit rate.
ifSpeed can represent the VTU-C side only, which is insufficient.

Bob, can you see any reason why this wasn't done?
I take it that we still need to know what rate per channel was chosen
at start-up between a min and a max rate?

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

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

---

From: "Umberto Bonollo" <[email-masked]>
Date: Thu, 17 Oct 2002 18:44:33 +1000

Hi Bob,

1) I don't think we can use
124 and 125 for VDSL fast and VDSL interleave ifTypes?

2) Aren't these already used in RFC 2662 for ADSL?

3) In RFC 2662, 124 and 125 are used to extend the
ifTable with the adslAtucChanTable and
adslAturChanTable, for example.

4) In VDSL draft MIB Ver 05, we need new numbers (ifTypes) from
IANA (I think) so we know (unambiguously) to extend ifTable with
vdslChanTable, for example.
Hence, we would need numbers for vdslInterleave(x) and
vdslFast(y)

5) I don't think using ifStack is enough as it seems
indirect and error prone. Also in IETF, VDSL and SHDSL
have their own MIBs and are not extension MIBs to
ADSL MIB (RFC 2662).

Umberto Bonollo ([email-masked])
NEC Australia
&
Scott Baillie
NEC Australia