Subject: Re: Questions re current sonetng, atm1ng and atm2TC drafts

From: Kaj Tesink <[email-masked]>
Date: Tue, 24 Mar 1998 12:13:28 -0500

At 12:04 PM 3/23/98 +0800, Peter Jones wrote:
>Hi Kaj,
>
>Kaj Tesink wrote:
>> 
>> hi peter,
>> 
>> thanks for your mail; good points; i'll forward some of it to the quality review
>> process folks so that we can fix any problems.
>> 
>> some observations:
>> - on your sonet mib suggestion to add a trap:
>>   i appreciate the desire of alignment but have you thought of simply
>>   sending the line status object along with linkUp/Down traps?
>>   the sonet mib is under quality review and i prefer to make minor
>>   changes only.
>> 
>
>I don't think sending extra objects along with a linkUp/LinkDown trap is
>an acceptable solution. Our experience is that this usually results in
>interworking problems with other managers and devices. I think that the 
>linkUp/linkDown traps provide a differnet service that the
>dsx1LineStatusChange
>type traps.

i thought you would say this.
any folks out there who would second this request
"to align the sonet/sdh mib with the other trunk mibs
regarding this trap"?

>
>We are trying to build a "unified" infrastructure forhandling "telco"
>type alarms notification, and want to use the facilities from the
>standard MIBs wherever possible. The dsx1LineStatusChange Notification
>is a good fit for what we want. As far as the sonetng mib goes, it
>already has the objects that contain the status bits, all that is
>missing is a standard way to notify this to a management application
>(whether local to the device or remote).
>
>
>> - on your observation that the various atm mibs seem to IMPORT from
>>   each other: i thought that was fixed a long time ago. i know
>>   i made some changes because of that. well, obviously we need to check this
>>   and fix as result of the quality review process.
>> 
>
>Regarding the importing, atm2TC does not directly import from atm1ng, it
>cheats.
>
>For instance:
>1)	The MODULE-IDENTITY clause from atm2TC really is { atmMIB 3 } which
>	is in atm1ng. The specification using { mib-2 37 3 } ducks around 
>	the problem that the  mib-2 37 is defined in atm1ng. Our MIB 
>	compiler complains that atm1ng is redefining an OID already 
>	specified in atm2TC.
>               atmTCMIB MODULE-IDENTITY
>                    ::= { mib-2 37 3 } -- atmMIB 3

i'll look into it; i thought we got it fixed but will check

>
>2)	A similar problems exists for the traffic descriptor types, 
>	with the {atmMIBObjects 1} branch being moved from atm1ng 
>	to atm2TC. The same techniques is used to get around the 
>	issue, by specifying 
>	atmTrafficDescriptorTypes OBJECT IDENTIFIER ::= {mib-2 37 1 1}.
>	This causes us the same problem when compiling atm1ng where our
>	compiler says that atmMIBObjects (i.e. mib-2 37 1) has already 
>	been defined in atm2TC. 

hadnt seen this one before

>
>That's the essence of what I am complaining about. Hooking the OIDs
>defined
>in atm2TC onto the subtree defining in atm1ng is not good.

will check
>
>
>> - your question on the status of the mibs:
>>   atm1ng and atmtc: have been quality reviewed - i'm waiting to hear from the
>>   area director. i'll ping him. then we do the fixes and that  should be it.
>>   atm2: you have seen the new draft (thanks for your comments).
>>   mickey wants to make one more update.
>>   accounting mibs: have been quality reviewed - i'm waiting to hear from the
>>   area director. i'll ping him.
>> 

>> hope you're up-to-date again,
>> 
>> thanks for the feedback,
>> 
>> kaj
>
>regards
>peter
>
>
>-- 
>______________________________________________________________________
>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
>mailto:[email-masked]        http://www.atmospherenet.com
>_______________________________________________________________________
> 

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/                                                                      _/
_/  Kaj Tesink                                                          _/
_/  Bellcore                                                            _/
_/  Business Internet Professional Services  vmail (732) 758-5254       _/
_/  331 Newman Springs Rd.                   email [email-masked]  _/
_/  Red Bank, NJ 07701                     faxmail (732) 758-2269       _/
_/                                                                      _/
_/  * NOTE AREA CODE CHANGE (908) --> (732) EFFECTIVE JUNE 1, 1997 *    _/
_/                                                                      _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

---

From: Kaj Tesink <[email-masked]>
Date: Tue, 24 Mar 1998 12:13:28 -0500

will check

---

From: Gary Hanson <[email-masked]>
Date: Wed, 25 Mar 1998 08:12:30 -0800 (PST)

Kaj and Peter,

> >linkUp/linkDown traps provide a differnet service that the

I agree that linkUp/linkDown traps provide a different service
than the dsx1LineStatusChange type traps, and that having traps
for other MIB-specific status variable value changes can be
beneficial.  For which objects in the SONET-MIB in the sonetng-02
draft are you proposing adding traps?  I see the following as
potential candidates:
- sonetSectionCurrentStatus
- sonetLineCurrentStatus
- sonetPathCurrentStatus
- sonetVTCurrentStatus

Are you also suggesting adding objects to enable/disable such
MIB-specific traps, again along the lines of the trunkmib objects?

By the way, I disagree with the statement that adding extra objects
into a linkUp/linkDown trap results in interworking problems.  Not
only is the practice specifically allowed in RFC 1157 and RFC 1215
(although the latter is for some reason only an informational RFC),
but I have never previosly heard any reports that this led to
interoperability problems between managers and agents.  At worst,
I would suspect that the offending management applications might
need to be fixed in future versions.

> >(whether local to the device or remote).

Gary

---

From: Gary Hanson <[email-masked]>
Date: Wed, 25 Mar 1998 08:45:31 -0800 (PST)

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

On Tue, 24 Mar 1998, Kaj Tesink wrote:

> >> [...]

---

From: Peter Jones <[email-masked]>
Date: Thu, 26 Mar 1998 09:43:05 +0800

Hi Gary,

> with overly strict object registration checking.

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.

regards
peter

---

From: Kaj Tesink <[email-masked]>
Date: Wed, 25 Mar 1998 18:30:23 -0500

>{ mib-2 37 1 } is it illegal for ATM-TC-MIB to register

thats what i thought; it shouldnt
>with overly strict object registration checking.

i will check the drafts on their correctness 
but i think i agree with this too.