Subject: RE: SONET PM trap definitions

From: Kaj Tesink <[email-masked]>
Date: Mon, 08 Apr 2002 14:56:26 -0500

Orly and David,

the points that you both make reflect very well the classical discussion
on the pros and cons of trapping. that discussion was never fully resolved
to all satisfaction and thats probably why this pops up again.

let me make some general points based on previous discussion:
- one of the goals of the snmp framework is to keep the agent simple
- to avoid the problem of 'trap-storms', the philosophy tended
   to be conservatism towards standardizing traps; the idea was
   to try 'trap-directed polling' instead
- for non-real-time cases it usually seems to make sense not to define
   standard traps; after all the nms can always retrieve on an
   as-needed/when-needed basis and of course we keep interval history
   anyway in the sonet mib
- having said that, there are plenty of examples of standard traps
   in various mib modules; if consensus shows that traps are needed
   they should preferably have dis/en-able knobs to deal with above
   problems.
- an alternative that always exists is to define enterprise-specific
   mib extensions.

i copy this to the list for further input,

kaj

At 12:02 PM 4/8/2002 -0400, Albert, David wrote:
>There is always the opposite case where the management is not interested 
>in all PM at all times and sending traps will flood the net for no reason.
>[Albert, David] Agreed, a good MIB design will allow this feature to be 
>en/disabled.  In ITU TMN standards, there is a feature called 
>zero-suppression in which PM periods with no error counts may be 
>trap-suppressed up to some user definable maximum number of periods.
>
>In a real net there are many interfaces and one trap per 15 min. will not 
>hold the full set of data.
>[Albert, David] Agreed, I would expect one trap per interface.
>
>There is new/renew work dealing with transfer of large amount of 
>information such as statistics, that you should look at. It seems more 
>appropriated than traps. After all if the goal is to observe network 
>behaviors, or to use the information for accounting, the information does 
>not have to be transferred in real time, but can be collected to file and 
>transferred in blocks at a later time. (look at EOS WG).
>[Albert, David] This is true, but it defeats one of the primary reasons 
>for defining standard MIBs and protocols; namely the standardization of 
>information exchange syntax (protocols) and semantics (MIBs).  I agree 
>that a technique for bulk transfer of file information is useful, but 
>primarily for proprietary information (downloading new binary software, 
>etc.) or other information that has no need for manager knowledge of 
>semantics.
>
>If the information is needed to predict failure, it can still be adjusted 
>to be sent promptly based on the same mechanism.
>[Albert, David] The primary application is accounting; fault prediction is 
>much rarer and would typically be accomplished by setting thresholds above 
>which error traps (threshold crossing alerts) should be issued.
>
>Thank you for sharing your thoughts on this, I am enjoying the discussion!
>
>Sincerely,
>David Albert
>CIENA Corporation
>
>
>Orly
>-----------------------
>Orly Nicklass, Ph.D
>Associate VP, R&D
>RAD Data Communications, Ltd.
>
>[email-masked]
>
>-----Original Message-----
>From: Kaj Tesink [mailto:[email-masked]]
>Sent: Tuesday, March 26, 2002 4:32 PM
>To: Albert, David
>Cc: Reddy, Sudheer; [email-masked]
>Subject: RE: SONET PM trap definitions
>
>David,
>yes, i understand your reasoning. this is not
>the first time that this point comes up and
>digging in the archives of various SNMP
>discussion lists will certainly yield many arguments
>both for trap-directed polling and for the
>trap policy that you're advocating.
>
>this document has been written consistent with
>the specs for DS1/E1 and DS3/E3. of course all
>these specs have the same issue. the current status
>of all these specs is that they're are in the process
>of being bumped up in the ietf standards ladder.
>so changes or additions at this time would not work.
>however, from time to time other additions have been
>proposed (for example recent proposals for better SDH
>support). so the idea is that if there is sufficient
>support and consensus to write some kind of a supplemental
>mib module.
>therefore my suggestion is that you
>- first sound out the atommib list on whether there is
>   more support on your proposal
>- if there's broader support then write a specific
>   proposal incl miblet
>- fold that into the yet to be written supplemental
>   mib (no editor has been identified yet)
>
>does this make sense.
>comments from anybody else out there?
>
>kaj
>
>
>
>At 03:39 PM 3/25/2002 -0500, Albert, David wrote:
>>Thank you for your reply and I will certainly subscribe
>>to the discussion group.  While I agree that severe
>>performance problems might result in a linkDown
>>trap and cause a management system to poll performance
>>monitoring data, this is not the likely expected or desired
>>behavior for SONET/SDH performance monitoring.
>>
>>PM data is typically gathered every 15-minute and 24-hour
>>period (sometimes limited to non-zero periods) and recorded
>>in the management system for use in service layer management.
>>The PM data is often used to demonstrate to compliance with
>>performance guarantees that have been made to customers.  Some
>>systems also try to use performance data to do predictive failure
>>analysis.  Because this data is needed regularly, forcing management
>>systems to poll will simply double network traffic (GET/RSP instead
>>of TRAP) and increase the load on agents.
>>
>>There are certain traps whose definition as part of a SONET/SDH
>>standard would IMHO greatly increase acceptance of SNMP as a
>>management mechanism for telecommunications networks including:
>>PM, Faults (LOS, LOF, LOP, AIS, etc.), security, dbChange.
>>I would be happy to make a contribution in this area if you think it
>>would help.
>>
>>Regards,
>>David Albert
>>CIENA
>>-----Original Message-----
>>From: Kaj Tesink [mailto:[email-masked]]
>>Sent: Friday, March 22, 2002 5:56 PM
>>To: Albert, David
>>Cc: Reddy, Sudheer; [email-masked]
>>Subject: Re: SONET PM trap definitions
>>
>>At 04:56 PM 3/22/2002 -0500, Albert, David wrote:
>>>Hello Kaj,
>>>    I enjoyed reading your excellent RFC (2558) defining
>>>SONET/SDH Interfaces for SNMP.  Do you know whether
>>>a MIB definition exists for a PM reporting TRAP (i.e. a
>>>standard TRAP that can be sent periodically to a management
>>>system notifying it of a newly completed PM interval and the
>>>collected PM statistics rather than forcing the manager to
>>>poll the interval table?)  If you are aware of a standard that
>>>defines such a trap or can point me in the right direction, I
>>>would appreciate it.  Thank you!
>>>
>>>Sincerely,
>>>
>>>David Albert
>>>CIENA
>>hi David,
>>
>>i'm not aware of current standard definitions for such traps;
>>there may be enterprise-specific traps. this mib was written based on
>>polling assumptions; the nms can set its own polling policy.
>>high error situations would generate linkDown traps and may trigger the nms
>>to inspect specific pm parameters.
>>
>>I copy your comments to the discussionlist of the atommib wg
>>which is the appropriate forum to discuss these issues. See
>>http://www.ietf.org/html.charters/atommib-charter.html
>>for subscription info.
>>
>>this has also some mib extensions for SONET APS.
>>
>>Note that 2558 is being evaluated right now and implementation experience is
>>being requested. Please send your implementation report to
>>Faye Ly <[email-masked]>
>>Use the compliance clause as guidance.
>>
>>
>>
>>kaj
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>>
>>Kaj Tesink
>>Telcordia Technologies. In.
>>331 Newman Springs Road
>>Red Bank, NJ 07701
>>Email: kaj @research.telcordia.com
>>Tel: (732) 758-5254
>>Fax: (732) 758-4177
>>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
>
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
>Kaj Tesink
>Telcordia Technologies. In.
>331 Newman Springs Road
>Red Bank, NJ 07701
>Email: kaj @research.telcordia.com
>Tel: (732) 758-5254
>Fax: (732) 758-4177
>
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies. In.
331 Newman Springs Road
Red Bank, NJ 07701
Email: kaj @research.telcordia.com
Tel: (732) 758-5254
Fax: (732) 758-4177

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 8 Apr 2002 22:59:47 +0200

