Subject: RE: [Adslmib] vdsl-08 question

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

If this is all you need:

vdslChanOverhead OBJECT-TYPE
        SYNTAX       Gauge32
        UNITS        "%"
        MAX-ACCESS   read-only
        STATUS       current
        DESCRIPTION
            "Channel overhead applies independently to downstream and
upstream directions, and only to fast channel. It indicates the percentage
of redundant octets to the total FEC block. The range is 0 to 100. In the
case where the ifType is interleave(124), use noSuchObject."
        ::= { vdslChanEntry 4 }

    vdslChanBurstProtection OBJECT-TYPE
        SYNTAX       Gauge32
        UNITS        "0.005 ms"
        MAX-ACCESS   read-only
        STATUS       current
        DESCRIPTION
            "Channel burst protection applies independently to downstream
and upstream, and only to interleave (slow) channel. It indicates the
correctable burst size with the interleaver settings. The range is 0 to
1.275 ms. In the case where the ifType is fast(125), use noSuchObject."
        ::= { vdslChanEntry 5 }

-----Original Message-----
From: Bob Ray [mailto:[email-masked]]
Sent: Tuesday, April 29, 2003 9:22 AM
To: [email-masked]
Cc: adslmib mail list
Subject: Re: [Adslmib] vdsl-08 question

On Tue, 2003-04-29 at 01:42, [email-masked] wrote:
> Hi Bob,
> 
> The main reason all SCM specific parameters were removed from the model is
> because there was an input from NLC to the DSLF (dsl2003.298) showing that
> with the existing generic parameters plus (new) vdslChanBurstProtection
and
> vdslChanOverhead, one can configure a SCM line. So we should choose
between
> including the generic parameters, according to Sabit's mail from 7-Apr-03,
> and the SCM parameters (vdslSCMConfProfileFastCodewordSize and
> vdslSCMConfProfileFastFecSize) according to your mail from 27-Mar-03.
> 
> We cannot leave outside both the original and the alternative parameters,
> because there is no one who claims it is possible to configure a SCM link
> that way.
> 
> Best regards,
> Moti Morgenstern
> 

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]>

_______________________________________________
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: 30 Apr 2003 08:07:03 -0500

That's it!  Thanks.

Bob Ray

-- 
Bob Ray <[email-masked]>

---

From: Rajesh Abbi <[email-masked]>
Date: Wed, 30 Apr 2003 09:48:41 -0400

Hi Sabit,

Thanks for the input.  I have a few suggestions for the definitions provided by you
below.

* vdslChanBurstProtection :
    - Suggest rename to vdslChanMinInterleaveBurstProtection
        Note: It is impractical to specify a specific/exact value.  Also, ITU-T G.997.1
        defines the parameter as "7.3.2.3 Minimum Impulse Noise Protection".
    - Suggest using micro-seconds as units.
    - 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)."

* vdslChanOverhead :
    - Suggest rename to vdslChanMaxFastFecOverhead:
        Note: Once again it is impractical to require exact values for this.
    - The range should be much smaller, 1..50% is more than adequate.  It would be absurd
        to have this 100% ;-).
    - Suggested DESCRIPTION:
        "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)."

Note: No need to indicate that the parameters apply independently in up/downstream directions
since that is implied by the MIB (indexed by vdslPhysSide).

Regards,

Rajesh

---

From: "Bob Ray" <[email-masked]>
Date: Wed, 30 Apr 2003 09:44:43 -0500

>          parameter is not applicable to the Fast channel (noSuchObject
should be returned)."
<snip>
>         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: Rajesh Abbi <[email-masked]>
Date: Wed, 30 Apr 2003 11:35:08 -0400

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: "Bob Ray" <[email-masked]>
Date: Wed, 30 Apr 2003 12:58:00 -0500

Following are the working object declarations.  Let me know if I've
got them right.  Please.

