home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rmonmib / rmonmib-minutes-97apr.txt < prev   
Encoding:
Text File  |  1997-05-29  |  14.1 KB  |  347 lines
  1. Editor's Note:  These minutes have not been edited.
  2.  
  3. Minutes - IETF #38  Memphis, TN
  4. --------------------------------
  5.  
  6. WG:        RMONMIB
  7. Area:      OPS
  8. Meetings:  8apr97  0900-1130
  9.            9apr97  1015-1115
  10. Minutes:   Andy Bierman  (WG Chair)
  11.  
  12. Summary
  13. -------
  14.  
  15. The goal of the Memphis meeting was the resolution of all issues,
  16. (to the greatest degree possible) related to current WG development.
  17.  
  18. The following I-Ds and all WG email since the last meeting were 
  19. discussed:
  20.    draft-ietf-rmonmib-rmonprot-v2-00.txt  (ID-1)
  21.    draft-waterman-rmonmib-smon-00.txt     (ID-2)
  22.    draft-ietf-rmonmib-hcrmon-00.txt       (ID-3)
  23.  
  24. All issues were resolved, at least in principle.  Some features
  25. are not documented yet in WG Internet Drafts, so actual resolution 
  26. is pending such publication.  The WG believes completed documents can be
  27. submitted to the IESG by August 1997.
  28.  
  29. Deliverables: 3 documents
  30.    The WG agreed to maintain the current document structure. The WG I-D
  31.    version of ID-2 will reflect the scope agreed upon at the meeting..
  32.    The title is not clear yet, but 'Switch Extensions for RMON'
  33.    may be appropriate.
  34.  
  35. Detailed Agenda Resolution
  36. --------------------------
  37.  
  38. The following functional components were discussed during the meetings.
  39. Individual resolutions represent WG consensus, but are subject to 
  40. mailing list objection.  This is a very detailed account, since
  41. every aspect of the work-in-progress was affected by WG decisions
  42. made at this meeting.  These minutes also serve as editing instructions 
  43. for the authors of the I-Ds listed above.
  44.  
  45. A: Protocol Directory
  46. A.1: review and update ID-1
  47. A.2: Protocol macro parsers
  48.  
  49.    No new macros have been posted to the mailing list since the last 
  50.    meeting.  The WG concluded this method of document completion was 
  51.    not working,  and it was up to the document authors to work amongst 
  52.    themselves to complete the Protocol Identifiers (V2) I-D.
  53.  
  54.    Action Item(Editors ID-1):
  55.    A new version of ID-1 is expected in one month, with new PI macros, 
  56.    the RFC 2074 edits, and sub-section headings within the PI section
  57.    removed.  An off-line phone conference will be planned to discuss
  58.    potential work assignments.
  59.  
  60. B: 64-bit counters
  61. B.1: scope of 64-bit support
  62. B.2: SNMPv1 and SNMPv2C support
  63. B.3: MIB Logistics -- Table format
  64.  
  65.    The High Capacity RMON MIB (ID-3) and all related WG email
  66.    was discussed in detail:
  67.      * too much boiler-plate -- some introduction text is copied from
  68.        the RMON-2 MIB.
  69.  
  70.        Action Item(Editor ID-3):
  71.        Left up to the Editor for change.  Text must remain 
  72.        consistent with version in RFC 2021.
  73.  
  74.      * 'SPARSE-AUGMENTS' needed instead of real AUGMENTS to
  75.        allow for a probe with only some interfaces requiring 64-bit
  76.        counters.  The WG concluded that instantiating all columns in
  77.        all rows would not be a burden on agents, and would make table
  78.        retrieval easier for NMS applications.
  79.  
  80.        Action Item(Editor ID-3):
  81.        None -- AUGMENTS clause remains.  Consider adding text explaining
  82.        that the agent must instantiate all columns for all
  83.        configured rows in the augmented table, if any columns 
  84.        are needed out of this table.  Add rules for mapping
  85.        the 32-bit counter to these filler-columns.
  86.  
  87.      * keep ID-2 and ID-3 separate.
  88.  
  89.        Action Item(Editor ID-3):
  90.        Remove reference to switch-based RMON instrumentation.
  91.        This functionality to be moved to WG version of ID-2.
  92.  
  93.      * more Counter64 support.
  94.        The WG wants all etherStats packet-based counters to have 64-bit 
  95.        versions, as well as all appropriate topN and usrHistory tables.
  96.  
  97.        Action Item(Editor ID-3):
  98.        Add missing etherStats extensions. Current SNMP SMI does not 
  99.        support topN or usrHistory (need Integer64, Unsigned64), so 
  100.        these functions will not be added at this time.
  101.  
  102. C: Port Aggregation
  103.  
  104.    External port aggregation and internal collection-point monitoring
  105.    were discussed together, but it was agreed that they are
  106.    different problems that require different solutions.  Discussion
  107.    of internal collection-point monitoring is located in sections 
  108.    E.2 and E.4.
  109.    
  110.    Port aggregation allows an agent to potentially reduce DRAM and 
  111.    CPU collection requirements, and an NMS to reduce polling of 
  112.    redundant monitoring information. 
  113.  
  114. C.1: Port Aggregation Mechanism
  115.  
  116.    The ifStackTable will be used to represent an RMON port 
  117.    aggregation group. For example, suppose ifEntry.4, 5, 6, and 7 
  118.    are to be monitored as one collection, and ifEntry.100 exists as 
  119.    a proprietary-virtual 'place-holder' interface, needed only for
  120.    the following ifStackTable rows:
  121.       ifStackStatus.4.100 = active(1)
  122.       ifStackStatus.5.100 = active(1)
  123.       ifStackStatus.6.100 = active(1)
  124.       ifStackStatus.7.100 = active(1)
  125.    An NMS would then set the appropriate RMON dataSource parameter to
  126.    ifIndex.100 in order to monitor the just-configured port aggregation 
  127.    group.
  128.  
  129.    [Ed. note:  The WG did not fully consider this issue at the
  130.    meeting wrt/ dynamic aggregation.  For an N-port switch there
  131.    are (2^^N) - 1 possible port aggregation permutations. If an
  132.    interface is allowed to appear in 0 or 1 collections, then
  133.    N top-level proprietary-virtual interfaces must be pre-configured.  
  134.    This issue is considered re-opened and deferred to the mailing list 
  135.    for discussion.  The WG should consider how to define port aggregation 
  136.    groups dynamically such that the top-layer virtual interface does not 
  137.    actually have to be present in any IF-MIB tables before it can be used.] 
  138.    
  139.    Action Item(Editor ID-2):
  140.    Describe the agreed-upon ifStackTable-based port aggregation framework. 
  141.    Define the dataSource configuration MIB objects.  Consider mechanisms
  142.    for fully dynamic dataSource configuration.
  143.  
  144. C.2: Permutation Rules 
  145. C.3: Data Reduction Mechanisms
  146. C.4: Non-Local Ports
  147.  
  148.    No available-dataSource-permutation mechanism will be considered
  149.    for the ifStack-based aggregation feature at this time.  
  150.    No pre-collection filtering mechanisms will be defined either.  
  151.    All traffic from an identified interface is considered part of the 
  152.    dataSource.  Individual VLANs may be identified as dataSources,
  153.    pending outcome of the features defined in section E.2.
  154.    Monitoring on non-local ports is considered a distributed management 
  155.    function deferred to the DISMAN WG.
  156.  
  157. D: 100MB/Gigabit Ethernet Ports
  158. D.1: High Capacity Counters for Fast Ethernet, Gigabit Ethernet
  159.  
  160.    The high speed counter support for these interfaces is discussed
  161.    in section B. 
  162.  
  163. D.2: Full Duplex Ports
  164.  
  165.    The WG agreed full-duplex and half-duplex interfaces must be
  166.    representable by a single dataSource.  See section E.2 for
  167.    functionality defined in this area.
  168.    
  169. D.3: Net Utilization Formula
  170.  
  171.    The old network utilization formula defined in RFC 1757
  172.    is specific to 10MB Ethernet ports. Formulas for 100MB 
  173.    (half & full-duplex) and GBit Ethernet ports should be defined.
  174.  
  175.    Action Item(Editor ID-3):
  176.    Add appropriate framework text to define calculation formulas
  177.    for specified ethernet port types.
  178.  
  179. D.4: High speed packet capture
  180.  
  181.    The RMON-1 packet capture feature utilizes a packet-arrival-time
  182.    delta-filter with a granularity of milli-seconds.  High speed
  183.    interface monitoring would benefit from finer granularity 
  184.    monitoring.  This feature extension must be backwardly
  185.    compatible with the existing captureBufferPacketTime object
  186.    defined in RMON-1.
  187.  
  188.    Action Item(Editor ID-3):
  189.    Define mechanism to augment the captureBufferTable to
  190.    include the micro-second component of the capture-time-delta.
  191.   
  192. E: Switch Extensions
  193.  
  194.    Switch-related RMON features were discussed in general, and 
  195.    the SMON MIB (ID-2) in particular. 
  196.  
  197. E.1:  VLAN support
  198.  
  199.    The WG will add some IEEE 802.1Q VLAN support to ID-2. 
  200.    It was determined that per-VLAN information is much more
  201.    important in the etherStats group than any other RMON groups.
  202.    Therefore, only VLAN identification, dataSource identification, 
  203.    and port-level statistics collection will be addressed at this time.
  204.    The WG will consider per-VLAN-priority as well, but this
  205.    feature is not required at this time.
  206.  
  207.    Action Item(Editor ID-1):
  208.    Add VLAN encapsulation protocol identifier macros as required.
  209.  
  210.    Action Item(Editor ID-2):
  211.    Consider adding text to ifStack-based dataSource feature explaining use of
  212.    this mechanism to monitor VLANs.  Consider additional mechanism
  213.    to identify a VLAN itself (regardless of port) using the dataSource
  214.    capabilities feature. 
  215.  
  216.    Add control table and data table for 802.1Q VLAN statistics, 
  217.    sparsely-indexed by 12-bit VLAN ID.  Consider proper values for
  218.    dataSource parameter. Data columns are:
  219.       { ucast, mcast, bcast } * { octets, packets }
  220.  
  221.   Consider adding control table and data table of 802.1p statistics
  222.   for a given dataSource, densely indexed by 3-bit 802.1p
  223.   priority value. Consider proper values for dataSource parameter.
  224.   Data columns are:
  225.       { priority } * { octets, packets }
  226.   OR
  227.       { priority } * { ucast, mcast, bcast } * { octets, packets }
  228.  
  229. E.2: Switch Configuration Extensions
  230.  
  231.    MIB objects to configure a copy-port function will be defined. 
  232.    The WG considered three levels of functionality:
  233.       1) 1 src port to 1 dst port 
  234.       2) N src ports  to 1 dst port
  235.       3) M src ports to N dst ports
  236.    The WG will support option (2), and may support option (3) 
  237.    in the future.
  238.  
  239.    A dataSource capabilities mechanism will also be defined, to
  240.    allow an NMS to better determine probe monitoring capabilities.
  241.    Mechanisms to alert or prevent copy-port over-subscription
  242.    problems were discussed, but no features were defined.
  243.     
  244.    Action Item(Editor ID-2):
  245.    Define table allowing arbitrary number of src-portX-to-one-dst-port
  246.    copy-traffic configurations. Consider adding support for full-duplex
  247.    interfaces in the dataSource capabilities table(s).  
  248.    Consider extensions required to support level 3 copy-port functionality.
  249.    Consider adding a dropEvents counter associated with the dst port
  250.    to help an NMS detect over-subscription problems.
  251.  
  252.    Define a dataSource capabilities function, identifying:
  253.       * OID of dataSource 
  254.       * probeCapabilities bit-mask pertaining to this dataSource only.
  255.         If present, this overrides the global bit-mask for this dataSource.
  256.       * indication of dataSource type 
  257.           { ifEntry, ifStack-aggregation, entPhysicalEntry }
  258.         Consider functionality needed for arbitrary aggregation 
  259.         of these base dataSource types.
  260.       * indication of promiscuous vs. non-promiscuous monitoring
  261.         capability of the dataSource
  262.       * indication of errored-frame monitoring capability;
  263.         individual error conditions do not need to be identified.
  264.       * indication of { half-duplex-rx, half-duplex-tx, full-duplex-both }
  265.         status for full-duplex ports
  266.  
  267. E.3: Switch-specific external instrumentation
  268.  
  269.    The WG agreed that no additional functionality was required
  270.    in this area, since port aggregation, dataSource extensions,
  271.    and VLAN monitoring are addressed separately.
  272.  
  273. E.4: Switch-specific internal instrumentation
  274.  
  275.    The dataSource mechanism in E.2 may support dataSources and
  276.    dataSource aggregations not identified in the ifTable 
  277.    (e.g., a repeater port).  The Entity MIB will be used
  278.    to identify internal backplanes (and possibly other
  279.    entPhysicalEntry types) as collection-points.
  280.  
  281.    Action Item(Editor ID-2):
  282.    No new functionality will be considered in this area, but
  283.    consider adding reference to Bridge MIB to identify statistics
  284.    for number of forwarded vs. dropped frames per-bridge-port in
  285.    framework section for switch monitoring.
  286.  
  287. E.5: Per-Connection Statistics
  288.  
  289.    TCP connection monitoring was discussed, but this work will not
  290.    be pursued, since it is considered to be within the scope of 
  291.    the RTFM WG.
  292.  
  293. E.6: Switch-Specific Protocol Directory
  294.  
  295.    The WG determined that no switch-specific protocolDirectory 
  296.    replacements or extensions were required.
  297.  
  298. F: Interim Meeting
  299.  
  300.    The WG may need an interim meeting to complete the current workload
  301.    by August. Due to the amazing amount of material covered and resolved
  302.    in 3.5 hours at the Memphis meeting, an interim was not scheduled at 
  303.    this time.  In the event the action items herein are not resolved by 
  304.    May 12, then an interim will be announced around the June 10 time-frame.
  305.  
  306. F.1: Meeting Goals
  307.  
  308.    Completion of deliverables defined in the Summary section above.
  309.  
  310. F.2: Meeting Logistics
  311.  
  312.     Meeting location does not have to be outside the USA, since
  313.     it will be held within two months of the Munich IETF (even
  314.     though the RMONMIB WG does not intend to meet in Munich).
  315.     The WG will probably choose a non-hosted city, at an airport hub
  316.     on or near the east coast of the USA. The cities suggested so far:
  317.        * Washington, DC
  318.        * Boston
  319.  
  320. G:  Late Additions
  321. G.1: RMON-2 MIB Bugs
  322.    
  323.    The WG discussed the following RMON-2 related issues:
  324.       * some TCs are defined in terms of other TCs
  325.       * 1757 version of OwnerString TC now different (maybe obsolete), and
  326.         perhaps the IF-MIB version or general TC-MIB replacement should 
  327.         be used instead.
  328.  
  329.    No resolution was reached in either case, but the WG agreed that
  330.    the capability to define TCs in terms of other TCs should be supported.
  331.  
  332. G.2: ATM-RMON MIB Status
  333.  
  334.    The ATM-RMON MIB counts ATM-specific cells and connections, using
  335.    data structures similar to those found in RMON-1.  The ATM Forum
  336.    is standardizing this MIB, and a final vote is due soon on
  337.    document af-nm-test-0080.000.  The RMONMIB WG is requested to
  338.    consider integration of frame-based monitoring of ATM interfaces
  339.    with the cell-level mechanisms found in the ATM-RMON MIB.
  340.  
  341.    Action Item(Editors ID-1):
  342.    Consider adding appropriate PI macros for AAL-5, LANE, and other 
  343.    ATM-related frame encapsulations.
  344.  
  345. --------------C4675A2A60--
  346.  
  347.