Subject: RE: [Adslmib] Non-Standard Band Plans [Comments on Ver 05 draft VDSL-LINE-MIB]

From: "Umberto Bonollo" <[email-masked]>
Date: Sat, 2 Nov 2002 02:30:34 +1100

Hi Moti,

Thanks for your comments.

1. My example used MCM tables (So I have no comment about SCM).

2. I was concerned that empty TxBand/RxBand tables in the case
of other(4) might not mean anything to the equipment, but
if no "special behaviour" is defined then
each agent will accept empty tables
and then determine what this means
for the VDSL modems on a
per agent basis.

Umberto

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Thursday, 31 October 2002 20:19
To: Umberto Bonollo
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Adslmib] Non-Standard Band Plans [Comments on Ver 05 draft
VDSL-LINE-MIB]

Umberto,

I don't see anything special in a non-standard band plan that requires a
special behavior (except for specifying the "propietary" band plan itself,
which should be out of the scope of the formal MIB).

Moreover, MCM is NOT a precondition for using a non-standard band plan .
Can you explain why "the agent will reject the SET request" when an
operator prefers to use SCM with a non-standard band plan?

best regards,
Moti Morgenstern

Senior System Engineer
Inovia Telecoms Ltd.
Member of the ECI Telecom group
30 Hasivim St.
Petach Tikva, Israel 49133
Tel.: +972-3-9266258 Fax: +972-3-9268182
e-mail: [email-masked]

                      "Umberto
                      Bonollo"                 To:      <[email-masked]>,
<[email-masked]>
                      <umberto@                cc:
                      nstc.nec.com.au>         Subject: [Adslmib]
Non-Standard Band Plans [Comments on Ver 05 draft VDSL-LINE-MIB]
                      Sent by:
                      adslmib-admin@
                      ietf.org

                      31/10/02 09:07

To Bob Ray and Rajesh Abbi:

Hi,

Your comments on the following would be appreciated:

1. To enter a non-standard band plan the manager:

1.1  first has to set vdslLineConfBandPlan = other(4).

1.2 Thereafter, the tables called vdslLineMCMConfProfileTxBandTable
and vdslLineMCMConfProfileRxBandTable *** must *** contain at least
one row entry each.

2. This entails a few things:

2.1 The PDU that sets vdslLineConfBandPlan = other(4) must at the
same time (within the same PDU) create at least one row entry in each of
vdslLineMCMConfProfileTxBandTable and vdslLineMCMConfProfileRxBandTable,
else the agent will reject the SET request.

2.2 Given 2.1 has occurred, at no stage will the agent
allow vdslLineMCMConfProfileTxBandTable or
vdslLineMCMConfProfileRxBandTable
to become empty as this means nothing
with respect to the configuration.

2.3 Hence, now when the manager sets  vdslLineConfBandPlan to something
else
apart from other(4) then at the same time (in the same PDU) the row entries
in vdslLineMCMConfProfileTxBandTable and vdslLineMCMConfProfileRxBandTable
will all be deleted.

3. So the above discussion assumes:

3.1 vdslLineMCMConfProfileTxBandTable and vdslLineMCMConfProfileRxBandTable
can each never be empty when vdslLineConfBandPlan = other(4) .

4. Comments on alternate meanings for non-standard band plans are welcomed
(e.g.):

4.1 Does vdslLineConfBandPlan = other(4) with
vdslLineMCMConfProfileTxBandTable is empty and
vdslLineMCMConfProfileRxBandTable is empty have any meaning for the
equipment?
Ans: No[?]

4.2 Does vdslLineConfBandPlan = other(4) with
vdslLineMCMConfProfileTxBandTable is empty and
vdslLineMCMConfProfileRxBandTable is nonempty have any meaning for the
equipment?
Ans: No[?]

4.3 Does vdslLineConfBandPlan = other(4) with
vdslLineMCMConfProfileTxBandTable is nonempty and
vdslLineMCMConfProfileRxBandTable is empty have any meaning for the
equipment?
Ans: No[?]

Regards,
Umberto Bonollo ([email-masked])
NEC Australia

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

_______________________________________________
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: "Umberto Bonollo" <[email-masked]>
Date: Sat, 2 Nov 2002 02:48:54 +1100

Hi Bob,
Thanks for the feedback.

1. I accept that the agent would provide pre-populated stuff in the profile
index = 1 case (whatever it needs).

2. However, I thought that usually anything to do with profiles would be
created by
the manager; including the TxBand/RxBand Tables.

3. For types 1-3, there doesn't seem any reason to use the TxBand/RxBand
tables as its all fixed (so the TxBand/RxBand tables can be empty).

4. For the other(4) case, non-standard, the tables are used to
define the non-standard band plan.

5. I was concerned about empty tables in the other(4) case,
but Moti's reply makes me think each agent
just handles that somehow itself...

Just our take on it for you to consider.

Umberto

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Bob Ray
Sent: Friday, 1 November 2002 9:34
To: Umberto Bonollo; [email-masked]
Subject: [Adslmib] RE: Non-Standard Band Plans [Comments on Ver 05 draft
VDSL-LINE-MIB]

You've confused me, Umberto!!!!
But, I'll try to wallow through.

>else the agent will reject the SET request.

Let's say one creates a new profile and then sets vdslLineConfBandPlan to
something (1..4).  The agent, upon seeing this action, will generate the
default band table entries for that type based upon its knowledge of the
band plan (vendor-specific 'other' plans included) which one may then
modify via further set operations.

I would expect an agent to prepopulate the profile tables with appropriate
default entries (for the supported standard and vendor-specific band plans)
at initialization.  For example, if the agent is embedded in a rack
containing bandPlanFx(3) modems, the profile tables (band tables, etc.)
would exist by default.

Does that make sense or am I off on Mars again?

Bob Ray