Bob Ray

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

    vdslChanCurrFastFecOverhead  OBJECT-TYPE
        SYNTAX       Gauge32 
        UNITS        "%"
        MAX-ACCESS   read-only
        STATUS       current
        DESCRIPTION
            "Actual Forward Error Correction (FEC) redundancy 
            related overhead for a fast channel.  This parameter
            is not applicable to an interleaved (slow) channel.
            For interleaved channels, noSuchObject should be returned."
        ::= { vdslChanEntry 4 }

    vdslChanCurrSlowBurstProtection OBJECT-TYPE
        SYNTAX       Gauge32 
        UNITS        "microseconds"
        MAX-ACCESS   read-only
        STATUS       current
        DESCRIPTION
            "Actual level of impulse noise (burst) protection 
            for an interleaved (slow) channel.  This parameter is 
            not applicable to fast channels.  For fast channels, 
            noSuchObject should be returned."
        REFERENCE    "ITU-T G.997.1"          -- section 7.3.2.3
        ::= { vdslChanEntry 5 }

    vdslLineConfDownstreamTargetSlowBurstProtection OBJECT-TYPE
        SYNTAX       Unsigned32 (0..1275)
        UNITS        "microseconds"
        MAX-ACCESS   read-create
        STATUS       current
        DESCRIPTION
            "Specifies the target level of impulse noise (burst) 
            protection for an interleaved (slow) channel."
        REFERENCE    "ITU-T G.997.1"          -- section 7.3.2.3
        ::= { vdslLineConfProfileEntry 41 }

    vdslLineConfUpstreamTargetBurstProtection OBJECT-TYPE
        SYNTAX       Unsigned32  (0..1275)
        UNITS        "microseconds"
        MAX-ACCESS   read-create
        STATUS       current
        DESCRIPTION
            "Specifies the target level of impulse noise (burst) 
            protection for an interleaved (slow) channel."
        REFERENCE    "ITU-T G.997.1"          -- section 7.3.2.3
        ::= { vdslLineConfProfileEntry 42 }

    vdslLineConfDownstreamMaxFastFecOverhead OBJECT-TYPE
        SYNTAX       Unsigned32 (0..50)
        UNITS        "%"
        MAX-ACCESS   read-create
        STATUS       current
        DESCRIPTION
            "This parameter provisions the maximum level of Forward
            Error Correction (FEC) redundancy related overhead to
            be maintained for the Fast channel."
        ::= { vdslLineConfProfileEntry 43 }

    vdslLineConfUpstreamMaxFastFecOverhead OBJECT-TYPE
        SYNTAX       Unsigned32 (0..50)
        UNITS        "%"
        MAX-ACCESS   read-create
        STATUS       current
        DESCRIPTION
            "This parameter provisions the maximum level of Forward
            Error Correction (FEC) redundancy related overhead to
            be maintained for the Fast channel."
        ::= { vdslLineConfProfileEntry 44 }

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 30 Apr 2003 11:10:52 -0700

Hi -

> From: "Bob Ray" <[email-masked]>
> To: "Rajesh Abbi" <[email-masked]>
> Cc: "Say, Sabit" <[email-masked]>; <[email-masked]>; "adslmib mail list" <[email-masked]>
> Sent: Wednesday, April 30, 2003 10:58 AM
> Subject: [Adslmib] six objects
...
>     vdslChanCurrFastFecOverhead  OBJECT-TYPE

Given that the units are "%", shouldn't the range be constrained
to 0..100?

...
>             For interleaved channels, noSuchObject should be returned."

For the SNMP toolkits I'm familiar with, this would be a pain to implement.
Given the semantics of the object, I think it would be better to replace this
line with

+             For interleaved channels, a value of zero shall be returned."

...
>     vdslChanCurrSlowBurstProtection OBJECT-TYPE
...
>             noSuchObject should be returned."

Similarly, I think "zero shall be returned" would be better here.

...
>     vdslLineConfDownstreamTargetSlowBurstProtection OBJECT-TYPE

Would a DEFVAL make sense here, or is the intent that this MUST be
supplied for the row to be activated?

...
>     vdslLineConfUpstreamTargetBurstProtection OBJECT-TYPE

Would a DEFVAL make sense here?  Must this be set for the
row to go active?

...
>     vdslLineConfDownstreamMaxFastFecOverhead OBJECT-TYPE

DEFVAL?

...
>     vdslLineConfUpstreamMaxFastFecOverhead OBJECT-TYPE
...

DEFVAL?

Randy

---

From: Rajesh Abbi <[email-masked]>
Date: Wed, 30 Apr 2003 14:20:50 -0400

Bob/Sabit,

I still wonder about the "xxxTargetSlowBurstProtection".  The only reason someone
would set it is to provide a minimum protection level.  If the result is more or less then
it is almost meaningless.  Even the ITU-T G.997.1 parameter (as referenced) is
"Minimum Impulse Protection".

Rest looks good.

Thanks,

Rajesh

---

From: Bob Ray <[email-masked]>
Date: 30 Apr 2003 14:17:02 -0500

Randy asks:

a) Given that the units are "%", shouldn't the range be constrained to
0..100?

It should have SOME constraint.  Ok to use 0..50 per Rajesh's
suggestion?

b) For the SNMP toolkits I'm familiar with, this would be a pain to
implement.  Given the semantics of the object, I think it would be
better to replace this line with
+  For interleaved channels, a value of zero shall be returned."

Ok.

c) Would a DEFVAL make sense here, or is the intent that this MUST be
supplied for the row to be activated?

I've put in DEFVALs of { 0 } for these.  I don't know of a way to
specify two default values - some value in 1..50 (or 1..1275) if 
appropriate and 0 if not.  So, I guess 0 works.  Complaints from the
crowd?

Suitably modified objects below.

Bob Ray 

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

        SYNTAX       Gauge32 (0..50)
            For interleaved channels, a value zero should be returned."
        ::= { vdslChanEntry 4 }

        SYNTAX       Gauge32 (0..1275)
            a value of zero should be returned."

        DEFVAL       { 0 }

        DEFVAL       { 0 }

        DEFVAL       { 0 }

        DEFVAL       { 0 }