Editor's Note: These minutes have not been edited.
Minutes - IETF #38 Memphis, TN
--------------------------------
WG: RMONMIB
Area: OPS
Meetings: 8apr97 0900-1130
9apr97 1015-1115
Minutes: Andy Bierman (WG Chair)
Summary
-------
The goal of the Memphis meeting was the resolution of all issues,
(to the greatest degree possible) related to current WG development.
The following I-Ds and all WG email since the last meeting were
discussed:
draft-ietf-rmonmib-rmonprot-v2-00.txt (ID-1)
draft-waterman-rmonmib-smon-00.txt (ID-2)
draft-ietf-rmonmib-hcrmon-00.txt (ID-3)
All issues were resolved, at least in principle. Some features
are not documented yet in WG Internet Drafts, so actual resolution
is pending such publication. The WG believes completed documents can be
submitted to the IESG by August 1997.
Deliverables: 3 documents
The WG agreed to maintain the current document structure. The WG I-D
version of ID-2 will reflect the scope agreed upon at the meeting..
The title is not clear yet, but 'Switch Extensions for RMON'
may be appropriate.
Detailed Agenda Resolution
--------------------------
The following functional components were discussed during the meetings.
Individual resolutions represent WG consensus, but are subject to
mailing list objection. This is a very detailed account, since
every aspect of the work-in-progress was affected by WG decisions
made at this meeting. These minutes also serve as editing instructions
for the authors of the I-Ds listed above.
A: Protocol Directory
A.1: review and update ID-1
A.2: Protocol macro parsers
No new macros have been posted to the mailing list since the last
meeting. The WG concluded this method of document completion was
not working, and it was up to the document authors to work amongst
themselves to complete the Protocol Identifiers (V2) I-D.
Action Item(Editors ID-1):
A new version of ID-1 is expected in one month, with new PI macros,
the RFC 2074 edits, and sub-section headings within the PI section
removed. An off-line phone conference will be planned to discuss
potential work assignments.
B: 64-bit counters
B.1: scope of 64-bit support
B.2: SNMPv1 and SNMPv2C support
B.3: MIB Logistics -- Table format
The High Capacity RMON MIB (ID-3) and all related WG email
was discussed in detail:
* too much boiler-plate -- some introduction text is copied from
the RMON-2 MIB.
Action Item(Editor ID-3):
Left up to the Editor for change. Text must remain
consistent with version in RFC 2021.
* 'SPARSE-AUGMENTS' needed instead of real AUGMENTS to
allow for a probe with only some interfaces requiring 64-bit
counters. The WG concluded that instantiating all columns in
all rows would not be a burden on agents, and would make table
retrieval easier for NMS applications.
Action Item(Editor ID-3):
None -- AUGMENTS clause remains. Consider adding text explaining
that the agent must instantiate all columns for all
configured rows in the augmented table, if any columns
are needed out of this table. Add rules for mapping
the 32-bit counter to these filler-columns.
* keep ID-2 and ID-3 separate.
Action Item(Editor ID-3):
Remove reference to switch-based RMON instrumentation.
This functionality to be moved to WG version of ID-2.
* more Counter64 support.
The WG wants all etherStats packet-based counters to have 64-bit
versions, as well as all appropriate topN and usrHistory tables.
Action Item(Editor ID-3):
Add missing etherStats extensions. Current SNMP SMI does not
support topN or usrHistory (need Integer64, Unsigned64), so
these functions will not be added at this time.
C: Port Aggregation
External port aggregation and internal collection-point monitoring
were discussed together, but it was agreed that they are
different problems that require different solutions. Discussion
of internal collection-point monitoring is located in sections
E.2 and E.4.
Port aggregation allows an agent to potentially reduce DRAM and
CPU collection requirements, and an NMS to reduce polling of
redundant monitoring information.
C.1: Port Aggregation Mechanism
The ifStackTable will be used to represent an RMON port
aggregation group. For example, suppose ifEntry.4, 5, 6, and 7
are to be monitored as one collection, and ifEntry.100 exists as
a proprietary-virtual 'place-holder' interface, needed only for
the following ifStackTable rows:
ifStackStatus.4.100 = active(1)
ifStackStatus.5.100 = active(1)
ifStackStatus.6.100 = active(1)
ifStackStatus.7.100 = active(1)
An NMS would then set the appropriate RMON dataSource parameter to
ifIndex.100 in order to monitor the just-configured port aggregation
group.
[Ed. note: The WG did not fully consider this issue at the
meeting wrt/ dynamic aggregation. For an N-port switch there
are (2^^N) - 1 possible port aggregation permutations. If an
interface is allowed to appear in 0 or 1 collections, then
N top-level proprietary-virtual interfaces must be pre-configured.
This issue is considered re-opened and deferred to the mailing list
for discussion. The WG should consider how to define port aggregation
groups dynamically such that the top-layer virtual interface does not
actually have to be present in any IF-MIB tables before it can be used.]
Action Item(Editor ID-2):
Describe the agreed-upon ifStackTable-based port aggregation framework.
Define the dataSource configuration MIB objects. Consider mechanisms
for fully dynamic dataSource configuration.
C.2: Permutation Rules
C.3: Data Reduction Mechanisms
C.4: Non-Local Ports
No available-dataSource-permutation mechanism will be considered
for the ifStack-based aggregation feature at this time.
No pre-collection filtering mechanisms will be defined either.
All traffic from an identified interface is considered part of the
dataSource. Individual VLANs may be identified as dataSources,
pending outcome of the features defined in section E.2.
Monitoring on non-local ports is considered a distributed management
function deferred to the DISMAN WG.
D: 100MB/Gigabit Ethernet Ports
D.1: High Capacity Counters for Fast Ethernet, Gigabit Ethernet
The high speed counter support for these interfaces is discussed
in section B.
D.2: Full Duplex Ports
The WG agreed full-duplex and half-duplex interfaces must be
representable by a single dataSource. See section E.2 for
functionality defined in this area.
D.3: Net Utilization Formula
The old network utilization formula defined in RFC 1757
is specific to 10MB Ethernet ports. Formulas for 100MB
(half & full-duplex) and GBit Ethernet ports should be defined.
Action Item(Editor ID-3):
Add appropriate framework text to define calculation formulas
for specified ethernet port types.
D.4: High speed packet capture
The RMON-1 packet capture feature utilizes a packet-arrival-time
delta-filter with a granularity of milli-seconds. High speed
interface monitoring would benefit from finer granularity
monitoring. This feature extension must be backwardly
compatible with the existing captureBufferPacketTime object
defined in RMON-1.
Action Item(Editor ID-3):
Define mechanism to augment the captureBufferTable to
include the micro-second component of the capture-time-delta.
E: Switch Extensions
Switch-related RMON features were discussed in general, and
the SMON MIB (ID-2) in particular.
E.1: VLAN support
The WG will add some IEEE 802.1Q VLAN support to ID-2.
It was determined that per-VLAN information is much more
important in the etherStats group than any other RMON groups.
Therefore, only VLAN identification, dataSource identification,
and port-level statistics collection will be addressed at this time.
The WG will consider per-VLAN-priority as well, but this
feature is not required at this time.
Action Item(Editor ID-1):
Add VLAN encapsulation protocol identifier macros as required.
Action Item(Editor ID-2):
Consider adding text to ifStack-based dataSource feature explaining use of
this mechanism to monitor VLANs. Consider additional mechanism
to identify a VLAN itself (regardless of port) using the dataSource
capabilities feature.
Add control table and data table for 802.1Q VLAN statistics,
sparsely-indexed by 12-bit VLAN ID. Consider proper values for
dataSource parameter. Data columns are:
{ ucast, mcast, bcast } * { octets, packets }
Consider adding control table and data table of 802.1p statistics
for a given dataSource, densely indexed by 3-bit 802.1p
priority value. Consider proper values for dataSource parameter.
Data columns are:
{ priority } * { octets, packets }
OR
{ priority } * { ucast, mcast, bcast } * { octets, packets }
E.2: Switch Configuration Extensions
MIB objects to configure a copy-port function will be defined.
The WG considered three levels of functionality:
1) 1 src port to 1 dst port
2) N src ports to 1 dst port
3) M src ports to N dst ports
The WG will support option (2), and may support option (3)
in the future.
A dataSource capabilities mechanism will also be defined, to
allow an NMS to better determine probe monitoring capabilities.
Mechanisms to alert or prevent copy-port over-subscription
problems were discussed, but no features were defined.
Action Item(Editor ID-2):
Define table allowing arbitrary number of src-portX-to-one-dst-port
copy-traffic configurations. Consider adding support for full-duplex
interfaces in the dataSource capabilities table(s).
Consider extensions required to support level 3 copy-port functionality.
Consider adding a dropEvents counter associated with the dst port
to help an NMS detect over-subscription problems.
Define a dataSource capabilities function, identifying:
* OID of dataSource
* probeCapabilities bit-mask pertaining to this dataSource only.
If present, this overrides the global bit-mask for this dataSource.
* indication of dataSource type
{ ifEntry, ifStack-aggregation, entPhysicalEntry }
Consider functionality needed for arbitrary aggregation
of these base dataSource types.
* indication of promiscuous vs. non-promiscuous monitoring
capability of the dataSource
* indication of errored-frame monitoring capability;
individual error conditions do not need to be identified.
* indication of { half-duplex-rx, half-duplex-tx, full-duplex-both }
status for full-duplex ports
E.3: Switch-specific external instrumentation
The WG agreed that no additional functionality was required
in this area, since port aggregation, dataSource extensions,
and VLAN monitoring are addressed separately.
E.4: Switch-specific internal instrumentation
The dataSource mechanism in E.2 may support dataSources and
dataSource aggregations not identified in the ifTable
(e.g., a repeater port). The Entity MIB will be used
to identify internal backplanes (and possibly other
entPhysicalEntry types) as collection-points.
Action Item(Editor ID-2):
No new functionality will be considered in this area, but
consider adding reference to Bridge MIB to identify statistics
for number of forwarded vs. dropped frames per-bridge-port in
framework section for switch monitoring.
E.5: Per-Connection Statistics
TCP connection monitoring was discussed, but this work will not
be pursued, since it is considered to be within the scope of
the RTFM WG.
E.6: Switch-Specific Protocol Directory
The WG determined that no switch-specific protocolDirectory
replacements or extensions were required.
F: Interim Meeting
The WG may need an interim meeting to complete the current workload
by August. Due to the amazing amount of material covered and resolved
in 3.5 hours at the Memphis meeting, an interim was not scheduled at
this time. In the event the action items herein are not resolved by
May 12, then an interim will be announced around the June 10 time-frame.
F.1: Meeting Goals
Completion of deliverables defined in the Summary section above.
F.2: Meeting Logistics
Meeting location does not have to be outside the USA, since
it will be held within two months of the Munich IETF (even
though the RMONMIB WG does not intend to meet in Munich).
The WG will probably choose a non-hosted city, at an airport hub
on or near the east coast of the USA. The cities suggested so far:
* Washington, DC
* Boston
G: Late Additions
G.1: RMON-2 MIB Bugs
The WG discussed the following RMON-2 related issues:
* some TCs are defined in terms of other TCs
* 1757 version of OwnerString TC now different (maybe obsolete), and
perhaps the IF-MIB version or general TC-MIB replacement should
be used instead.
No resolution was reached in either case, but the WG agreed that
the capability to define TCs in terms of other TCs should be supported.
G.2: ATM-RMON MIB Status
The ATM-RMON MIB counts ATM-specific cells and connections, using
data structures similar to those found in RMON-1. The ATM Forum
is standardizing this MIB, and a final vote is due soon on
document af-nm-test-0080.000. The RMONMIB WG is requested to
consider integration of frame-based monitoring of ATM interfaces
with the cell-level mechanisms found in the ATM-RMON MIB.
Action Item(Editors ID-1):
Consider adding appropriate PI macros for AAL-5, LANE, and other
ATM-related frame encapsulations.
--------------C4675A2A60--