Subject: [Adslmib] vdsl-08 question

From: Bob Ray <[email-masked]>
Date: 28 Apr 2003 14:16:10 -0500

Hi.

I propose that I remove the two objects

    vdslChanBurstProtection
    vdslChanOverhead

from the -08 draft (producing a -09 draft) and move
it ahead in the queue.  Haven't heard any comments or
suggestions in several weeks, so I guess no one really
cares about the two objects (i.e. they are unimportant).

If I don't hear any objections in the next day or so,
I'll get -09 out.

-- 
Bob Ray <[email-masked]>

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

---

From: [email-masked]
Date: Tue, 29 Apr 2003 16:54:00 +0300

Bob,

First we had a comprehensive solution in IETF based on LCS parameters. Then
came NLC (actually they convinced the DSLF) and said it's better to use
generic parameters. This is obviously a better solution once you have the
detailed definitions.

The PROBLEM is that Sabit doesn't receive email from the IETF (as he wrote
on 18-Apr-2003).

Therefore I added Sabit on CC and suggest that:
- Sabit will add himself to the list :-)
- Sabit (or his colleague) will at last find the time to provide the
detailed spec of those two generic parameters.

If nothing happens, we should return to the two "old and good" SCM specific
parameters (for which we already have detailed definitions) and move them
to the main profile table. They can and should be conditionally mandatory
for SCM applications.

Bye,
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:      [email-masked]                                                   
                                               cc:      adslmib mail list <[email-masked]>                                           
                      29/04/03 16:22           Subject: Re: [Adslmib] vdsl-08 question                                                 
                      Please respond                                                                                                   
                      to rray                                                                                                          

On Tue, 2003-04-29 at 01:42, [email-masked] wrote:
[snipped my original email]

Hi Moti.

I asked the list for two sentences (DESCRIPTION for these two objects).
On the assumption SOMEONE/ANYONE would provide them, I removed all
the other LCS objects from the draft.

Since NO ONE has provided the two sentences in the two months since
Felix first asked for them, and three weeks since I first asked for
them, I assumed no one cared whether they were in or not.  Hence,
my post.

As I understand the process, these two sentences are all that is
keeping us from moving these two drafts to the RFC editor queue.
Which is what I want to do.

I did not see the presentation from NLC.  One would think that they
would be happy to provide the DESCRIPTIONs, no?

--
Bob Ray <[email-masked]>

---

From: "Say, Sabit" <[email-masked]>
Date: Tue, 29 Apr 2003 15:25:03 -0700

Bob,

But I did send this email about my agrement to the two objects and provided
some details. If no objections, I can complete the definitions, but I am not
fluent in MIB definitions so somebody who does needs to help me. 

So, you should not remove them. The alternative of putting back the line
code specific parameters is totally unacceptable. The best way is to move
forward, with these two parameters properly defined.

Sabit

-----Original Message-----
From: Bob Ray [mailto:[email-masked]]
Sent: Monday, April 28, 2003 3:16 PM
To: adslmib mail list
Subject: [Adslmib] vdsl-08 question

Hi.

    vdslChanBurstProtection
    vdslChanOverhead

-- 
Bob Ray <[email-masked]>

Subject: RE: dsl2002.298 and SCM LCS MIB
From: "Say, Sabit" <[email-masked]>
To: Flemisch Felix <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, Boll Norbert <[email-masked]>, Forster Josef <[email-masked]>
Date: Sun, 6 Apr 2003 23:13:31 -0700

Felix,
Sorry about not responding to this quickly.
I do not receive email from the ietf? list. Do I need to subscribe to some
email list or perhaps you can forward relevant correspondence, as you did
earlier.

I am glad to hear that not including line code specific parameters in the
basic MIB is still a valid course. 
I also agree that we have missed a couple of generic parameters that specify
the configuration of the interleaver and the RS frame. 

The missed parameters should be needed not only for SCM but MCM as well.