Inline

> Sent: Monday, April 08, 2002 9:56 PM
> To: Albert, David; 'Orly Nicklass'
> Cc: [email-masked]

But not at all cost anymore. We understand that network devices
(and certainly the larger ones) can be more intelligent than what
we had back in the late 80s.

>   to try 'trap-directed polling' instead

Well, we do have MIBs now to configure trap destinations and to
filter traps to specific destinations etc. So we have much better
control than we had 10 years ago.

>   they should preferably have dis/en-able knobs to deal with above

And various MIBs do have that.

> There is always the opposite case where the management is not 
> interested in all PM at all times and sending traps will 
> flood the net for no reason. 
> [Albert, David] Agreed, a good MIB design will allow this 
> feature to be en/disabled.  In ITU TMN standards, there is a 
> feature called zero-suppression in which PM periods with no 
> error counts may be trap-suppressed up to some user definable 
> maximum number of periods.
> 
> 
> In a real net there are many interfaces and one trap per 15 
> min. will not hold the full set of data. 
> There is new/renew work dealing with transfer of large amount 
> of information such as statistics, that you should look at. 
> It seems more appropriated than traps. After all if the goal 
> is to observe network behaviors, or to use the information 
> for accounting, the information does not have to be 
> transferred in real time, but can be collected to file and 
> [Albert, David] This is true, but it defeats one of the 
> primary reasons for defining standard MIBs and protocols; 
> namely the standardization of information exchange syntax 
> (protocols) and semantics (MIBs).  I agree that a technique 
> for bulk transfer of file information is useful, but 
> primarily for proprietary information (downloading new binary 
> software, etc.) or other information that has no need for 
> manager knowledge of semantics. 
>  
> If the information is needed to predict failure, it can still 
> be adjusted to be sent promptly based on the same mechanism. 
> [Albert, David] The primary application is accounting; fault 
> prediction is much rarer and would typically be accomplished 
> by setting thresholds above which error traps (threshold 
> crossing alerts) should be issued. 
>