Subject: [Adslmib] VDSL Line Type Naming and Configuration

From: Flemisch Felix <[email-masked]>
Date: Sun, 1 Jun 2003 12:28:29 +0200

Hi all,

I wrote

> The announced email on "VDSL Line Type Configuration and
> VDSL Line Extension MIB" will be sent out next Monday.

It turned out to be convenient to split the email in two parts.
Here is the first part on VDSL Line Type Naming and Configuration.

I give a rationale for what I'm proposing in
"draft-ietf-adslmib-vdsl-09a.txt", sent out on 30th May,
and answer the related comments by Randy
(805,808c863,869; 830c893; 2879a3042,3063;
see his email of 31st May)
thereby polishing the text of the previous proposals.

I'm proposing the following:

1. Rename the enums of vdslLineType (within vdslLineEntry) so that
   they refer to the "interleaved" channel instead of refering to
   the "slow" channel (though this is in fact the same channel).

2. Introduce the new parameter "vdslLineConfLineType" within
   vdslLineConfProfileEntry to enable the configuration of
   vdslLineType at start-up time (and only at start-up time).

As to 1.:

a) Channelization capabilities of DSL equipment to provide multiple
   channels with different transmission qualities are of increasing
   importance, and the basic feature to have a fast channel, or an
   interleaved channel, or either, or both[, or none] is only the very
   beginning of those capabilities.  They will increase already with
   ADSL2 and ADSL2+, i.e. the choices for DSL line types will increase
   above the currently offered five options (taken from G.997.1;
   however, the revision of G.997.1 removed the ADSL line type...).

b) Slow and interleaved refer to the same, high-latency channel,
   but "slow" emphasizes the DISADVANTAGE of interleaving that
   it makes the channel slow, while "interleaved" emphasizes the
   ADVANTAGE of interleaving that it provides reliability in the
   presence of impulse noise or other line disturbances.

   So "slow" is a pessimistic point of view while "interleaved"
   is an optimistic point of view.

   Similarly "fast" emphasizes the ADVANTAGE of the fast channel
   that it has low throughput delay though it may include modest
   interleaving depending on the definition of low latency.

c) Whether one replaces "slow" by "interleaved", and "either" by
   "fastOrInterleaved", and "both" by "fastAndInterleaved", is
   - a matter of taste (slow, either, both are more elegant,
     but slow is pessimistic)
   - a matter of backward compatibility with RFC 2662 and RFC 3440
     ("interleaved")
   - a matter of compatibility with VDSL standards ("slow")
   - a matter of compatibility with IANA assignments
     ("interleave(124)" which should be "interleaved(124)",
     however, or could be changed to "slow(124)")

d) If the WG sees no need for replacement one can basically leave it
   to the co-editors whether they want to stick to "slow" or change
   to "interleaved".  In the following I summarize both alternatives
   where in the case of "slow" I have improved the text slightly.

   This answers Randy's comment 805,808c863,869. 

   Note also that in case of "interleaved" there is no reference to
   T1.424-1 (which is T1E1.4/2001-311 and T1E1.4/2000-009R3) since
   the document uses "slow".  This answers Randy's comment 830c893.

The non-fast channel is designated as "slow":
    vdslLineType OBJECT-TYPE
        SYNTAX       INTEGER
            {
            noChannel(1),         -- no channels exist
            fastOnly(2),          -- only fast channel exists
            slowOnly(3),          -- only slow channel exists
            either(4),            -- either fast or slow
                                  -- channels can exist, but
                                  -- only one at any time
            both(5)               -- both the fast and the slow
                                  -- channel exist
            }
        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).

            Note that 'slow' and 'interleaved' refer to the same
            channel."
        REFERENCE    "T1E1.4/2000-009R3"    -- Part 1 [T1E1311]
        ::= { vdslLineEntry 2 }
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

The non-fast channel is designated as "interleaved":
    vdslLineType OBJECT-TYPE
        SYNTAX       INTEGER
            {
            noChannel(1),         -- no channels exist
            fastOnly(2),          -- only fast channel exists
            interleavedOnly(3),   -- only interleaved channel exists
            fastOrInterleaved(4), -- either fast or interleaved
                                  -- channels can exist, but
                                  -- only one at any time
            fastAndInterleaved(5) -- both the fast and the interleaved
                                  -- channel exist
            }
        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).

            Note that 'interleaved' and 'slow' refer to the same
            channel."
        ::= { vdslLineEntry 2 }
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

As to 2.:

a) For VDSL equipment that offers channelization capabilities
   there is clearly a need to configure the VDSL line type at
   start-up time.  However, it is also clear that nevertheless
   vdslLineType should remain read-only to avoid reconfiguration
   during showtime which would have some nasty side effects, e.g.
   on the ifTable (see Bob's email of 28th May).

b) This has been recognized for ADSL and therefore RFC 3440
   includes an extension of adslLineConfProfileEntry by
   adslConfProfileExtEntry which includes the parameter
   adslConfProfileLineType whose syntax is that of adslLineType.
   IMHO it is just an oversight that this parameter became not
   already a part of RFC 2662.