The first parameter should be called "target burst protection" and it
applies only to the Slow channel (Interleaved, if you like) 
I included the qualifier "target" because the selection of linecode specific
intleaver parameters would try to achieve this target, but the result could
end up being lower or higher. 
The parameter applies independently to Upstream and Downstream.
I prefer the unit microseconds, because the values are sub-ms. A reasonable
range would be 0 to 1000 microseconds in 20 microsecond increments. 

The other parameter should be called "Maximum redundancy overhead" and it
applies only to the Fast channel (Not interleaved, if you like). 
I included the qualifier "maximum" because the selection of linecode
specific framing parameters would use no more, but equal to or less than
this percentage, in determining the number of FEC octets. 
The parameter applies independently to Upstream and Downstream. 
The % unit is OK. The reasonable range would be 0 to 50% in 1% increments.

If this is agreed so far, we can provide a detailed description. 

Sabit
NLC

-----Original Message-----
From: Flemisch Felix [mailto:[email-masked]]
Sent: Sunday, March 30, 2003 2:42 PM
To: [email-masked]'
Cc: [email-masked]'
Subject: dsl2002.298 and SCM LCS MIB

Hello Sabit,

Moti Morgenstern wrote on Sunday 02 March 2003 (see msg00178.html):

"For the VDSL, the DSLF decided to extract the line code specific parameters
from the basic MIB only after the members reviewed a contribution from NLC
(dsl2002.298) claiming that SCM specific parameters can be determined
according to other, generic type, parameters. The problem is that the DSLF
discovered only recently that few of those generic parameters are not
present in the MIB so configuring a SCM line is impossible without
additional parameters.
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."

But Moti is not aware of the semantics of the proposed parameters
(see msg00191.html):  "NLC ... to ... provide soon the definitions
for the two alternative parameters they mentioned (i.e.,
overhead-percentage and burst protection)".

Therefore, I would like to ask you, Sabit, to resolve asap these issues
and the following questions and request of mine (see msg00183.html):

Are you proposing to add the parameters vdslChanOverhead (UNITS "%") and
vdslChanBurstProtection (UNITS "ms") to VdslChanEntry, which shall be not
for ifType interleave(124)?  Please provide a formal DESCRIPTION and how
they
are used for SCM lines.  After adding these two parameters, is it then clear
that basic configuration of SCM lines is possible, or might something else
be needed or useful?

If this is the case, and since these extensions are compatible with TR-057
and RFC 2662, I agree to add them to IETF's VDSL MIB and don't see any
reason
why anybody should not agree.

Best regards,

Felix Flemisch
--------------------------------------
SIEMENS AG
Information and Communication Networks
Carrier Products Systems Engineering
Hofmannstr. 51
D-81359 Munich
Tel    +49 89 722 62175
e-Mail [email-masked]
--------------------------------------

---

From: [email-masked]
Date: Wed, 30 Apr 2003 18:09:31 +0300

Bob,

Sorry, but the term "shocked" quite describes what I feel. Thank you Bob
for indicating this possible disaster.

Once again (not for you Bob but for other people):

The idea was that it is possible to remove the LCS CONFIGURATION section
and use other, existing and generic CONFIGURATION parameters for
CONFIGURING SCM links. The problem was that there were two LCS
CONFIGURATION parameters that could not be removed unless we define
alternative generic CONFIGURATION parameters.

The two new parameters should be part of the CONFIGURATION profile and it
should be possible in the profile to assign different values per each
transmission direction (what we call upstream and downstream).  It is also
obvious that the new parameters are persistent as all other profile
details. The only difference between the two new parameters and other
profile parameters is that the two new parameters are used only for SCM
links' CONFIGURATION. That's the only difference.

I don't mind (or even be glad) if, IN ADDITION to those two CONFIGURATION
parameters, the IETF memebers find it appropriate to add read-only
parameters that provide the actual values achieved during synchronization.

Best regards,
Moti Morgenstern

Senior Systems Engineer
ECI Telecoms Ltd.

                      "Bob Ray" <rray@                                                                                                 
                      pesa.com>                To:      "Rajesh Abbi" <[email-masked]>                                        
                                               cc:      "Say, Sabit" <[email-masked]>, <[email-masked]>, "adslmib mail     
                      30/04/03 17:44           list" <[email-masked]>                                                                
                                               Subject: RE: [Adslmib] vdsl-08 question                                                 

