Subject: fwd: Has V3 changed the SNMP philosophy?

From: Randy Presuhn <[email-masked]>
Date: Mon, 15 Mar 1999 13:25:28 -0800 (PST)

Hi -

Attached is a non-spam non-member posting to the disman list.

 -----------------------------------------------------------------------
 Randy Presuhn           [email-masked]     http://www.bmc.com
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 -----------------------------------------------------------------------
 Any relationship between my opinions and BMC's is coincidental.
 -----------------------------------------------------------------------

> From owner-disman  Sat Mar 13 15:06:02 1999
> Received: from tangelo.bmc.com ([email-masked] [172.17.7.166])
> 	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA19564
> 	for <[email-masked]>; Sat, 13 Mar 1999 15:06:01 -0800 (PST)
> Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250])
> 	by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id RAA05885
> 	for <[email-masked]>; Sat, 13 Mar 1999 17:06:00 -0600 (CST)
> Received: from rfrye.reston.mci.net ([166.44.166.253])
>  by shoe.reston.mci.net (PMDF V5.2-29 #33823)
>  with SMTP id <[email-masked]> for
>  [email-masked]; Sat, 13 Mar 1999 18:05:58 EST
> Date: Sat, 13 Mar 1999 17:58:52 -0500
> From: Rob Frye <[email-masked]>
> Subject: RE: Has V3 changed the SNMP philosophy?
> In-reply-to: <[email-masked]>
> To: [email-masked]
> Reply-to: [email-masked]
> Message-id: <[email-masked]>
> MIME-version: 1.0
> X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4
> X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
> Content-type: text/plain; charset=iso-8859-1
> Content-transfer-encoding: 7BIT
> Importance: Normal
> X-Priority: 3 (Normal)
> X-MSMail-priority: Normal
> 
> SNMPv3 has changed some aspects of SNMP, just as v2 changed some from v1.
> I do not believe these to be "detrimental" effects.  Yes, to some extent
> I believe Inform has been touted as, and can be used as, "acknowledged
> traps".  But that acknowledgement only goes so far; there have been
> many discussions about just how "reliable" they are in a congested
> network or a multi-layered, busy management system.  The disman
> Notification MIB helps even more, but still does not "guarantee"
> the delivery of traps/informs/notifications to the entity that
> will ultimately process them.
> 
> As for the philosophy of trap directed polling, I believe that traps/informs
> should carry sufficient information for a management application
> to determine WHAT is wrong, not just that there was "some kind of problem".
> In a large network, trap directed polling requires distributed,
> hierarchical polling/management.  But even "reliable traps" can not
> be counted on for good management: is no news good news, or REALLY BAD
> news such that you can't even hear the bad news?
> 
> My US$0.02.
> 
> -- Rob.
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Rob Frye ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Sr. Network Management Architect   Email:          [email-masked]
> MCI WorldCom                       Phone: +1-703-715-7225/V272-7225
> 2100 Reston Parkway, Suite 600     Fax:   +1-703-715-7436/V272-7436
> Reston, VA  20191                  Pager:           +1-888-270-1537
> ~~~~~~~~~~~Strive always to generate more light than heat~~~~~~~~~~
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf
> > Of Shobana Sundaram
> > Sent: Friday, March 12, 1999 9:38 AM
> > To: internet; internet
> > Subject: Has V3 changed the SNMP philosophy?
> >
> >
> >
> >
> > I am curious to know if V3 has changed the fundamental SNMP philosophy.
> > RFC 1909 has an appendix that talks
> > about the "Inform Request" usage in SNMP v2.  See below for details.
> > This emphasizes that
> > we shouldn't use it as acknowledged traps. In SNMP V3, I believe that
> > there is not a clean distinction between agent and
> > manager. Are we promoting the use of  confirmed notifications to
> > guarantee reliable alarm surveillance in carrier environments?.
> > If we really want to be foolproof, we need something like the
> > Notification Log MIB to back up data from notifications.
> > Is anyone aware of any good solution to provide reliable  alarm
> > surveillance?
> >
> >
> >
> > ------------------------------------------------------------------
> > ---------------------------
> >
> >           An InformRequest-PDU is generated and transmitted at the
> >           request of an application in a SNMPv2 entity acting in a
> >           manager role, that wishes to notify another application (via
> >           an SNMPv2 entity also acting in a manager role) of information
> >
> >           in a MIB view which is accessible to the sending SNMPv2 entity
> >
> >           when acting in an agent role.
> >
> >
> >
> >
> > APPENDIX B - Who Sends Inform-Requests?
> >
> > B.1.   Management Philosophy
> >
> >    Ever since its beginnings as SGMP, through its definition as SNMPv1,
> >    and continuing with the definition of SNMPv2, SNMP has embodied more
> >    than just a management protocol and the definitions of MIB objects.
> >    Specifically, SNMP has also had a fundamental philosophy of
> >    management, consisting of a number of design strategies.  These
> >    strategies have always included the following:
> >
> > (1)  The impact of incorporating an SNMP agent into a system should be
> >      minimal, so that both: a) it is feasible to do so even in the
> >      smallest/cheapest of systems, and b) the operational role and
> >      performance of a system is not compromised by the inclusion of an
> >      SNMP agent.  This promotes widespread development, which allows
> >      ubiquitous deployment of manageable systems.
> >
> > (2)  Every system (potentially) incorporates an SNMP agent.  In
> >      contrast, the number of SNMP managers is limited.  Thus, there is a
> >
> >      significantly larger number of SNMP agents than SNMP managers.
> >      Therefore, overall system development/complexity/cost is optimized
> >      if the SNMP agent is allowed to be simple and any required
> >      complexity is performed by an SNMP manager.
> >
> >
> > (3)  The number of unsolicited messages generated by SNMP agents is
> >      minimized.  This enables the amount of network management traffic
> >      to be controlled by the small number of SNMP managers which are
> >      (more) directly controlled by network operators.  In fact, this
> >      control is considered of greater importance than any additional
> >      protocol overhead which might be incurred.  Monitoring of network
> >      state at any significant level of detail is accomplished primarily
> >      by SNMP managers polling for the appropriate information, with the
> >      use of unsolicited messages confined to those situations where it
> >      is necessary to properly guide an SNMP manager regarding the timing
> >
> >      and focus of its polling.  This strategy is sometimes referred to
> >      as "trap-directed polling".
> >
> > B.2.   The Danger of Trap Storms
> >
> >    The need for such control over the amount of network management
> >    traffic is due to the potential that the SNMP manager receiving an
> >    unsolicited message does not want, no longer wants, or already knows
> >    of the information contained in the message.  This potential is
> >    significantly reduced by having the majority of messages be specific
> >    requests for information by SNMP managers and responses (to those
> >    requests) from SNMP agents.
> >
> >
> >    The danger of not having the amount of network management be
> >    controlled in this manner is the potential for a "storm" of useless
> >    traps.  As a simple example of "useless", consider that after a
> >    building power outage, every device in the network sends a coldStart
> >    trap, even though every SNMP manager and every network operator
> >    already knows what happened.  For a simple example of "storm",
> >    consider the result if each transmitted trap caused the sending of
> >    another.  The greater the number of problems in the state of the
> >    network, the greater the risk of such a storm occurring, especially
> >    in the unstructured, heterogeneous environment typical of today's
> >    internets.
> >
> >    While SNMP philosophy considers the above to be more important than
> >    any lack of reliability in unsolicited messages, some
> >    users/developers have been wary of using traps because of the use
> >    (typically) of an unreliable transport protocol and because traps are
> >
> >    not acknowledged.  However, following this logic would imply that
> >    having acknowledged-traps would make them reliable; of course, this
> >    is false since no amount of re- transmission will succeed if the
> >    receiver and/or the connectivity to the receiver is down.  A SNMP
> >    manager cannot just sit and wait and assume the network is fine just
> >    because it is not receiving any unsolicited messages.
> >
> > B.3.   Inform-Requests
> >
> >    One of the new features of SNMPv2 is the Inform-request PDU.  The
> >    Inform-Request contains management information specified in terms of
> >    MIB objects for a context supported by the sender.  Since by
> >    definition, an SNMPv2 manager does not itself have managed objects
> >    (see sections 3.3), the managed objects contained in the Inform-
> >    request belong to a context of an SNMPv2 agent, just like the managed
> >
> >    objects contained in an SNMPv2-Trap.
> >
> >    However, it is not the purpose of an Inform-request to change the
> >    above described philosophy, i.e., it would be wrong to consider it as
> >
> >    an "acknowledged trap".  To do so, would make the likelihood and
> >    effect of trap storms worse.  Recall the building power outage
> >    example:  with regular traps, the SNMP manager's buffer just
> >    overflows when it receives messages faster than it can cope with; in
> >    contrast, if every device in the network were to send a coldStart
> >    Inform-request, then after a power outage, all will re-transmit their
> >
> >    Inform-request several times unless the receiving SNMP managers send
> >    responses.  In the best case when no messages are lost or re-
> >    transmitted, there are twice as many useless messages; in the worst
> >    case, the SNMP manager is unable to respond at all and every message
> >    is re-transmitted its maximum number of times.
> >
> >
> >    The above serves to explain the rationale behind the definition (see
> >    Appendix A's update to section 4.2.7 of [4]) that:
> >
> >      An InformRequest-PDU is generated and transmitted at the request of
> >
> >      an application in a SNMPv2 entity acting in a manager role, that
> >      wishes to notify another application (via an SNMPv2 entity also
> >      acting in a manager role) of information in a MIB view which is
> >      accessible to the sending SNMPv2 entity when acting in an agent
> >      role.
> >
> >    This definition says that SNMPv2 agents do not send Inform-Requests,
> >    which has three implications (ordered in terms of importance):
> >
> > (1)  the number of devices which send Inform-requests is required to be
> >      a small subset of all devices in the network;
> >
> > (2)  while some devices traditionally considered to be SNMP agents are
> >      perfectly capable of sending Inform-requests, the overall system
> >      development/complexity/cost is not increased as it would be by
> >      having to configure/re-configure every SNMPv2 agent as to which
> >      Inform-requests to send where and how often; and
> >
> > (3)  the cost of implementing an SNMPv2 agent in the smallest/cheapest
> >      system is not increased.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 
>