c) I'm proposing to do exactly the same for VDSL.  In the following
   I summarize the proposal using the designation "interleaved" for
   the non-fast channel.  The "slow" alternative would be similar.

   This also answers Randy's comment 2879a3042,3063 since I'm
   stating a default value for the new parameter.

    vdslLineConfLineType OBJECT-TYPE
        SYNTAX       INTEGER
            {
            noChannel(1),         -- no channels exist
            fastOnly(2),          -- only fast channel exists
            interleavedOnly(3),   -- only interleaved channel exists
            fastOrInterleaved(4), -- either fast or interleaved
                                  -- channels can exist, but
                                  -- only one at any time
            fastAndInterleaved(5) -- both the fast and the interleaved
                                  -- channel exist
            }
        MAX-ACCESS   read-create
        STATUS       current
        DESCRIPTION
            "This parameter provisions the type of VDSL physical
            line entity that shall exist, by defining whether and
            how the line shall be channelized, i.e. which channel
            type(s)are supported.  If the line is to be channelized,
            the value will be other than noChannel(1).

            This configuration can be activated only during start-up.
            Afterwards the value of vdslLineType (within vdslLineEntry)
            coincides with the value of vdslLineConfLineType.
            Depending on this value the corresponding entries in the
            ifTable for the interleaved and the fast channel, i.e.
            ifEntry(ifType=124) and ifEntry(ifType=125), are enabled
            or disabled according to the value of their ifOperStatus.

            In the case when no value has been set, the default
            value 'DEFVAL' is noChannel(1)."
        ::= { vdslLineConfProfileEntry 45 }
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

The announced email on "VDSL Line Extension MIB" will be sent out
tomorrow.

A final remark.  There is severe doubt whether HAM is an acronym at all
(see e.g. http://www.hamcity.com/knowledge/whatisham.asp).  I therefore
recommend not to expand it as Randy suggested.

Regards,

Felix Flemisch

Siemens AG
Information and Communication Networks
Carrier Products Systems Engineering
Hofmannstr. 51
D-81359 Munich
Germany
Phone    +49 89 722 62175
Email    [email-masked]
Internet http://www.siemens.com/

-----Original Message-----
From: Flemisch Felix 
Sent: Saturday, May 31, 2003 3:10 PM
To: [email-masked]'
Cc: [email-masked]'
Subject: RE: WG Last Call: draft-ietf-adslmib-vdsl-09.txt

Hi all,

Randy Presuhn wrote

> I did a diff of the -09- and "09a" documents, and have
> a few comments on the proposed changes.

Thanks Randy for so quickly producing diffs and commenting them!
You identified a number of obscurities indeed.
Here are my answers.

...

The announced email on "VDSL Line Type Configuration and
VDSL Line Extension MIB" will be sent out next Monday.

Regards,

Felix

-----Original Message-----
From: Flemisch Felix 
Sent: Friday, May 30, 2003 10:42 PM
To: [email-masked]'
Cc: [email-masked]'; [email-masked]';
[email-masked]'; [email-masked]'
Subject: RE: WG Last Call: draft-ietf-adslmib-vdsl-09.txt

Hi all,

please find attached a plain ASCII text version of the updated
"draft-ietf-adslmib-vdsl-09.txt" that I previously distributed
as a Word document with continuous line numbering where I have
added my comments using change tracking.  I have named this
updated document "draft-ietf-adslmib-vdsl-09a.txt".

...

Best Regards,

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

---

From: Bob Ray <[email-masked]>
Date: 04 Jun 2003 15:16:08 -0500

>    the "slow" channel (though this is in fact the same channel).

Done.
  
>  is an optimistic point of view.

Life is too short to fight marketing guys :)))

>    vdslLineConfProfileEntry to enable the configuration of

Done.  The profile table is a far better place for this.

More to come.

-- 
Bob Ray <[email-masked]>

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 6 Jun 2003 09:52:55 -0700

Hi -

> From: "Flemisch Felix" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Sunday, June 01, 2003 3:28 AM
> Subject: [Adslmib] VDSL Line Type Naming and Configuration
...
>             both(5)               -- both the fast and the slow

If the WG adopts this, the material in "--" comments
should be included in the DESCRIPTION.

...
...

Same comment applies to this definition as well.

...
>             fastAndInterleaved(5) -- both the fast and the interleaved

Same comment applies to this one also.

...
...

If we take this reference as definitive, then it should be written "ham", rather
than "HAM", since the lower-case form is what is used there.

Randy