Subject: [Adslmib] habeas corpus

From: "Bob Ray" <[email-masked]>
Date: Thu, 27 Feb 2003 11:15:23 -0600

>   ** Propose moving to a separate line-code-specific MIB Group/Sub-tree
>      (similar to what was done for ADSL MIB - RFC 2662)

The following are referenced in RFC 2662:

   [11]  ADSL Forum WT-014, "DMT Line Code Specific MIB", February 1999.
   [12]  ADSL Forum WT-015, "CAP Line Code Specific MIB", February 1999.

Produce the body.

Bob Ray

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

---

From: Rajesh Abbi <[email-masked]>
Date: Thu, 27 Feb 2003 12:00:52 -0500

Hi Greg and All,

I have compared DSL Forum's TR-057 with the current IETF VDSL MIB draft
(draft-ietf-adslmib-vdsl-07.txt) and compiled a list of differences.  The list
is included below along with my proposals for updates to the IETF draft for better
alignment between the two specifications.

Regards,

Rajesh

-----------------------------------------------------------------------------------
 Differences between IETF (draft-ietf-adslmib-vdsl-07.txt) and DSLF (TR-057)
-----------------------------------------------------------------------------------

    - vdslLineTable:
            - vdslLineCoding and vdslLineType are not addressed by DSLF.
              ** Propose to leave in - useful.

    - vdslPhysTable:
            - IETF: has Current Channel Rates only
            - DSLF: has Current Line Rates only
              ** Propose to add Curr Line Rate to vdslPhysTable

    - vdslChanTable:
            - vdslChanCrcBlockLength:  DSLF does not have this.
              ** Propose to leave in - useful.

    - vdslSCMPhysBandTable:
            - TR-057 does not address line-code-specific (LCS) elements.
            ** Propose moving to a separate line-code-specific MIB Group/Sub-tree
               (similar to what was done for ADSL MIB - RFC 2662)

    - vdslLineConfProfileTable:
            - vdslLineConfDownstreamMaxPwr and vdslLineConfUpstreamMaxPwr are
              not addressed by DSLF.
              ** Propose to leave in - useful.

            - Data Rate configuration is different for IETF and DSLF:
                - IETF defines following per direction (Downstream/Upstream):
                    - Configured Line Rate
                    - Max Fast Chn Rate
                    - Min Fast Chn Rate
                    - Max Slow Chn Rate
                    - Min Slow Chn Rate
                  + vdslLineConfRateAdaptationRatio (common)
                - DSLF defines following per direction (Downstream/Upstream):
                    - Max Fast Chn Rate
                    - Min Fast Chn Rate
                    - Max Slow Chn Rate
                    - Min Slow Chn Rate
                    - Rate Selection Mode (Manual / Adapt at Init)
                    - Rate Adaption Ratio
              ** Proposal:
                * There is no need for 'Configured Line Rate' since rate is derived
                  from the sum of Fast and Slow channel rates.  Moreover, specifying
                  both can result in potential conflict.
                  Suggest removing it.
                * DSLF want's explicit configuration of 'Rate Selection Mode'
                  Suggest adding this.
                * 'Rate Adaption Ratio' can be different upstream/downstream.
                  Suggest separating into up/down parameters.

            - Power Backoff configuration is different for IETF and DSLF:
                - IETF only defines xxxPboControl (enabled/disabled) for up/downstream.
                - DSLF defines following for up/downstream:
                    - Power Backoff Mode (Auto/Manual/Disabled)
                    - Manual Power Backoff Level (dB) (in case of Manual mode)
              ** Propose to use the more complete DSLF model.

            - vdslLineConfAdslOccupy:
                - Current IETF uses this to configure if VDSL line can 'occupy' the ADSL
                  spectrum.
                - DSLF does not support this configuration.  Instead it has a parameter to
                  indicate if ADSL is present in the VDSL binder.  This has spectral
                  compatibility impact for ETSI VDSL.  The parameter has three options:
                    - No ADSL Present
                    - ADSL over POTS present
                    - ADSL over ISDN present
              ** These two parameters do different things.  Perhaps we need both.  Folks
                  at DSL Forum were not in favor of having the 'occupy' parameter.  I had
                  proposed combining the two into one by adding two more options to the above
                  "ADSL over POTS present in the loop" and "ADSL over ISDN present in loop".

    o MCM Specific:
            - vdslLineMCMConfProfileTable
            - vdslLineMCMConfProfileTxBandTable
            - vdslLineMCMConfProfileRxBandTable
            - vdslLineMCMConfProfileTxPSDTable
            - vdslLineMCMConfProfileMaxTxPSDTable
            - vdslLineMCMConfProfileMaxRxPSDTable

            - TR-057 does not address line-code-specific (LCS) elements.
            ** There is no need for these MCM specific profiles.  The high-level parameters
               configured in vdslLineConfProfileTable already determine the value of these
               low-level parameters.
               Suggest removing them altogether.  This will greatly simplify the MIB.

    o SCM Specific:
            - vdslLineSCMConfProfileTable
            - vdslLineSCMConfProfileTxBandTable

            - TR-057 does not address line-code-specific (LCS) elements.
            ** Propose moving to a separate line-code-specific MIB Group/Sub-tree
               (similar to what was done for ADSL MIB - RFC 2662)

            - TR-057 supports configuration of Ham Band Masks (standard + custom)
            ** Suggest moving vdslSCMConfProfileTransmitPSDMask and Notch
               parameters to the common vdslLineConfProfileTable since PSD Masks are applicable
               to both MCM/SCM.  Also suggest renaming as follows:
                    - vdslSCMConfProfileTransmitPSDMask     -> vdslLineConfHamBandMask
                    - vdslSCMConfProfileVendorNotch1Start   -> vdlsLineConfCustomNotch1Start
                        ...
                      (Note: The notches are not 'vendor-specific' but region/operator-specific)

    o PM:
            - DSLF has LOLS included - not in IETF.
            ** LOLS were included in ADSL MIB - RFC 2662.  Suggest including for consistency.

            - IETF has "Uncorrected Blocks" DSLF has "Uncorrectable Blocks"
            ** I believe the same thing is implied.  "Uncorrectable" seems to better reflect the
               situation since it excludes corrected-blocks.

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

[email-masked] wrote:

> From: Gavin Young, DSL Forum Technical Committee Chair
> To: Mike Sneed, IETF ADSLMIB Chair
> Subject: Communication regarding VDSL network element management.
>
> The DSL Forum would like to continue to work with the IETF to develop a comprehensive set of management specifications for VDSL.  In this plan, the DSL Forum has documented and approved a set of objects for VDSL management (TR-57) for incorporation into your VDSL Management Internet Draft.
>
> Sincerely,
> Gavin Young
> DSL Forum Technical Chair
>
> Cc:
> Greg Bathrick, DSL Forum to IETF Liaison
> Peter Adams, DSL Forum Ops and Net Mgt WG Co-Chairman
> Greg Bathrick, DSL Forum Ops and Net Mgt WG Co-Chairman
>
> Attachment:
> DSL Forum TR-057 - VDSL Network Element Management
>
>   ----------------------------------------------------------------------------------------------------
>                     Name: TR-057.pdf
>    TR-057.pdf       Type: Portable Document Format (application/pdf)
>                 Encoding: base64
>              Description: TR-057.pdf