Subject: [Megaco] Goals For The Megaco MIB

From: "Tom-PT Taylor"<[email-masked]>
Date: Wed, 15 May 2002 11:12:57 -0400

I've just been reading draft-ietf-snmpconf-bcp-08.txt, which has good advice
both for MIB design and for implementation.  At one point this document
quotes a number of guidelines for MIB definition and adds a few more points
to the quotation.  I'll repeat these guidelines below, while putting a
question to the list: what goals should the Megaco MIB(s) satisfy?

<quote>

One of the first tasks in defining a MIB module is the creation of a
model that reflects the scope and organization of the management
information an agent will expose.

MIB modules can be thought of as logical models providing one or more
aspects/views of a subsystem.  The objective for all MIB modules should
be to serve one or more operational requirements such as accounting
information collection, configuration of one or more parts of a system,
or fault identification.  However, it is important to include only those
aspects of a subsystem that are proven to be operationally useful.

In 1993, one of most widely deployed MIB modules supporting
configuration was published, RFC 1493, which contained the BRIDGE-MIB.
It defined the criteria used to develop the MIB module as follows:

     To be consistent with IAB directives and good engineering
     practice, an explicit attempt was made to keep this MIB as
     simple as possible.  This was accomplished by applying the
     following criteria to objects proposed for inclusion:

       (1)  Start with a small set of essential objects and add only
            as further objects are needed.

       (2)  Require objects be essential for either fault or
            configuration management.

       (3)  Consider evidence of current use and/or utility.

       (4)  Limit the total of objects.

       (5)  Exclude objects which are simply derivable from others in
            this or other MIBs.

       (6)  Avoid causing critical sections to be heavily
            instrumented.  The guideline that was followed is one
            counter per critical section per layer.

Over the past eight years additional experience has shown a need to
expand these criteria as follows:

       (7)  Before designing a MIB module, identify goals and
            objectives for the MIB module. How much of the
            underlying system will be exposed depends on these
            goals.

       (8)  Minimizing the total number of objects is not an
            explicit goal, but usability is. Be sure to consider
            deployment and usability requirements.

       (9)  During configuration, consider supporting explicit
            error state, capability and capacity objects.

       (10) When evaluating rule (5) above, consider the impact
            on a management application. If an object can help
            reduce a management application's complexity, consider
            defining objects that can be derived.

</quote>

Tom Taylor
[email-masked]
Ph. +1 613 736 0961 (ESN 396 1490)

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

---

From: [email-masked]
Date: Thu, 16 May 2002 11:49:00 +0530

hello,

   Additionally, from my experience

  I would put the approach for MIB design in the following way:

   a. Categorization and Packaging of information.
         MG Terminations could be a package/module on which I can perform
         configuration and control,  get associated statistics and
         alarms. A deployment scenario may  not require all the packages
          defined in the MIBs. This also provides a  good level of abstraction.

  b. Define possible default values for the MIB attributes. A typical SNMP
       based implementation relies more on initial or default values which can
       be used to bring the system up without operator intervension.
Configuration
       changes at runtime tend to be minimal. Pleae note that the default values
       could change for a deployment scenario.

 c.  Normalization of Megaco related notificications attributes to X.721 Alarm
record. This
       provides standardization of  alarm information to the outside world.

   regards

    --
   harish lalapeth
---------------------- Forwarded by Harish Lalapeth/HSS on 05/16/2002 11:26 AM
---------------------------

"Balasubramanian Pitchandi" <[email-masked]> on 05/15/2002 09:30:17 PM

Please respond to [email-masked]

To:   "'Tom-PT Taylor'" <[email-masked]>, [email-masked]
cc:    (bcc: Harish Lalapeth/HSS)

Subject:  RE: [Megaco] Goals For The Megaco MIB

I think the goals can be broadly classified into these categories:

1. Configuration:

     Configuration includes letting the Management application choose
what
     values the system uses. Some of the configurations include:

     i. Media Gateway Configuration (on the MGC side)
     ii. Media Gateway Controller Configuration (on the MG side)
     iii. Termination Configuration
     iv. Connection Configuration
     v. Profile Configuration
     vi. Package Configuration
     vii. Threshold Configuration
     viii. Protocol Configuration (Version, MWD, Transport type etc.)

2. Control:

     After the system is up, the management application would want to

     control the system operation. Some of the control operations
that
     I can think of:

     i. Enabling/disabling Gateways, Terminations, Connections
     ii. Testing the terminations (Loopback, continuity etc.)
     iii. Effecting a switch-over to another MGC (or an MG)
     iv. Adding/Removing terminations

3. Status:

     While the system is up, the management application would want to

     monitor the status of the system. The status can be of two types
     - Solicited Status & Unsolicited status (Notifications or
Alarms).
     Some of the categories of the status that I can think of:

     i. Operational and Admin status of the gateways terminations,
        connections (Solicited)
     ii. Quality notifications (when threshold is violated)
     iii. Protocol error notifications
     iv. Operational notifications (failover, loss of communication
etc)

4. Statistics:

     During the system operation, the management application would
want
     to collect statistics about the system (specific to Megaco). The

     statistics could be then used to control/change other parameters

     as the mgmt app wants. Some of the statistics categories that I
can
     think of:

     i. Protocol Statistics (no. of msgs, no. or errors etc.)
     ii. Alarm statistics (no. of alarms, their severity etc.)
     iii. Switch-over statistics

Also, the goal should be to re-use the already defined MIBs out there to
the maximum possible extent and define only those that are absolutely
necessary for Megaco.

One other goal should be to divide the MIB into two - one for the Media
Gateway and the other for the Media Gateway Controller.

What do others think?

A good discussion on the existing MIB and what all changes folks want
would be really helpful to me while I start to update the MIB draft.

Thanks,
Bala

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tom-PT Taylor
Sent: Wednesday, May 15, 2002 11:13 AM
To: [email-masked]'
Subject: [Megaco] Goals For The Megaco MIB

I've just been reading draft-ietf-snmpconf-bcp-08.txt, which has good
advice
both for MIB design and for implementation.  At one point this document
quotes a number of guidelines for MIB definition and adds a few more
points
to the quotation.  I'll repeat these guidelines below, while putting a
question to the list: what goals should the Megaco MIB(s) satisfy?

<quote>

</quote>

Tom Taylor

DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited (HSS) and is intended solely for the use of the individual
to whom it is addressed. It may contain  privileged or confidential
information  and should not be circulated or used for any purpose other
than for what it is intended. If you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. HSS accepts
no responsibility for loss or damage arising from the use of the information
transmitted by this email including damage from virus.

---

From: [email-masked]
Date: Thu, 16 May 2002 11:49:00 +0530

hello,

   regards

1. Configuration:

2. Control:

3. Status:

4. Statistics:

What do others think?

Thanks,
Bala

-----Original Message-----

<quote>

</quote>

Tom Taylor