home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 95apr / disman-minutes-95apr.txt < prev    next >
Text File  |  1995-05-27  |  19KB  |  535 lines
  1.  
  2. Distributed Network Management BOF (DISMAN)
  3.  
  4. Reported by Donna McMaster/Bay Networks and Glenn Waters/Bell-Northern
  5. Research
  6.  
  7. The DISMAN BOF, chaired by Bob Stewart, met on Tuesday, 4 April.  The
  8. purpose of the BOF was to discuss the Manager-to-Manager (M2M) MIB and
  9. other distributed management work that the IETF Network Management Area
  10. might consider tackling.
  11.  
  12. Bob Stewart presented the agenda, which was accepted as proposed:
  13.  
  14.  
  15.    o Agenda Bashing
  16.    o Introduction, Bob Stewart, Cisco
  17.    o Steve Waldbusser, CMU
  18.    o Brian O'Keefe, Hewlett-Packard
  19.    o David Levy, SNMP Research
  20.    o Karl Auerbach, CaveBear
  21.    o Yechiam Yemini, Columbia University
  22.    o Open Discussion and Summary
  23.  
  24.  
  25. Bob Stewart's Presentation
  26.  
  27. Bob discussed why the SNMPv2 Working Group decided to separate M2M MIB
  28. from other SNMPv2 work.  Bob expects the group will end up with at least
  29. a charter to clean up, fix, and finish the M2M MIB. Dave Perkins
  30. suggested that M2M work could be split, leaving some of the
  31. event-handling framework in the SNMPv2 group and creating a new group to
  32. handle the rest of the current draft.
  33.  
  34. Bob also gave an overview of distributed management and suggested where
  35. we might go from here.  (See slides.)  Bob's final slide, ``Where We
  36. Might Go,'' summarized options.  Bob expects that building ``something
  37. completely different'' will not be a popular option.  He expects that we
  38. must at least fix M2M problems.  Defining MIBs for expressions (e.g.,
  39. computing utilization), scripts (e.g., ``if x then y''), and programs
  40. (more complexity) fall in between and will need more discussion.
  41.  
  42.  
  43. Steve Waldbusser's Presentation
  44.  
  45. Steve pointed out that the fundamental concepts in the M2M MIB have been
  46. implemented and used in the RMON MIB for several years.  He presented a
  47. slide to illustrate a split between the framework and applications
  48. pieces of the MIB.
  49.  
  50. Manager-to-Manager
  51.  
  52.    o ``Framework''
  53.       -  Event forwarding
  54.       -  Delegation?
  55.  
  56.    o Applications
  57.       -  Threshold polling (i.e., alarmTable)
  58.       -  History
  59.       -  Scripting
  60.       -  Topology discovery
  61.       -  ...
  62.  
  63. With regard to the framework, Steve pointed out that event processing is
  64. a key feature of the management that we do, and that forwarding events
  65. to a hierarchy of consoles is a natural extension.  He would be
  66. interested in getting together with others interested in exploring these
  67. ideas.
  68.  
  69. Steve deferred the discussion of delegation to the speakers that follow.
  70.  
  71.  
  72.  
  73. Brian O'Keefe's Presentation
  74.  
  75. Brian discussed the Manager-to-Manager (M2M) MIB status and presented an
  76. overview of the MIB. He also suggested some evolutionary changes that
  77. could be made to M2M. Brian made the disclaimer that these slides
  78. represent his perceptions as he was not an author of the M2M MIB.
  79.  
  80. When asked for implementation experience, two or three hands were
  81. raised, and only one indicated that the MIB is deployed.  However, it
  82. was pointed out that there is a lot of implementation experience with
  83. similar concepts in the RMON MIB.
  84.  
  85. Following Brian's presentation, someone asked the difference between M2M
  86. and RMON. Brian responded that the functions are similar, but RMON looks
  87. at what to monitor and M2M looks at how to monitor (the mechanism).
  88.  
  89. The RMONMIB Working Group Chair, Andy Bierman, noted that the RMONMIB
  90. Working Group has deferred work on the Alarms and Events groups to the
  91. M2M effort.
  92.  
  93. A text version of Brian's slides follows.  Note that the two
  94. ``Proposal'' sections were not actually presented during the BOF, but
  95. are included here for anyone interested.  Brian asks readers to keep in
  96. mind they are only preliminary/straw proposals to address the issues
  97. identified in the earlier portion of the presentation.
  98.  
  99.  
  100.    o Purpose:  (initial version)
  101.  
  102.       -  Remote configuration of sampling/threshold monitoring engines
  103.          for alarm generation
  104.  
  105.       -  Also provides some capability for hierarchical-based
  106.          polling/monitoring (i.e., last sampled value)
  107.  
  108.  
  109.    o Current status:
  110.  
  111.       -  Proposed Standard (RFC 1451, April 1993)
  112.    
  113.       -  Originally part of the SNMPv2 document set
  114.    
  115.       -  The SNMPv2 Working Group deferred work to new working group
  116.          per {57} (so as to focus on ``core'' SNMPv2 framework)
  117.    
  118.       -  Implementation experience:
  119.           * Actual M2M MIB implementations?  Deployed/in-use?
  120.           * Many SNMP sampling/threshold monitoring engines exist (but
  121.             not using standard configuration methods)
  122.    
  123.    o Overview:
  124.  
  125.      There are two object groups and a total of three tables (plus
  126.      support_scalars):
  127.  
  128.       -  Event Group
  129.  
  130.          snmpEventTable       Description and statistics for configured 
  131.                               notifications  
  132.  
  133.          snmpEventNotifyTable Configures transmission of notifications 
  134.                               specified in Event Table
  135.       -  Alarm Group
  136.  
  137.          snmpAlarmTable       Configures sampling, threshold monitoring 
  138.                               and alarm generation for a specified managed 
  139.                               entity/variable
  140.  
  141.    o Issues:  (for debate)
  142.  
  143.  
  144.       1. Specifying destinations in snmpEventNotifyTable
  145.  
  146.          -  Currently done via contextId only as input to ACL search
  147.          -  Need QOS too?  Replace outright?  Not a problem?
  148.             --> This is a black-hole discussion.
  149.  
  150.       2. Fixes and improvements to snmpAlarmTable
  151.  
  152.          -  Unconstrain snmpAlarmStatus rules {58}
  153.             --> enable modification via single set-operation
  154.  
  155.          -  Add rateOfChange as well as (instead of) deltaValue {105}
  156.             --> avoids spurious alarms caused by delays in sample-taking
  157.  
  158.          -  Add consecutiveSamples metric to threshold configuration {60}
  159.             --> enables distinction between sustained and spurious alarms
  160.  
  161.          -  Add equalTo threshold comparison {61}
  162.             --> necessary for monitoring state variables, not just
  163.                 counters and gauges
  164.  
  165.          -  Add MIB expression thresholds {62}
  166.             --> necessary for monitoring derived statistics (i.e.,
  167.                 percent errors)
  168.  
  169.  
  170.    o Possible evolution of M2M-MIB:
  171.  
  172.       1. Support wild-card object instance specification in
  173.          snmpAlarmVariable
  174.          --> simplify/reduce configuration transactions and storage
  175.  
  176.       2. Maintain history of sampled data
  177.          --> enable standard configuration of distributed data collection
  178.              and trend services
  179.  
  180.       3. Steps towards more automated actions/control operations,
  181.          scripting
  182.          --> greater management by delegation
  183.  
  184.       4. Etc.
  185.  
  186.  
  187.    o Proposal:  Consolidated Alarm Table fixes/improvements
  188.  
  189.       -  Textual conventions:
  190.  
  191.          SnmpAlarmType ::= ENUM { absValue, deltaValue, rateValue }
  192.          SnmpAlarmComparison ::= ENUM { none, eq, ne, ge, gt, lt, le }
  193.  
  194.       -  SNMP Alarm Table { contextIdentity, snmpAlarmIndex }
  195.  
  196.           snmpAlarmVariable          r/c  InstancePointer
  197.           snmpAlarmInterval          r/c  Unsigned32
  198.           snmpAlarmSampleType        r/c  SnmpAlarmType
  199.           snmpAlarmSampledInterval   r/o  Unsigned32
  200.           snmpAlarmSampledValue      r/o  Integer32
  201.    
  202.           snmpAlarmExceptCompare     r/c  SnmpAlarmComparison
  203.           snmpAlarmExceptThreshold   r/c  Integer32
  204.           snmpAlarmExceptConsec      r/c  Unsigned32 (1..65535)
  205.           snmpAlarmExceptEventInde   r/c  Unsigned32
  206.    
  207.           snmpAlarmClearedCompare    r/c  SnmpAlarmComparison
  208.           snmpAlarmClearedThreshold  r/c  Integer32
  209.           snmpAlarmClearedConsec     r/c  Unsigned32
  210.           snmpAlarmClearedEventIndex r/c  Unsigned32
  211.  
  212.  
  213.    o Proposal:  M2M extension to support MIB Expressions
  214.  
  215.       -  Textual Conventions:
  216.  
  217.       SnmpExprVarType ::= ENUM { absValue, deltaValue, rateValue, constant } 
  218.       SnmpExprVarOp::= ENUM { add, sub, mult, div, mod, sqrt, sq, x2y }
  219.  
  220.       -  SNMP Expression Table { snmpExprIndex }
  221.  
  222.           snmpExprIndex     n/a  Unsigned32
  223.           snmpExprDescr     r/c  DisplayString
  224.           snmpExprPrecision r/c  Integer32
  225.           snmpExprStatus    r/c  RowStatus
  226.  
  227.       -  SNMP Expression Variable Table { snmpExprIndex, snmpExprVarIndex g
  228.  
  229.           snmpExprVarIndex    n/a  Unsigned32
  230.           snmpExprVarType     r/c  SnmpExprVarType
  231.           snmpExprVarVariable r/c  InstancePointer
  232.           snmpExprVarConstant r/c  Integer32
  233.           snmpExprVarOperator r/c  SnmpExprVarOp
  234.           snmpExprVarStatus   r/c  RowStatus
  235.  
  236.       -  Expression defined in post-fix notation, result truncated to
  237.          Integer32
  238.  
  239.       -  Used when snmpAlarmVariable points to entry in snmpExprTable
  240.  
  241.  
  242. David Levi's Presentation
  243.  
  244. Mid-Level Manager MIB and SNMP Script Language
  245.  
  246.  
  247.    o History
  248.       -  Language designed for XNETMON o/a late 1992
  249.  
  250.       -  Customers requested language without GUI o/a mid 1993
  251.          Created Mid-Level Manager (MLM)
  252.  
  253.       -  Customers requested a GUI to help configure MLM o/a early 1994
  254.          Created Mid-Level Manager Config Tool
  255.  
  256.    o Goals
  257.       -  Ease burden of management stations
  258.       -  Reduce/localize network traffic
  259.       -  Expand domain of manageable devices
  260.       -  Automatic corrective behaviors
  261.  
  262.    o Architecture
  263.       -  Showed BRASS server (a thing that consolidates SNMP traffic)
  264.       -  MLM implemented as Emanate subagent
  265.       -  Can run on same processor or on agent or other
  266.       -  Can have multiple MLMs talk with each other
  267.  
  268.    o MLM MIB (see Internet-Draft, draft-levi-snmp-mid-level-mgr)
  269.  
  270.      Three tables:
  271.  
  272.       -  mlmScriptTable
  273.  
  274.           * mlmScriptTable used to upload/download scripts between the
  275.             MLM and manager, e.g., the MLM Config Tool.  Scripts are
  276.             stored as Octet Strings
  277.  
  278.       -  mlmCompileTable
  279.  
  280.           * mlmCompileTable used for configuring and running scripts
  281.               +can contain filename of script or pointer to
  282.                mlmScriptTable
  283.               +can specify arguments to pass to a script
  284.               +can specify frequency to run script periodically
  285.               +can command script to be run once
  286.  
  287.       -  mlmResultTable used to make result of running script available
  288.          in MIB variables
  289.  
  290.           * scripts return varbind lists
  291.           * result table contains encoding of varbind lists:
  292.             mlmResultOID
  293.             mlmResultType
  294.             mlmIntegerValue
  295.             mlmOctetStringValue
  296.             etc.
  297.  
  298.  
  299.    o Script Language
  300.       -  All variables are varbind lists
  301.       -  Basic control structures (if, while)
  302.       -  Various logical/mathematical operators
  303.       -  Language can be extended by registering C functions with script
  304.          library
  305.       -  Scripts run asynchronously
  306.  
  307.    o Basic Script Capabilities
  308.       -  SNMP operations (get, set, etc.), result assigned to script
  309.          variable
  310.       -  Send trap or M2M inform request
  311.       -  Log data to a file
  312.       -  Fork, call, or jump to another script
  313.       -  Launch another application
  314.    
  315.    o Experience
  316.      Have written many MLM applications, for example:
  317.  
  318.       -  Intruder detection script
  319.           * uses RMON to capture source address of packet
  320.           * script checks if packets are from a ``trusted'' device
  321.           * if not, script issues a warning (could be a set request,
  322.             send e-mail, etc.)
  323.  
  324.       -  Audio counter-attack script
  325.           * monitors audio MIB for noise level
  326.           * if level is above threshold, turn on UPS with set
  327.           * if level stays above threshold, do set to play back the
  328.             noise
  329.  
  330.       -  M2M-like scripts
  331.           * retrieves several MIB variables, possibly from several
  332.             agents
  333.           * combines the variables using a mathematical expression
  334.           * if a threshold is crossed, send an inform request
  335.  
  336.  
  337.    o Future Directions
  338.       -  MLM MIB
  339.          separate mlmCompileTable into an ``available scripts'' table
  340.          and a ``script execution'' table
  341.  
  342.       -  Explore alternative means for NMS applications to get results
  343.          from MLM
  344.  
  345.       -  Define useful extensions to script language
  346.  
  347.       -  Harmonization between script language and snmp-tcl.
  348.  
  349.  
  350. David was asked if he had any feel for resource consumption.  He said
  351. that scripts are stored in tokenized format, compiled once received, and
  352. can use as much resources as you want.  Jeff Case commented that it has
  353. been implemented in ROM-based systems.  Most of the time they tend to be
  354. blocked waiting for an event or timer, so they are not
  355. resource-consumptive at that point.
  356.  
  357. Someone asked how specific is MIB to language?  Could MIB be used for
  358. snmp-tcl?  There are some detail problems, some MIB pieces are specific,
  359. but overall it would be possible with a few changes.
  360.  
  361. Steve Waldbusser commented that it could have a script stored so that
  362. you push a button and it runs.  For example, this could be done as a
  363. side-effect of a get request.
  364.  
  365.  
  366. Karl Auerbach's Presentation
  367.  
  368. Karl thinks the previous approach is reasonable, but not useful for
  369. building real management.  The premise is area managers are needed close
  370. to what we want to manage.  He sees RMON scripts as impractical for area
  371. managers.  Karl suggests a totally different approach.  How do we put
  372. control out in the network efficiently and securely?  A box runs in a
  373. multi-threaded environment with scheme manipulators, e.g., for SNMP,
  374. ping, etc.  S-exprs return information to area manager.
  375.  
  376.  
  377.    o Primitives
  378.  
  379.       -  Bit-twiddling too low-level
  380.       -  Association protocol ``transport-agile'' could be used for UDP,
  381.          dial-up, etc.
  382.       -  Self-delimiting, ASCII text
  383.       -  Program sends back response programs
  384.       -  Need way for manager to find out what is running and cancel
  385.       -  Manager trusts agent:  checks periodically for reachability,
  386.          does traceroute if loses connection
  387.       -  Script trust -- formal prof too expensive
  388.  
  389.  
  390.    o Useful primitives and operators
  391.  
  392.       -  List of addresses (who is out there)
  393.       -  Misconfigured IP subnet masks
  394.       -  MTU, traceroute, ICMP path discovery
  395.       -  Novellish stuff
  396.  
  397.  
  398. Jeff Case wanted to know what the difference is between this and Levi's
  399. proposal?  Primitive?  Security?  Parallelism?  Flexibility?  Marshall
  400. Rose believes both speakers agree in value of remote execution
  401. environment, programmable entity.  Differences revolve around
  402. functionality (primitives).  Also Levi proposes SNMP as the transport
  403. mechanism; Karl did not want to be limited by SNMP as transport.
  404.  
  405.  
  406. Yechiam Yemini's Presentation
  407.  
  408. Distributed Management by Delegation (MBD)
  409.  
  410.  
  411.    o Current Management:  centralized and labor intensive
  412.       -  Plugging in a network device is not as simple as plugging in a
  413.          stereo
  414.       -  Must always go from centralized administrator to each end
  415.          device
  416.       -  Trained people are expensive and hard to find
  417.       -  Expects vendor that created MIB to also build applications to
  418.          manage it but vendor may not have the resources to do this,
  419.          especially on multiple platforms
  420.       -  Want to eliminate labor intensive function from management
  421.       -  Replace people with programs that run in the network
  422.       -  As elements become more complex, boundaries between control of
  423.          device and management blur (e.g., ATM virtual circuit)
  424.  
  425.    o Goal:  automated embedded management
  426.       -  Localize control loops, automate functions
  427.       -  Developed at Columbia University in 1988 and licensed by
  428.          several sites
  429.  
  430.    o Operation
  431.       -  ``Software backplane'' inserted into devices in network
  432.       -  Can plug functions into backplane
  433.       -  Download, execute under local or remote control
  434.       -  Move programs to data, focus on manager function deployment
  435.       -  Distinguishing feature:  language independent, delegate
  436.          compiled C, C++, interpreted TCL
  437.       -  OS independent (has a portable thread package)
  438.  
  439.    o Applications
  440.       -  Delegate
  441.           * policy scripts to automate domain management
  442.           * new protocol interface (CORBA access to MIB data)
  443.           * config language interpreter and then config.  scripts
  444.       -  End-user can leverage a small team of expert staff to manage a
  445.          large network.
  446.       -  Defined a MIB view language, allows you to define views on a
  447.          MIB, creates virtual table, SNMP + (expressive power > CMIP)
  448.  
  449.    o Notes/Status
  450.       -  not a product but an infrastructure
  451.       -  code is available to play with
  452.  
  453.  
  454. Steve Waldbusser asked what would be standardized?  Yechiam Yemini
  455. responded:  not new language or transport protocol; URL to access
  456. program; protocol for remote control; inter-process communications,
  457. threads.
  458.  
  459. Jeff Case noted that 67k is needed just for delegation services.  He
  460. asked where is C compiler?  -- not in VxWorks!
  461.  
  462. Dave Perkins asked how do you get results back from programs, scripts?
  463. Occam's razor -- build only what is there:  SNMP MIB, RPC, CORBA, etc.
  464.  
  465.  
  466.  
  467. Discussion
  468.  
  469.    o Marshall Rose warned to watch out for stereo analogy -- most folks
  470.      cannot set their VCR clocks.
  471.       -  Observes general agreement concerning remote
  472.          execution/delegation
  473.       -  Questions are
  474.           * transport to remote
  475.           * protocols, security, etc.
  476.           * response, etc.
  477.       -  Back to reality:  this is a standards activity
  478.           * originally network management used UDP datagram -- fetch
  479.             value/set value -- but hardware specific
  480.           * interoperability requires specific semantics, which is where
  481.             we get MIBs
  482.           * if this group undertakes standardization, it must define:
  483.  
  484.               +transport mechanism
  485.               +language
  486.               +threads, IPCs, etc.
  487.               +data structures
  488.               +extensions, e.g., ping, traceroute
  489.  
  490.    o Karl Auerbach asked where can we start -- do something simple but
  491.      useful?  Number one is expressions that combine existing MIB
  492.      variables.
  493.  
  494.    o Greg Bruell commented that Bay Networks has a homegrown scripting
  495.      language that has been used for about six months.  It can download
  496.      programs; get results in octet strings.
  497.  
  498.    o Maria Greene has used TCL scripts and feels it would be good to
  499.      standardize.
  500.       -  But in addition can we define scripts?
  501.       -  Could develop/define RMON using this capability (e.g., monitor
  502.          threshold/traps)
  503.       -  Should working group charter include repository of scripted
  504.          applications?
  505.  
  506.    o Someone suggested collecting information in a file -- use FTP or
  507.      something to get the file.
  508.  
  509.    o Bob Stewart agreed and commented that history table is also a good
  510.      idea.
  511.  
  512.    o Jeff Case suggested that the group:
  513.  
  514.       1. Fix/modestly enhance M2M in short time; stay safe, get it done
  515.          as soon as possible
  516.       2. If you want something more aggressive, then agree on a model,
  517.          define execution environment, data structures, and primitives
  518.  
  519.      Later, consider scripts.  The easiest part is probably the
  520.      transport.
  521.  
  522.  
  523. Summary
  524.  
  525. Bob asked for consensus:
  526.  
  527.  
  528.    o M2M fix -- a big yes
  529.    o Adding programmability to SNMP -- also strongly supported
  530.  
  531.  
  532. Bob will talk to Dierdre to set up a working group, get a charter under
  533. way, and set up a mailing list.
  534.  
  535.