Rajesh suggests:

>    - Suggested DESCRIPTION:
>        "This parameter provisions the minimum level of impulse noise
(burst) protection the
>          Interleaver associated with the Interleave (Slow) channel should
maintain.  This
>          parameter is not applicable to the Fast channel (noSuchObject
should be returned)."
<snip>
>        "This parameter provisions the maximum level of Forward Error
Correction (FEC)
>         redundancy releated overhead to be maintained for the Fast
channel.  This parameter
>         is not applicable to the Interleave (Slow) channel (noSuchObject
should be returned)."

Please note that

a) these objects are in the channel table
b) these objects are not persistent
c) these objects are read-only
d) there is no 'provisioning' going on with these objects

If these need to be moved to the profile table, please speak up now!!!!

Bob Ray

---

From: "Say, Sabit" <[email-masked]>
Date: Wed, 30 Apr 2003 09:24:11 -0700

Can I suggest a change?

vdslChanBurstProtection would become:
    - vdslLineConfDownstreamTargetSlowBurstProtection (RW)
    - vdslLineConfUpstreamTargetSlowBurstProtection (RW)

The reason is that you might end up more or less, not necessarily more.

Also the read-only ACTUAL values could be:
	- vdslLineDownstreamSlowBurstProtection (R)
	- vdslLineUpstreamSlowBurstProtection (R)

For completeness:
vdslChanOverhead would become:
    - vdslLineConfDownstreamMaxFastFecOverhead (RW)
    - vdslLineConfUpstreamMaxFastFecOverhead (RW)

and read-only
    - vdslLineownstreamFastFecOverhead (R)
    - vdslLineUpstreamFastFecOverhead (R)

This time, the actual value is always less or equal to configured. 

-----Original Message-----
From: Rajesh Abbi [mailto:[email-masked]]
Sent: Wednesday, April 30, 2003 11:35 AM
To: Bob Ray
Cc: Say, Sabit; [email-masked]; adslmib mail list
Subject: Re: [Adslmib] vdsl-08 question

I guess while looking at the trees we lost track of the "forest" ;-).

These parameters do need to be added to the vdslLineConfProfileTable
with following changes:

vdslChanBurstProtection would become:
    - vdslLineConfDownstreamMinSlowBurstProtection (RW)
    - vdslLineConfUpstreamMinSlowBurstProtection (RW)

vdslChanOverhead would become:
    - vdslLineConfDownstreamMaxFastFecOverhead (RW)
    - vdslLineConfUpstreamMaxFastFecOverhead (RW)

Regards,

Rajesh

---

From: "Say, Sabit" <[email-masked]>
Date: Wed, 30 Apr 2003 08:22:20 -0700

Sorry for my ignorance re: actual MIB definitions.

I totally agree with Moti that these two should be configuration parameters.
I thought they would be somehow (magically) be both read-only and
configurable.
Anyway, it also helps that they are reported. 
And now thinking clearer, the descriptions should be slightly different, one
configuring a max or target, and the other one reading the actual used by
the PMD layer.

Also I have to disagree on the difference and point out that these are
needed NOT ONLY for configuring SCM but also MCM.  

I think now I have to read the whole MIB and suggest more input on these.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, April 30, 2003 11:10 AM
To: Bob Ray
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Adslmib] vdsl-08 question

Bob,

Best regards,
Moti Morgenstern

Senior Systems Engineer
ECI Telecoms Ltd.

                      "Bob Ray" <rray@

                      pesa.com>                To:      "Rajesh Abbi"
<[email-masked]>                                        
                                               cc:      "Say, Sabit"
<[email-masked]>, <[email-masked]>, "adslmib mail     
                      30/04/03 17:44           list" <[email-masked]>

                                               Subject: RE: [Adslmib]
vdsl-08 question                                                 

(burst) protection the
maintain.  This
should be returned)."
<snip>
Correction (FEC)
channel.  This parameter
should be returned)."

Please note that

Bob Ray