Subject: [ipcdn] RE: Thoughts about param set in DOCS-QOS-MIB ?

From: "Bob Himlin" <[email-masked]>
Date: Wed, 26 Jul 2000 12:13:35 -0700

TurboNet also supports this change (number 1 in Minnie's original mail).
I'm copying IPCDN since I know they are going to be discussing this MIB (or
may have already done so) at their Pittsburgh meeting.  When is (was) this
meeting?

Bob Himlin
TurboNet Communications

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Ruby, Lisa (SD-EX)
Sent: Wednesday, July 26, 2000 10:24 AM
To: 'Minnie Lu'; Lucy Pollak
Cc: [email-masked]'
Subject: RE: Thoughts about param set in DOCS-QOS-MIB ?

Minnie and Lucy,

Motorola supports Minnie's proposal to change the index on the
Service Flow Parameter Set Table.

Lisa Ruby
Motorola - Broadband Communications Sector
[email-masked]

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]]
Sent: Tuesday, July 18, 2000 7:13 PM
To: Lucy Pollak
Cc: 'Minnie Lu'; [email-masked]'
Subject: RE: Thoughts about param set in DOCS-QOS-MIB ?

Hi, Lucy,

  Thanks a lot for your response !  Even though the MIB is implemented, if
there is any way to save the lots of CPU and/or MEMORY (maybe disk space),
there would be a sign to save the customers' money due to the device runs
better.   From my personally opinion, I don't think it is too late to make
it
better especially it is in draft 2 only.

  Thanks!
  Minnie

At 12:38 PM 7/6/00 +0200, Lucy Pollak wrote:
>Hi.
>I guess that you proposition good enough but so late. We implemented this
>mib 9 months before and correlated DB architecture is already used in our
>implementation. More then this, Class Name table is not supported by CM.
>
>-----------------------------------------
>Lucy Pollak, Cable Modem Group
>TI Cable Broadband Communications
>E-mail: [email-masked]
>Tel: +972-9-9706458 Fax: +972-9-9706500
>-----------------------------------------
>
>-----Original Message-----
>From: Minnie Lu [mailto:[email-masked]]
>Sent: Saturday, July 01, 2000 1:41 AM
>To: [email-masked]; John V. Harvey; [email-masked];
>Siripunkaw, Pak
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: Thoughts about param set in DOCS-QOS-MIB ?
>
>
>Hi, all,
>
>  I have comments sent to the authors some time ago for the idea to use
>separate tables for param set of service flow and service class in
>DOCS-QOS-MIB.  Here I would like to bring it up for discussion in broad
>audience.  My goal is just like to see DOCS-QOS-MIB better and better.
>
>Currently based on the draft-ietf-ipcdn-qos-mib-02.txt, due to the service
>flow possible quantity in a CMTS, if we use global index for param set of
>service flow, either lots of memory or cpu time are needed for the
>searching/matching which would be an issue when trying to implement them.
>I felt that this is because the param set of service flow (read-only) and
>param set of service class (read-create) are combined together.   Also,
>currently the service class name in docsQosParamSetTable is read-only.  It
>is possible for users to create an entry of service class param set with no
>service class name which is not so good to me.
>
>IF they can be separated.  Here is my thoughts for possible indexing param
>set of service flow to avoid memory or cpu time waste and still try to keep
>them user friendly for SNMP managers. (detail syntax is omitted for easy
>explanation)
>
>1. Service Flow Param Set table can be indexed as
>{ifIndex, docsQosServiceFlowId, docsQosParamSetType}
>which docsQosParamSetType will be defined as
>INTEGER { provisioned (1), admitted(2), active(3)}.
>In this way, it is consistent with the indexing method for other attributes
>of the service flow.  All the objects in this table are read-only.  The
>param set index is still fixed and each param set of each service flow has
>its own entry in the service flow param set table.  Once user has the index
>of the service flow, he/she can easily know the index of the param set of
>each type.  There would be less 3 objects needed in the
>docsQosServiceFlowTable,too.
>
>2. Service Class table, I would suggest to combine the param set of service
>class and docsQosServiceClassTable together as one table (read-create).  It
>could either index by service class name or service class id.   There is
>another thoughts that still keep two tables as now, but change the service
>class name as read-create in the service class param set table and change
>the docsQosServiceClassTable as read-only table without the status object.
>Either thoughts are fine with me.
>
>This is only my personal opinion.  Any comments are welcome !
>
>Thanks for listening  and Happy holidays !
>Minnie Lu
>

_______________________________________________
IPCDN mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/ipcdn