home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ifmib / ifmib-minutes-95jul.txt < prev    next >
Text File  |  1995-10-18  |  13KB  |  294 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Ted Brunner/Tektronix
  5.  
  6. Minutes of the Interfaces MIB Working Group (IFMIB)
  7.  
  8.  
  9.  
  10. First Meeting
  11.  
  12. The first meeting of the IFMIB Working Group was held on Tuesday,
  13. 18 July.
  14.  
  15. Implementation experience:  Bay Networks, Lannet and Chipcom either do
  16. not yet have implementation experience or it is on their plate.  Proteon
  17. will report back later.
  18.  
  19.        _________________________________________________________
  20.        |              |    1      |      2       |  Newbridge   |
  21.        |              | router?   |  atm switch  |  FR switch   |
  22.        |______________|___________|______________|______________|
  23.        | ifTable      |   yes     |     yes      |     yes      |
  24.        | ifXTable     |   yes     |     yes      |     yes      |
  25.        | 64bit        |   yes     |     N/A      |     N/A      |
  26.        | ifStack      |   yes     |     yes      |     yes      |
  27.        | ifRcvAddr    |   yes     |     N/A      |     N/A      |
  28.        | ifTest       |   N/A     |     N/A      |     N/A      |
  29.        | linkup/down  |           |     yes      |     yes      |
  30.        |______________|___________|______________|______________|
  31.  
  32.  
  33. The following problems were reported in using the specification to
  34. implement RFC 1573:
  35.  
  36.  
  37.    o Some typographical errors, e.g., import counter64.
  38.  
  39.    o Better text is needed about sparse tables.
  40.  
  41.    o More examples and text is needed to explain the allocation of
  42.      ifIndex values under error and reboot conditions.
  43.  
  44.    o When a certain case is intended to be disallowed, it is important
  45.      to document that rather than having the text silent.
  46.  
  47.  
  48. Issues Discussed
  49.  
  50.    o Certain NMS platforms and applications expecting RFC 1213 semantics
  51.      break with RFC 1573.  Third party apps may break, e.g., allocates
  52.      array for interfaces based on ifNumber.  ifIndex > ifNumber indexes
  53.      out of array.  Some cannot handle sparse ifTable, i.e., blanks
  54.      between ifIndex values.  A version of OpenView for Windows will
  55.      break.  But it has a bug which is expected to be fixed.
  56.  
  57.      Decision:  This cannot be helped.  Tell applications developers to
  58.      read RFC 1573.  Admit that it will break some applications.
  59.  
  60.    o IANAifType values have been added to since RFC 1573 was issued.
  61.      This was intent.  It was expected that IANA would provide not just
  62.      numbers but an ASN.1 module in a easily accessible repository.  It
  63.      was the intent that the new interfaces document would not have
  64.      IANAiftype module in it.
  65.  
  66.      Decision:  Ascertain if IANAifType module is available, and if IANA
  67.      will make it available at a repository (e.g., venera.isi.edu).  If
  68.      so, that module will not go into the new document.  Provide better
  69.      text in the new document for finding module.  First try FTP site;
  70.      second, ask IANA; third, try mailing list for clarification.
  71.  
  72.    o Reuse of OIDs between RFC 1213 and RFC 1573.
  73.  
  74.      Decision:  Further document in 3.2.1 the decision to reuse ifTable
  75.      OIDs.  Admit it is not optimal.  Admit it breaks some NMS
  76.      applications.  State the choice to deprecate ifTable affects all
  77.      existing agents.
  78.  
  79.      Decision:  There are ad hoc methods to distinguish RFC 1213 and
  80.      RFC 1573 agents.  Need not document these.
  81.  
  82.    o Under what conditions does the ifIndex value get reused?  Example:
  83.      Large switch has ports which get reset either by intervention or in
  84.      reboot.  The counter values held on the port are zeroed.  But
  85.      ifTable counters must not decrease.  If agent kept counters instead
  86.      of swapped out card this is not a problem.  Could maintain offset
  87.      on agent, and add it to a port's counter value, but then the port
  88.      holds different counter values than agent returns.  Could assign
  89.      new ifIndex to the port.
  90.  
  91.      RFC 1573 says a new ifIndex value should be assigned to avoid a
  92.      discontinuity in interface table counters.  RFC 1573 and RFC 1213
  93.      state there is no persistence of if numbering across reboots.
  94.  
  95.      Proposed:  A read-only object (TimeTicks) indicating the sysTime
  96.      after which interface counters are valid.  If counters were zeroed
  97.      by human intervention or hot swapping cards, this object tells when
  98.      it happened.
  99.  
  100.      Pro:  Clean description.
  101.  
  102.      Con:  Need to deprecate existing counters.  Need to read timestamp
  103.      whenever read counter.  Intervention will ``blow away'' other NM
  104.      apps reading counters.  Some customers seem willing to, but are
  105.      there more who would not?
  106.  
  107.      Straw poll taken between keeping existing model, and changing to
  108.      new one.  Some support for new model.  Greater support shown for
  109.      keeping existing model.
  110.  
  111.      Decision:  Suspend discussion of new proposal, resurrect only if
  112.      there is new input.  Clarify text of existing model.  Consider it
  113.      on the list.  Make final judgement then.
  114.  
  115.    o The ifStackTable may or may not have explicit top and bottom
  116.      layers.  While stack is changing, could get ambiguous results with
  117.      implied layering.
  118.  
  119.      Decision:  Always have explicit top and bottom layers, e.g.,
  120.      ifType.1=ethernetCsmacd, ifStackStatus.0.1=active, and
  121.      ifStackStatus.1.0=active.
  122.  
  123.    o ifName text is confusing in case of vertical stack of interfaces.
  124.      Decision:  Provide example in text of case where ifName is not the
  125.      same for all interfaces in a vertical stack.
  126.  
  127.    o ifStackTable is organized from top to bottom.  Bottom to top
  128.      organization is more intuitive in some cases.  Agent may organize
  129.      itself bottom to top.  But agent needs to know entire stack so
  130.      cannot avoid constructing it.  Manager needs to load entire
  131.      ifStackTable to make sense of interfaces, so bottom to top table
  132.      would need entire load.
  133.  
  134.      Decision:  Do not add bottom to top stackTable.
  135.  
  136.    o ifStackTable can be large, and loading whole thing to ascertain
  137.      where there is an interface change can be painful.  Proposed:  an
  138.      indicator of change in stack table, with pointer to where.  But may
  139.      be several changes so manager cannot avoid loading rest of table.
  140.      (Another one of several possible granularities for indicator is for
  141.      stackTable as a whole.)
  142.  
  143.      Decision:  Do not see sufficient improvement to warrant new
  144.      objects.
  145.  
  146.    o Bridge MIB interactions with RFC 1573.  Decision:  No necessary
  147.      changes to bridge MIB seen by existence of RFC 1573.
  148.  
  149.    o Entity MIB interactions with RFC 1573.  Decision:  No necessary
  150.      changes to Entity MIB seen by existence of RFC 1573.
  151.  
  152.    o A configured probe in RMON uses a ``data source OID'' to indicate
  153.      where data is to be obtained.  It points to an ifIndex.  But nv
  154.      needs to contain more expressive notion of source that can be
  155.      re-pointed if ifIndex value changes.  Also, data taken by a probe
  156.      is with reference to an ifIndex.  After renumbering, this data is
  157.      obsolete.  But this is the proper behavior when an interface goes
  158.      away.
  159.  
  160.      Decision:  There are implied problems for RMON because ifIndex does
  161.      not have a persistence.  But this is understood by RMON Working
  162.      Group.
  163.  
  164.    o Various typographical errors concerning ifNumber conformance
  165.      statement and ifRecvAddrStatus read/create and ifRecvAddrAddress.
  166.      Decision:  Keith understands the edits.
  167.  
  168.  
  169.  
  170. Second Meeting
  171.  
  172.  
  173. The second meeting of the IFMIB Working Group was held on Thursday,
  174. 30 July.
  175.  
  176.  
  177.    o Currently ifType numbers are being assigned by IANA at request of
  178.      (at least) the RFC 1573 editor.  There is an IANA Web page of
  179.      assigned numbers.
  180.  
  181.      There is no MIB module.  Joyce Reynolds received heads up about the
  182.      working group's desire for an appropriate posting of our MIB
  183.      module.
  184.  
  185.      Decision:  The working group chair has an action item to settle
  186.      disposition of IANAifTypes.
  187.  
  188.    o ifMTU and other columns.  For some interfaces (e.g., LANE client),
  189.      these values are unknown by the agent at time of row creation.
  190.      Decision:  such objects are only instantiated once values are
  191.      known, return noSuchInstance prior to that.
  192.  
  193.    o ifIndex values are unique within a context.  But are they unique
  194.      across contexts?  Decision:  There is no required correlation of
  195.      ifIndex values between Entities.  E.g., <ifIndex=1 Entity=1> can be
  196.      different than <ifIndex=1 Entity=2>.  Supply text to that effect.
  197.  
  198.    o Seeking a unique handle for an interface which is constant across
  199.      reboots.  ifIndex is unique handle, but is not constant across
  200.      reboots.
  201.  
  202.      Is the tuple <ifName ifType> unique?  No.  Some interfaces do not
  203.      have ifName initially (e.g., LANE). The definition of ifName says
  204.      there can be vertical stacks of interfaces all with the same name.
  205.      Also, load balancing interfaces would naturally have the same
  206.      ifName.  The definition of ifName states that a zero length string
  207.      is sometimes an appropriate value.
  208.  
  209.      There is an overloading in the assignment of ifName:  algorithmic
  210.      derivation by agent, meaningful name, unique, and possibly
  211.      consistent across reboots.  This does not work.
  212.  
  213.      More fundamentally, how long must consistency be maintained?
  214.      RFC 1573 says between reboots.  We are looking at a longer period.
  215.      How long?  Can ifIndex=1 (for instance) ever be reused then?
  216.  
  217.      Decision:  Do we have a constant handle for an interface?  No.  Can
  218.      we find one?  Unknown.
  219.  
  220.    o ifAlias was proposed as a r/w object holding key information on the
  221.      agent to be shared between NMSs and configuration UIs on the agent.
  222.      Example of key use is a circuit number on a D1, phoned to site by
  223.      Telco.  Size depends on country.  32 digits is sometimes a problem.
  224.      64 are OK so far.  All proprietary MIBs have such an object --
  225.      sometimes it is used to keep notes.  ifAlias should be kept in nv
  226.      memory.  Size of the nv requirements is a problem.  Perhaps only
  227.      needed by physical links; perhaps a memory pool limit per box is
  228.      acceptable.  Could leave such function to media-specific MIB.
  229.  
  230.      Decision:  Full discussion was cut short.  The group feels this is
  231.      a useful object.  Seems that generic function in interfaces is
  232.      right place.  Conformance statement should be crafted to limit its
  233.      nv requirements.
  234.  
  235.    o ifScratchpad was proposed as a r/w object holding other information
  236.      on the agent.  Decision:  Insufficient support.
  237.  
  238.    o Are there any needs from DS1 MIB rewrite we need to consider?
  239.      Conformance categories seem sufficient:  ifGeneral and ifStack.
  240.  
  241.    o Are there any needs from character MIB rewrite we need to consider?
  242.      RS232 and Parallel port are considered interfaces.  A character
  243.      stream is not considered a network interface.
  244.  
  245.    o We have no algorithm for determining what is a network interface,
  246.      each media-specific MIB working group decides itself.  Decision:
  247.      Leave decision to media-specific working group.
  248.  
  249.    o notPresent value for interface ifOperStatus?  How will NMS behave
  250.      differently than if this were ``down''?
  251.  
  252.    o Currently ifEntry has max-access read-only while ifStackTable has
  253.      max-access read/write.  ifStack access seems broken.  Editor feels
  254.      the r/w was a typographic error.  Could set ifStackTable max-access
  255.      to Read/Create or read-only.  Three examples where create is
  256.      useful:  LANE, PPP, DS1 Fractional.
  257.  
  258.      Decision:  ifStackTable has max-access of read/create.
  259.  
  260.    o ifTableLastChange proposed to aid NMS in determining whether a
  261.      change between reboots.  Flagged when an ifTable row added or
  262.      deleted.  Perhaps unneeded with M2M notifies or linkup/down traps.
  263.      But these are not reliable.  Decision:  Add it.
  264.  
  265.    o ifStackLastChange proposed to aid NMS in determining whether a
  266.      change between reboots.  Flagged when an ifStack row added or
  267.      deleted (synonymous with change in rowstatus) Decision:  Add it.
  268.  
  269.    o Read/Write access for ifPhysAddress?  Useful for X.25, decnet-style
  270.      addresses, some ethernet cards.  Decision:  Use ifRecvAddr which is
  271.      read/create now.  Assume you can send with a source address taken
  272.      from ifRecvAddrTable.
  273.  
  274.    o If repeaterports are considered interfaces, are there any
  275.      repercussions we need to consider?  Decision:  Need working group
  276.      feedback.  It does not currently have an interface model.
  277.  
  278.    o TimeStampObject for test result?  Support for simultaneous tests on
  279.      the same interface?  The ifTestTable has no implementation
  280.      experience to show.  The AToMMIB Working Group an imagine uses for
  281.      multiple simultaneous tests.  ifTestTable constrained to one test
  282.      per interface.  It has its roots in the old EtherExtensions MIB.
  283.  
  284.      Decision:  Delete the ifTestTable.  Consider a generic Test MIB
  285.      separate from the interfaces MIB.
  286.  
  287.  
  288. Issues Not Considered
  289.  
  290.    o Interface pre-configuration.
  291.    o Use temporal domain = next reboot?
  292.    o More information when receive ifType = other.
  293.  
  294.