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: "Balasubramanian Pitchandi" <[email-masked]>
Date: Wed, 15 May 2002 12:00:17 -0400

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

---

From: "Balasubramanian Pitchandi" <[email-masked]>
Date: Wed, 15 May 2002 12:00:17 -0400

1. Configuration:

2. Control:

	

3. Status:

4. Statistics:

What do others think?

Thanks,
Bala

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

<quote>

</quote>

Tom Taylor

---

From: Christian Groves <[email-masked]>
Date: Thu, 16 May 2002 11:09:03 +1000

G'Day Bala and Tom,

I think in keeping with the spirit of minimising objects we should take a phased
approach to this work. I think configuration issues is probably the most
important thing we have. There's quiet a few protocol options that would be good
to identify in a MIB. Just concentrating on this will also keep the work small.
I suspect the reason why many MIBs don't get completed is because most people
are busy and can't spend time wading through large documents.

I think we also need to concentrate on Megaco as a protocol. Several of the
things listed are more issues of MGC and MG device management which I don't
think is the scope of this group. Other things listed below we already can
achieve through packages (ie. quality notifications). 

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Thu, 16 May 2002 11:09:03 +1000

G'Day Bala and Tom,

Regards, Christian

---

From: "Balasubramanian Pitchandi" <[email-masked]>
Date: Fri, 17 May 2002 19:12:54 -0400

G'Day Christian,

Sorry for the delay in my response. 

I agree with your views that we should take a phased approach to the MIB
development. First I am going to concentrate on the configuration items.

I would start to put together a list of configuration items that I think
need to be configured through MIBs and once the work group discusses and
agrees upon the list then it's pretty simple work to absorb them into
the actual MIB objects. I would have the list of configuration items
ready in a week.

Thanks for your inputs.

Regards, Bala

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Wednesday, May 15, 2002 9:09 PM
To: [email-masked]
Cc: 'Tom-PT Taylor'; [email-masked]
Subject: Re: [Megaco] Goals For The Megaco MIB

G'Day Bala and Tom,

I think in keeping with the spirit of minimising objects we should take
a phased
approach to this work. I think configuration issues is probably the most
important thing we have. There's quiet a few protocol options that would
be good
to identify in a MIB. Just concentrating on this will also keep the work
small.
I suspect the reason why many MIBs don't get completed is because most
people
are busy and can't spend time wading through large documents.

I think we also need to concentrate on Megaco as a protocol. Several of
the
things listed are more issues of MGC and MG device management which I
don't
think is the scope of this group. Other things listed below we already
can
achieve through packages (ie. quality notifications). 

Regards, Christian

---

From: "Balasubramanian Pitchandi" <[email-masked]>
Date: Fri, 17 May 2002 19:12:54 -0400

G'Day Christian,

Thanks for your inputs.

Regards, Bala

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Wednesday, May 15, 2002 9:09 PM
To: [email-masked]
Cc: 'Tom-PT Taylor'; [email-masked]
Subject: Re: [Megaco] Goals For The Megaco MIB

G'Day Bala and Tom,

Regards, Christian