Re: Questions re current sonetng, atm1ng and atm2TC drafts

Peter Jones <> Thu, 26 March 1998 03:37 UTC

Delivery-Date: Wed, 25 Mar 1998 22:37:32 -0500
Received: from (cnri []) by (8.8.7/8.8.7a) with ESMTP id WAA16760 for <>; Wed, 25 Mar 1998 22:37:29 -0500 (EST)
Received: from ( []) by (8.8.5/8.8.7a) with ESMTP id WAA14077 for <>; Wed, 25 Mar 1998 22:40:00 -0500 (EST)
Received: from ( []) by (8.8.8/8.8.8) with SMTP id UAA05960 for <>; Wed, 25 Mar 1998 20:43:46 -0500 (EST)
Received: from by (SMI-8.6/SMI-SVR4) id JAA00985; Thu, 26 Mar 1998 09:43:07 +0800
Message-ID: <>
Date: Thu, 26 Mar 1998 09:43:05 +0800
From: Peter Jones <>
Organization: Atmosphere Networks
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Gary Hanson <>
CC: Kaj Tesink <>,, John Neil <>,
Subject: Re: Questions re current sonetng, atm1ng and atm2TC drafts
References: <Pine.SUN.3.96.980325081245.22941C-100000@skeeter>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Gary,

Gary Hanson wrote:
> Kaj and Peter,
> It is not completely clear to me that it is a problem to have
> one MIB register objects at a level below that of objects
> registered in other MIBs.  For example, just because ATM-MIB
> registers { mib-2 37 }, it is not illegal for ATM-TC-MIB to
> register { mib-2 37 3 }, nor just because ATM-MIB registers
> { mib-2 37 1 } is it illegal for ATM-TC-MIB to register
> { mib-2 37 1 1 }.
> This type of registration of objects at points in the OID
> hierarchy space below that of objects registered by other
> MIBs is done all the time by the non-SMI-defining MIBs.
> This leads me to believe that the fault lies with the MIB
> compiler Peter is using.  It seems to me that there are only
> three reasonable options available to fix the problems that
> Peter is apparently experiencing with his MIB compiler.
> 1.  Abandon the approach of creating an ATM-TC-MIB, and of
>     migrating the OBJECT-IDENTITY object registrations from
>     the ATM-MIB to the ATM-TC-MIB.
> 2.  Register the atmTCMIB MODULE-IDENTITY as a different
>     value under mib-2 (as is done by the PerfHist-TC-MIB in
>     <draft-ietf-atommib-perfhistTC-01.txt), and deprecate
>     the existing objects under atmTrafficDescriptorTypes in
>     favor of new objects under atmObjectIdentifies.
> 3.  Ask the vendor of Peter's MIB compiler to relax its
>     checking of object re-registrations, specifically so
>     that the registration of an object N levels deep does
>     not also imply the simultaneous registration of unnamed
>     objects at levels N-1 or higher.
> I don't like option 1, since I think it is a good step
> forward to migrate the common TEXTUAL-CONVENTIONs and
> OBJECT-IDENTITYs to a MIB dedicated to such definitions.
> I also don't like option 2, or more precisely the second
> part of option 2, since the atmTrafficDescriptorTypes are
> already commonly used, and are not deserving of deprecation
> merely because of our interest in moving them to a new home.
> That leaves me to think option 3 is technically the best
> option, even if it makes things temporarily more difficult
> for those of us who are presently dependent on MIB compilers
> with overly strict object registration checking.
> Regards,
> Gary

I agree that option 1 is no good. I think that using a TC mib 
to contain common TC and OBJECT-IDENTITY constructs for all the 
related ATM MIBs is entirely sensible.

As you point out, option 2, although it is the most correct, has 
nasty implications.

It is true that part of my problem is caused by the MIB compiler 
being finicky. It expects OID values to be of the form { mib2 xxx } 
and does not accept { mib2 xx xx xx }. I can get around this by 
editing the MIB texts to add extra defintions (e.g.  { mib-2 37 }
and  { mib-2 37 1 } ) to the atm2TC MIB so that it can 
compile before atm1ng, and telling the MIB complier to
live with the redefinition of an OID with it runs into the real 
specification of atmMIB and atmMIBObjects in atm1ng.

You point out the all sorts of MIBs register underneath subtrees 
from other MIBs, but from what I have seen, they usually do this 
with an IMPORT clause. An example would the the IP fowarding MIB 
(RFC1354) that imports "ip" from rfc1213 and then defines ipForward 
as { ip 24 }. This is not what is happening in atm2TC, the equivelent 
would be to IMPORT atmMib from atm1ng, but then you would have the 
circular dependancy.

What I am complaining about with the atm1ng/atm2TC pair is that 
the atmTCMIB and atmTrafficDescriptorTypes from atm2TC are within 
the OID subtree of atm1ng, and atm1ng IMPORTS from atm2TC. This is 
why I said there was an effective IMPORT of atmMIB and atmMIBObjects 
from atm1ng. 

This means that we have atm2TC importing it's OID subtree attachment 
points from atm1ng, and atm1ng importing TCs and the 
atmTrafficDescriptorTypes from atm2TC.

This seems to be to be a bad design, atm2TC depends on atm1ng and 
atm1ng depends on atm2TC. I am aware of the history and 
I'm not sure how to fix this at this point in time.

So that's the problem that I see, and I don't know what the correct 
way to solve it is. My guess was that if the group started now,
it would probably make the TC MIB the one that hooked into mib-2,
and hang all the other mibs underneath the TC MIB. In this way, 
the TC mib would contain all the common definitions.


Peter Jones                           Atmosphere Networks
Manager of Software Development       4th Floor, Balcroft Building
                                      Garden Office Park
                                      345 Harborne Street
                                      Osborne Park WA 6017, Australia
Direct: +61 (8) 9443 0105             Main: +61 (8) 9443 0100
                                      Fax:  +61 (8) 9443 6610