Subject: fw: Has V3 changed the SNMP philosophy?

From: "Shobana Sundaram" <[email-masked]>
Date: Fri, 12 Mar 1999 09:44:37 -0500

Sundaram, Shobana (EXCHANGE:CAR:5D15) wrote:
     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.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Mar 1999 16:25:10 +0100

[Please turn off your HTML!]

>>>>> Sundaram, Shobana (EXCHANGE:CAR:5D15) wrote: 

Shobana> I am curious to know if V3 has changed the fundamental SNMP
Shobana> philosophy.  RFC 1909 has an appendix that talks about the
Shobana> "Inform Request" usage in SNMP v2.  See below for details.
Shobana> This emphasizes that we shouldn't use it as acknowledged
Shobana> traps. In SNMP V3, I believe that there is not a clean
Shobana> distinction between agent and manager. Are we promoting the
Shobana> use of confirmed notifications to guarantee reliable alarm
Shobana> surveillance in carrier environments?.

SNMPv3 allows an agent (or better the notification originator
application of an agent) to send notification via traps or informs.
An inform does not give you a "guaranteed reliable alarm" - but it
enables the notification originator to take appropriate actions if the
notification does not get through.

Shobana> If we really want to be foolproof, we need something like the
Shobana> Notification Log MIB to back up data from notifications.

Exactly. Thats why some of us believe the Notification Log MIB is
actually part of the SNMP infrastructure and not necessarily a DISMAN
work item. In some environments, you also have the chance to send the
notification via backup links if the normal path does not work. But
there are no activities I know of within the IETF to standardize
something like this.
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

---

From: Bob Natale <[email-masked]>
Date: Fri, 12 Mar 1999 13:10:07 -0500

>At 3/12/99:10:25 AM, Juergen Schoenwaelder wrote:

Hi Juergen,

>[Please turn off your HTML!]

[General comment: Yes, folks have to start thinking about
which e-mail product features work well among *identical*
mailers at one extreme [say, within a corporation using
Notes or Outlook] and those features which [for the most
part, thankfully] work across all or nearly all different
mailers.  For now: forget HTML, forget color/bold/italics,
forget fancy fonts, forget "autmatic attachments", forget
receipt- and read- notifications, etc.  Go with plain text
and (mostly safe) MIME attachments.]

<...>
>application of an agent) to send notification via traps or informs. 

...or the notification originator part of a "manager".

>enables the notification originator to take appropriate actions if
>the notification does not get through.

Just a nit...but the origniator of an inform that does not see a
response to the inform does not know that the inform did not get
through...only that he did not receive the response to it (which,
of course, may have been dropped along the way back from the
inform recipient)...consideration of this scenario *might* be
important in determining what is an *appropriate* action in
certain cases.

I don't mean to make a mountain out of a molehill there...it's
just a wrinkle on the case-specific logic that might be applicable.
Reasonable timeout/retry mechanisms in the notification originator
might work in most cases to ensure that the notification is not
reaching the target.  The concern (remote) is that, in some cases,
either sending duplicate informs and/or taking autonomous action
in the agent due to non-receipt of a response to an inform might
be problematic.

The last resort, I suppose, is that if an inform originator does
not receive a response, exhausts any applicable timeout/retry
cycles, and checks some applicable objects to determine that the
notification target has not taken the expected action(s) in
response to the inform, then it's a safe bet that autonomous
action is called for.

[As I said, all of that really amounts to a footnote in an
over-zealous checklist of notification originator logic design.]

>notification via backup links if the normal path does not work.

Yep...works for me.

Cordially,

BobN
------------ ISO 9001 Registered Quality Supplier -----------
Bob Natale         | ACE*COMM              | 301-721-3000 [v]
Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f]
[email-masked]| Gaithersburg MD 20878 | www.acecomm.com
------------- Free downloads at www.winsnmp.com -------------