Subject: Re: [Adslmib] vdsl - ietf and dslf

From: [email-masked]
Date: Thu, 27 Mar 2003 18:19:53 +0200

Bob,

My comments are the following:
   (A minor one) There is no such thing as a DSLF MIB for VDSL but only a
   protocol independent model.
   (More seriously) The DSLF removed the SCM specific configuration tables
   from the model after NLC claimed it's possible to configure SCM links
   based on other (existing) parameters. Meantime, after the WT turned to
   be a TR,  the DSLF realized that the decision was not 100% correct
   because NLC assumed parameters that are not in the model. I suggested
   (2-Mar-2003) to the IETF to fill the gap with two new generic
   parameters, citing the parameters NLC mentioned. Those parameters better
   be inside or the resulted MIB will be suitable for MCM only. You
   probably agree that it is fundamental to have a MIB that allows both
   line codes.

Best regards,
Moti Morgenstern

Senior Systems Engineer
ECI Telecoms Ltd.
Inovia Broadband Access Division
30 Hasivim St.
Petach Tikva, Israel 49133
Tel.: +972-3-9266258
Fax: +972-3-9268182
Cell: +972-55-786258
e-mail: [email-masked]
www.ecitele.com

                      "Bob Ray" <rray@                                                                                                 
                      pesa.com>                To:      "Adslmib" <[email-masked]>                                                   
                      Sent by:                 cc:                                                                                     
                      adslmib-admin@           Subject: [Adslmib] vdsl - ietf and dslf                                                 
                      ietf.org                                                                                                         

                      26/03/03 18:46                                                                                                   

From the DSLF working text, the following is a list of proposed
changes to the VDSL MIB draft.

1.  Add CurrLineRate to vdslPhysTable.
2.  Add vdslPerfLols, vdslPerfCurr15MinLols, vdslPerfCurr15MinLols,
    vdslPerfCurr1DayLols to VdslPerfDataEntry (loss of link seconds).
3.  vdslIntervalLols to VdslPerfIntervalEntry (loss of link seconds).
4.  Add vdsl1DayIntervalLols to Vdsl1DayIntervalEntry (loss of link
seconds).
5.  Change references to UncorrectedBlks to UncorrectableBlocks
    (e.g.  vdslChan1DayIntervalUncorrectBlks to
vdslChan1DayIntervalUncorrectableBlks)
6.  Remove vdslLineConfUpstreamDataRate and vdslLineConfDownstreamDataRate.
7.  Add vdslLineConfUpsteamRateMode and vdslLineConfDownstreamRateMode
    (manual(1), adaptAtInit(2)) to VdslLineConfProfileEntry.
8.  Change vdslLineConfRateAdaptationRatio to vdslLineConfUpstreamRateRatio
    and vdslLineConfDownstreamRateRatio.  That is, separate into up and
    down stream.
9.  Change vdslLineConfUpstreamPboControl and
vdslLineConfDownstreamPboControl
    enumerations to { disabled(1), auto(2), manual(3) }
10.  Add objects vdslLineConfUpstreamPboLevel and
vdslLineConfDownstreamPboLevel
     to vdslLineConfProfileEntry for manual pbo control.
11.  Change

     from:

                         vdslLineConfAdslOccupy OBJECT-TYPE
                     SYNTAX       TruthValue
                     MAX-ACCESS   read-create
                     STATUS       current
                     DESCRIPTION
                         "Indicates if the VDSL line can occupy the ADSL
                         frequency range."
                     ::= { vdslLineConfProfileEntry 26 }

     to:

                         vdslLineConfAdslPresence OBJECT-TYPE
                     SYNTAX       INTEGER
                           {
                              none(1),

adslOverPots(2),
                              adslOverISDN(3)
                           }
                     MAX-ACCESS   read-create
                     STATUS       current
                     DESCRIPTION
                         "Indicates ADSL is present on the VDSL line."
                     ::= { vdslLineConfProfileEntry 26 }

12.  Move PSD Mask and ham band notches to line configuration table.
     That is,  the following

            vdslSCMConfProfileTransmitPSDMask    BITS,
            vdslSCMConfProfileVendorNotch1Start  Unsigned32,
            vdslSCMConfProfileVendorNotch1Stop   Unsigned32,
            vdslSCMConfProfileVendorNotch2Start  Unsigned32,
            vdslSCMConfProfileVendorNotch2Stop   Unsigned32,

     become

            vdslLineConfHamBandMask                                 BITS,
            vdslLineConfCustomNotch1Start        Unsigned32,
            vdslLineConfCustomNotch1Stop         Unsigned32,
            vdslLineConfCustomNotch2Start        Unsigned32,
            vdslLineConfCustomNotch2Stop         Unsigned32,

13.  Completely remove the MCM specific configuration tables.

            - vdslLineMCMConfProfileTable
            - vdslLineMCMConfProfileTxBandTable
            - vdslLineMCMConfProfileRxBandTable
            - vdslLineMCMConfProfileTxPSDTable
            - vdslLineMCMConfProfileMaxTxPSDTable
            - vdslLineMCMConfProfileMaxRxPSDTable

14.  Completely remove the SCM specific configuration tables.

With this set of proposed changes (per Rajesh Abbi), the IETF and DSLF
MIBs should be in harmony.  If the list agrees to these changes AND
agress that the draft is ready to proceed to RFC status once they are
made, I'll do it.

Regards,
Bob Ray
PESA Switching Systems

_______________________________________________
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: Thu, 27 Mar 2003 13:51:58 -0600

>   probably agree that it is fundamental to have a MIB that allows both

To restate, DSLF agrees that the VDSL MIB, with the MCM and SCM specific
tables removed is quite suitable for both MCM and SCM VDSL as long as we
add the two objects you emailed earlier?  That one will be able to configure
both MCM and SCM at that point?  If this is so, I'm ready to go!!!

From earlier mail:

>So, I suggest adding the two generic parameters Overhead (%) and Burst
>Protection (ms) to the MIB, in order to allow determining the Fast Codeword
>Size and FEC Size for SCM links.

Just to clarify, do you mean for me to move (and rename)

        vdslSCMConfProfileFastCodewordSize
        vdslSCMConfProfileFastFecSize

to the vdslLineConfProfileTable?  I suggest augmenting the description
to state that they are intended for SCM links.  For MCM links, they
are to be fixed at 0.

Sure would be nice to have the line code specific aspects covered
in one MIB.  I would hope the MCM groups wouldn't complain too
much about two useless objects...

Is the above correct?  Rajesh?  Others?

Bob Ray
PESA Switching Systems