sonetng-specific traps (Was Re: Questions re current sonetng, atm1ng , and atm2TC drafts)

[Gary Hanson <[e-mail]>]

Kaj and Peter,

On Tue, 24 Mar 1998, Kaj Tesink wrote:

> 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 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.

> 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).

Gary