home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ifmib / ifmib-minutes-95dec.txt < prev    next >
Text File  |  1996-06-03  |  9KB  |  235 lines
  1. CURRENT MEETING REPORT
  2.  
  3. Reported by  
  4. Dallas Dec 8 1995
  5.  
  6. Minutes of the meeting:
  7. which combine the agenda,
  8. new issues, and the resolution of issues.
  9.  
  10. Draft discussed: draft-ietf-ifmib-mib-01.txt.
  11.  
  12. -Provide an online home for the IANAifType module.
  13.  Currently isi has an ftp and a web server. See this URL
  14.  http://www.isi.edu/in-notes/iana/assignments/smi-numbers/
  15.  I received initial feedback from Joyce Reynolds that hosting
  16.  the IANAifType module was possible.
  17.  One possible issue is the traffic level expected by ISI.
  18. Action
  19.  A web server is a good thing.  Traffic should not be a problem.
  20.  Manager stations will not download a MIB module when booting up;
  21.  vendors will download it, and send it with software releases.
  22.  The wg chair will contact ISI and establish a location for
  23.  the IANAifType mib module.
  24.  
  25. The following are Textual Clarification Issues.
  26.  This issues were brought up in Stockholm and text
  27.  has been added to the draft to satisfy the need.
  28.  
  29. -ifIndex > ifNumber will break some apps.
  30.  Admitted on pg.13
  31.  
  32. -reuse ifTable OIDs
  33.  Justified on pg.13
  34.  
  35. -always have explicit top and bottom ifStack layers
  36.  Explained on pg.43
  37.  
  38. -ifName
  39.  Usage explained on pg.37
  40.  
  41. -noSuchInstance before columns are known
  42.  Usage required on pg.23
  43.  
  44. -ifIndex unique in context
  45.  Explained on pg.14
  46. Action
  47.  The Working Group chair will ensure that the draft reflects
  48.  the best phrase for "community/context"
  49.  in the current SNMP standards environment.
  50.  
  51. -A spelling question arose. Is "instanciated" the british
  52.  spelling of "instantiated"?
  53.  
  54. The following are changes to the definition of objects,
  55.  and reflect decisions that were made in Stockholm.
  56.  
  57. -ifStackTable was made read/create.
  58.  See pg.44
  59. Action
  60.  The text should capture why the ifTable should NOT be made
  61.  read/create.  (1) There may be more information needed to create
  62.  an interface than contained in ifTable.  Therefor the appropriate
  63.  place to create a row is in the Media Specific Mib, where
  64.  such information is known.  (2) In some situations the agent
  65.  should choose the value for ifIndex, rather than the manager.
  66.  
  67. -ifTestTable deprecated
  68.  See pg.54
  69.  Also see further discussion of the ifTestTable below.
  70.  
  71. The following are objects added to the mib,
  72.  and reflect decisions that were made in Stockholm.
  73.  
  74. -ifTableLastChange aka the "all bets are off" object
  75.  Defined on pg.28
  76.  Indicates that the ifTable has changed, but doesn't
  77.  indicate how many additions or deletions.  Thus the
  78.  management station must re-load the entire table.
  79.  
  80. -ifStackLastChange aka yet another "all bets are off" object
  81.  Defined on pg.45
  82. Action
  83.  Why is this object on each row? Seems like it should be
  84.  used the same as ifTableLastChange, where a new value
  85.  indicates the management station must re-load the table.
  86.  Wg chair will talk to the editor about intent of the object,
  87.  and report back to wg.
  88.  
  89. -ifAlias
  90.  Defined on pg.42
  91.  Editor's proposal that ifAlias become "the if handle"
  92.   +NMS puts handle there
  93.   +handle stays with the ifIndex
  94.   +persistant across reboots
  95.   +have limit on memory usage
  96.  Policy issue as to what is persistant across reboots/hot-swaps/brain-swaps.
  97.  Note- The "Cisco Summit" yielded no technical solution.  Its policy.
  98.  
  99.  Both in Stockholm and in Dallas, this object was much discussed.
  100.  
  101.  It was established that most management station implementors (present)
  102.  do not need to assume ifIndex remain consistant across reboots,
  103.  and can/will deal with the reload/reindex.  An operator observed that
  104.  they commonly do box swaps and no re-indexing by a box can avoid
  105.  management station renumbering. Similarly with controller card swap
  106.  on a box.
  107.  
  108.  There are three "levels" of interface naming going on here:
  109.  (1) logging/stats at the management station,
  110.  (2) the ifIndex number,
  111.  (3) the physical card/port if present.
  112.  There needs to be a mapping between each level.  Consistancy between
  113.  the logging level and ifIndex is handled by the management station,
  114.  whereas mapping between ifIndex and the physical card/port should
  115.  be on the agent.
  116.  
  117.  It was agreed that the Entity Mib, not the Interfaces Mib,
  118.  should provide the ifindex to physical mapping capability:
  119.  (a previous draft of) the Entity Mib had an ifIndex to physical port
  120.  mapping table.  This is quite useful for interfaces for which the
  121.  ifConnectorPresent object is positive, and shouldn't be there otherwise.
  122. Action
  123.  The WG chair will send a note to the Entity Mib expressing a desire for
  124.  this functionality, and a pointer to the interface mib describing its use.
  125.  (Note that Andy Bierman, an entity mib editor, attended this ifmib meeting.)
  126.  
  127. Action
  128.  The ifmib should clarify what sorts of information to put into
  129.  ifAlias as compared to ifName and ifDescr.
  130.  
  131.  The wg felt that the text on agent space limitations on the length
  132.  of ifAlias were sufficient, that more mechanistic specifications
  133.  were not useful.
  134.  
  135.  The wg did feel that there was sufficient utility in this
  136.  object to warrent its inclusion in the Mib, knowing that it
  137.  incurs an NVRAM cost.
  138.  
  139.  
  140. Issues from the List that were discussed
  141. and resolved.
  142.  
  143. -A new state for ifOper/ifAdmin had been suggested: downBecauseDependency.
  144.  It is intended to flag configuration issues, while
  145.  dormant implies waiting for work.
  146. Action
  147.  We do not need this object, but we do need to specify how a lower layer
  148.  interface's state percolates up to upper layer interfaces.
  149.  Craft language something like this:  "For an interface,
  150.  While all lower interfaces are either down, unknown, testing,
  151.  it is down.
  152.  While all other lower interfaces are either down, unknown, testing,
  153.  if at least one lower interface is dormant, it is dormant.
  154.  While all other lower interfaces are either down, unknown, testing or dormant,
  155.  if at least one lower interface is up, it is up.
  156.  
  157. -A new state called "notPresent" was suggested.
  158.  It indicates that a card/port which had been located in that spot
  159.  has been removed. It is vendor specific as to whether
  160.  (a) the counter etc resources are reclaimed immediately, and the
  161.  values are lost, in which case the agent immediately "transitions"
  162.  the interface through the notPresent state and removes the row, or
  163.  (b) the counter etc resources are reclaimed at a later time,
  164.  and the values retained for that period of time, and made available
  165.  to management stations.  After that time, the interface "transitions"
  166.  to non-existance.  The duration of time is vendor specific.
  167.  
  168.  The meaning of the notPresent state percolates up as follows:
  169.  While all lower interfaces are either down, unknown, testing, or notPresent
  170.  it is down.
  171.  
  172. -The 100VG initialization/training state is not quite testing,
  173.  yet section 3.1.12 enumeration 5, page 21
  174.  suggests it should be considered testing.
  175.  A state characterization of testing would yeild many traps
  176.  as the interface goes through its initialization.
  177. Action
  178.  Want to call such initialization states down.
  179.  Need to revise the text to support this interpretation.
  180.  
  181. -ifName usage.
  182.  Some proxy systems used in large WAN switches could benefit
  183.  from specifying a routing string on a per interface basis.
  184.  If they could, the ifName is the appropriate place to put
  185.  this string.
  186. Action
  187.  Dave Fowler of newbridge will supply text to this effect.
  188.  
  189. -The ifStackTable is implementable if have
  190.  embedded system, single developer, source code knowlege/control.
  191.  No implementation experience from open systems
  192.  with 3rd party developers.  Furthermore not all
  193.  proxy agent implementations/architectures have sufficient
  194.  visibility to support the ifStackTable.
  195.  
  196.  While the WG has sympathy for the implemention problems
  197.  of open platforms it feels that the ifStackTable has real utility.
  198.  While the WG acknowleges this utility is most needed on "WAN boxes"
  199.  it felt this utility overrides implementation problems on certain
  200.  platforms.  There is precedent for this.
  201.  At other times the implementation difficulties of eg UNIX
  202.  were not deemed sufficient to quash an object of demonstrable utility.
  203.  
  204. Action
  205.  The ifStackTable is manditory.
  206.  If an implementation cannot determine the ifStackTable internally,
  207.  it must not fake it, by returning a misleading table which indicates
  208.  no stacking or something else inaccurate.  This was considered akin
  209.  to returning a count of zero when the counter is not implemented. 
  210.  Text forbidding this usage shall be added to the draft.
  211.  
  212.  The wg also wants to send a request to the Agentx wg that the
  213.  capability to support the ifStackTable in a proxy agent environment
  214.  be a requirement of the extensible agent design.
  215.  
  216. -Kaj's ifTestTable
  217.  The Atom mib wg is developing tests. It would like a standard
  218.  way of defining them.
  219.  
  220.  The wg felt that it would be good to incorporate tests that included
  221.  elements other than the interface, eg system self test.
  222.  
  223. Action
  224.  A new work item is spun off.  The Test table will
  225.  be a separate document.  If it is successful,
  226.  its first stop will be proposed standard.
  227.  Its task is to distill a general set of test functions
  228.  that are applicable across various media, and general systems.
  229.  This will allow mibs to specify code points only, not mechanims.
  230.  It is the job of the design team use good judgement as to whether
  231.  multiple simultaneous tests on an interface is worth
  232.  the implementation complexity it entails.
  233.  It is also their job to decide whether a "single table" or "dual table"
  234.  approach is preferable.
  235.