IETF #42 WG Minutes
OPS Area; RMONMIB WG
Chicago, IL  August 27, 1998

WG Chair: 	Andy Bierman  (abierman@cisco.com)
Minutes:   	Andy Bierman and Russell Dietz (rsdietz@tecelite.com)

Review Material:

(Current I-Ds)
[1] RMON Protocol Identifiers (Version 2) 	<draft-ietf-rmonmib-rmonprot-v2-03.txt>
[2] SMON MIB      				<draft-ietf-rmonmib-smon-04.txt>
[3] HC-RMON MIB 				<draft-ietf-rmonmib-hcrmon-03.txt>

(Reviews of Current I-Ds)
[4] ftp://ftp-eng.cisco.com/ftp/rmonmib/review-rmonprot-v2-03.txt
[5] ftp://ftp-eng.cisco.com/ftp/rmonmib/review-smon-04.txt
[6] ftp://ftp-eng.cisco.com/ftp/rmonmib/review-hcrmon-03.txt

Agenda:
1) RMON Protocol Identifiers (Version 2) Discussion
2) SMON MIB Discussion
3) HC-RMON MIB Discussion
4) Interoperability Test Event Planning
5) Standards Track Advancement Planning
6) Application/Service Performance Monitoring

Executive Summary:

The RMONMIB WG is currently working on three different drafts.  All of these drafts 
have been completed for some time, and peer reviews have recently been completed.  
The meeting was used to "review the review comments", and resolve any open issues 
with any of the drafts.  

The WG resolved almost all known issues with these drafts.  The next version of each 
will be the "final draft", and will be forwarded to the IESG for RFC publication, by 
November 1998.

The WG also discussed plans for an upcoming interoperability test event in January 
1998, standards advancement plans for the RMON MIBs, and some ideas for a possible 
future WG charter.

1) RMON PIv2 Discussion

The latest PI draft [1] and the associated review comments [4] were discussed by the WG.

1.1) PI document Maintenance 

The number of protocols supported by the RMON-2 MIB is growing all the time.  This 
is an important issue, because RFC 2021 contains normative references to the Protocol 
Identifiers document.  If the PI document is changing frequently, it will be cycling at 
Proposed Standard status. This will cause RFC 2021 to stay at Proposed Standard 
status indefinitely.

The WG decided to split the PI document into two pieces.  The beginning section, 
which defines the PI macro format, will become the "Protocol Identifier Reference" 
document and will stay on the standards track (cycle at Proposed).  The hundreds of 
PI macros will be moved to a new document called the "Protocol Identifier Repository" 
document, which will be taken off the standards track and published as an Informational 
RFC. Additions to the PI Repository will then be decoupled from the RMON-2 MIB itself.

1.2) PI macro language and terminology

The PI Reference document will be changed to emphasize that the use of "macro" in 
the term "PI macro" is historical, since they are not really macros.  The document will 
also be clarified in several ways, such as: * many of the acronyms will be expanded 
at first use * TBDs and editor's notes will be updated and removed  * document format 
and boilerplate will be updated as  per RFCs 2026, 2119, and 2223

1.3) Protocol Verbs

It is possible that support for "sub-protocols" or "verbs" will be added to the PI Reference 
and Repository documents in the future.  These verbs would allow specific operations 
of various terminal protocols to be uniquely identified, for counting and service 
monitoring purposes.  

1.4) Encapsulation Layer Protocols

The encapsulation layer protocols, such as IEEE 802.1Q, cause the number of 
protocolDirectory entries to increase dramatically.  The idea of treating such layers as 
just another type of "base layer" was discussed.  It was decided that although few (if 
any) implementations actually model 802.1Q as a specific layer in each protocol identifier, 
there is not enough interest to change the encapsulation layer identifiers at this time.  It 
was noted that specific "VLAN ID" and "user priority" statistics can be obtained with the 
SMON MIB.  The only potential impact is in the protocolDistStatsTable and the RMON-2 
relative-offset filtering mechanism.

1.5) Interoperability Test Issues

Specific interoperability issues related to the PI Reference and (to a lesser degree) the 
PI Repository documents were discussed.  The following requirements were identified:
* Need to test agents with real traffic (e.g., traffic playback), not simulated and/or partially 
   constructed application traffic. 
* Need to test protocols with specific protocolDirParameters BITS set and cleared (e.g. 
   NFS fragments, TFTP sessions).
* Need to test IP tunneling and other "multiple L3" protocol encapsulations
* Need to test with some "802.1Q tagged" traffic
 
1.6) Wildcard Terminal Mechanism

The protocol directory (PD) can contain many different encapsulations of the same 
application.  It is desirable to create a wildcard mechanism for terminal protocols, similar 
to the existing L3 wildcard mechanism. This can reduce the memory used by the agent, 
and the polling required by the NMS application.

A proposal for a new "base layer function" to identify wildcard terminals will be sent to 
the mailing list by Russell Dietz for the WG to evaluate.  The function must allow a 
particular terminal PI to be identified as a "wildcard-terminal", and the L3 address type 
information must be preserved (for NL and AL counting purposes).

If there are no strong objections posted to the mailing list, the wildcard terminal function 
may be altered, and then added to the PI Reference document as an optional feature, (i.e., 
no MIB objects will require that wildcard-terminal encapsulations be present in the PD).

1.6) Protocol Local Index Mapping Table

A proposal for a new mapping feature was discussed, which would provide a simple 
mapping from a protocolDirLocalIndex to its associated { protocolDirID, 
protocolDirParameters } tuple.

This will be discussed on the mailing list and deferred to future work.

2) SMON MIB Discussion

The latest SMON MIB draft [2] and the associated review comments [5] were discussed 
by the WG.

2.1) Garbage Collection Review Comments

A review issue was raised regarding the garbage collection of the smonPrioStatsTable.  
These entries are not garbage-collected, but the smonVlanIdStatsTable is (LRU) garbage-
collected.  The document will be updated to include the rationale for this decision.  An 
individual smonPrioStatsTable has a maximum of 8 rows, which is small enough to 
expect an agent to account for all 8 possible minor index values, without garbage collection.

2.2) OID Assignment Conflicts

The current HC-RMON and SMON drafts use the same OID assignment in some places. 
The SMON MIB will keep its current numbering and the HC-RMON MIB will be 
renumbered to fix this problem.

2.3) OwnerString Re-definition Issue 

There is a re-definition of the OwnerString TC, which causes popular MIB compilers to 
generate error messages when compiling this MIB.  The OwnerString TC in RFC 1271 
(later 1757) is not exactly the same as the cloned version in the Interfaces MIB (RFC 2233), 
partly due to the translation from SMIv1 to SMIv2.  SMON imports ifIndex from the 
Interfaces MIB, so MIB compilers complain about the "re-definition" of the OwnerString 
TC.  This problem is avoided in the RMON-2 MIB by importing ifIndex from RFC1213-
MIB, instead of IF-MIB. (Not a great solution either!)

This issue is not likely to be resolved by the RMONMIB WG, but it will be taken to the 
mailing list, in the hope someone will propose a solution to this "dependency mess".  Perhaps 
when RFC 1757 is updated in SMIv2 format (see sec. 5.1) the OwnerString textual convention 
can be renamed to RmonOwnerString", and all usage of "OwnerString" in RMON MIBs will 
be changed to "RmonOwnerString" as each MIB is updated (e.g., from Proposed to Draft 
Standard).  Hopefully, a less intrusive solution will be proposed on the mailing list instead. 

2.4) SMON dataSourceCapsTable Indirection Issue

The dataSourceCapsTable allows an agent to map Entity MIB physical entities (e.g., 
repeater backplanes) and entire VLANs to ifEntries with ifType "propVirtual(53)". There 
is some concern regarding customer confusion and increasing the size of the ifTable.  
The SMON editors will add clarifying text regarding this issue to the next SMON draft.

2.5) portCopyTable Bugs

The portCopyTable conformance statement and  ASN.1 comments related to the 
portCopyTable conformance are inconsistent.  The SMON editors will change one of 
them to fix the problem.  The portCopyIndex range will also be expanded to match the 
upper bound used in the InterfaceIndex textual convention.

2.6) New SMON portCopyTable Features

A proposal for adding new features (i.e. columns) to the portCopyTable was discussed by 
the WG. There seem to be some common features that have been implemented in 
proprietary MIBs, which would be useful in a standard MIB.

New features proposals include:
* portCopyDirection:  SYNTAX INTEGER { rx(1), tx(2), both(3) }  A parameter to select 
   traffic by direction.
* portCopyVlanID: SYNTAX Integer32 (0..???) allow for copy of a single configured 
   VLAN from a  ingle dataSource (presumed to carry traffic from multiple VLANs).
* portCopyVlanIdMask: SYNTAX BITS allow for copy of multiple configured VLANs 
   from a single dataSource (presumed to carry traffic from multiple VLANs).
* Copy only traffic that matches a certain MAC address (SA or DA).
* Control table switch to configure the copying of errored frames.

There seemed to be WG interest for some of the proposals, but not necessarily in the first 
version of the SMON MIB.  The portCopyDirection object had received the most discussion. 
The WG held the following "vote" to gauge consensus:

1) Don't want to do any of this in the SMON MIB
2) Move the portCopyTable forward as-is, with no new features at this time.
3) Add the portCopyDirection object now, and postpone consideration for all other new 
features to a future release.

Results:
1) 0
2) 3
3) 8

The WG Chair has posted a proposal for this object to the mailing list. Unless there are 
any objections within the next two weeks, the SMON editors will add it to the next 
SMON draft (directly to the portCopyTable).

2.7) smonVlanIdStatsId Range

The smonVlanIdStatsId object has a range of 0..4095.  Apparently, the new Bridge MIB 
has a TC to define a special VLAN index value, such that values for non-802.1Q VLANs 
(above 4095) can be supported.  A clause in the conformance section would be needed for 
this MIB object, so it is clear that only index values 0..4095 are mandatory for MIB 
conformance. 

The "working proposal" is that the upper bound of this MIB object be increased to match 
the Bridge MIB TC.  The DESCRIPTION clause will explain the "non-dot1Q" semantics 
of VLAN indexes above 4095. Unless there are any objections within the next two weeks, 
the SMON editors will make this change to the smonVlanIdStatsId object.

2.8) Interoperability Test Issues 

Specific interoperability issues related to the SMON MIB were discussed.  The following 
requirements were identified:
* Need to use "tagged" test traffic for multiple, specific 802.1Q VLAN IDs.
* Need to use test traffic tagged with multiple, specific 802.1p user priority values.
* Need to test dataSourceCapsTable against real and reported capabilities
* Need to test usage the new SmonDataSource TC options, smonVlanDataSource.<V> 
   and entPhysicalIndex.<N>.
* Need to test portCopyTable operation and capabilities, compared to those reported in 
   the dataSourceCapsTable.

3) HC-RMON MIB Discussion

The latest High Capacity RMON draft [3] and the associated  review comments [6] were 
discussed by the WG.

3.1) Rationale for ZeroBased counters

The ZeroBasedCounter32 and ZeroBasedCounter64 textual conventions do not contain 
any rationale for the usage of the TC.  The HC-RMON MIB editor will add some clarifying 
text as to the expected TC usage, explaining that these counters are found in data tables that 
get created by management action. The starting value of zero represents an implied poll, 
taken at the moment the table is instantiated.

3.2) mediaIndependentTable Conformance

The mediaIndependentTable is a "stand-alone" feature, yet it is part of the conformance 
statement for the RMON-2 HC extensions.  The HC-RMON editor will move this table 
to its own conformance macro.

3.3) mediaIndependantTable Duplex Changes

The mediaIndepenentTable is defined such that the "out" counters are only instantiated 
if the port is operating in full-duplex mode.  This causes a problem for NMS applications 
if the duplex mode of the port changes while the mediaIndependentEntry is active.  There 
are no discontinuity indicators for either the "in" or "out" counters in this table, such as 
"last-activated-time" or  "last-duplex-mode-change-time" Timestamp objects.  There is 
no explicit indication of the duplex mode, which would be useful for configuring RMON 
alarms on duplex-mode changes.

The WG will discuss this issue on the mailing list. There seemed to be WG consensus 
that the table is broken as-is, but it is worth fixing, and the solution should not be that difficult.

Three different approaches seem to be popular on this issue: 
1) the "minor tweak" solution:
Change the text that says the "out" counters go away to state instead that the "out" 
counters never go away, but simply stop incrementing in half-duplex mode.
2) the "80/20 solution":
Make the change in (1), but also add one new read-only MIB object to explicitly 
identify the duplex mode * mediaIndependentDuplexMode - enum { half(1), full(2) }
3) the "complete solution":
Make the changes in (1) and (2), but also add some new read-only MIB objects to help 
detect duplex mode changes:
    * mediaIndependentDuplexChanges - Counter32
    * mediaIndependentLastDuplexChangeTime - TimeStamp

The WG will discuss this issue on the mailing list over the next two weeks, and 
hopefully a consensus will be reached in that time.  The HC-RMON MIB cannot 
advance until this issue is resolved, so hopefully the WG will discuss and resolve this 
issue quickly.

3.4) ZeroBasedCounter64 TC

This TC uses SYNTAX Counter64, which is not an entirely legal modification to the 
Counter64 semantics. The issue is that a counter has special semantics related to its 
monotonically increasing behavior. A "snapshot" of a counter does not monotonically 
increase, so it should be a gauge instead.

The RMONMIB WG has been waiting for the SNMP WG to add Integer64, Gauge64, 
and/or UInteger64 to the SMIv2, but the SNMP WG finally decided not to add any 
new 64-bit types to the SMI in the near future.

The RMONMIB WG therefore decided to leave the ZeroBasedCounter64 TC as-is. 
There is some field experience already that the Counter64 "wire-encoding" does not 
cause interoperability problems between HC-RMON agents and applications.

4) Interoperability Test Event Planning

The WG discussed the possibility of another interoperability test event, to test RMON-2 
and the new MIBs.

4.1) Testing Scope and Logistics

The following documents would be tested:
* RMON-2 MIB	[RFC 2021]
* RMON-2 PIv2   	update to [1]
* SMON MIB      	update to [2]
* HC-RMON MIB   	update to [3]
  
The timeframe for the test event will be mid or late January 1999.

The test event will be hosted by InterWorking Labs, and will be held in (or close to) 
San Jose, CA.

The testing requirements mentioned in sections 1.5 and 2.8 will be addressed at the test, 
as well as general interoperability of the RMON-2 and HC-RMON MIBs. Test networks 
consisting of 10/100 ethernet and gigabit ethernet segments will be used (assuming 
vendors will loan equipment and engineers for the test).  Further announcements 
regarding this test event will be made on the WG mailing list later this year.

5) Standards Track Advancement Planning

The existing RMON MIBs need to progress along the standards track.  Each MIB was 
discussed by the WG, and The following actions will be taken for each MIB:

5.1) RFC 1513 - Token Ring RMON and RFC 1757 - RMON-1 MIB

The WG Chair will issue a call for interoperability reports on the mailing list. 
Implementors will be asked to fill out a survey and email it back to the WG Chair, who 
will publish the results.

These MIBs will also be converted to SMIv2 format as they are progressed on the 
standards track.  The Token Ring RMON MIB is due to move from Proposed Standard 
to Draft Standard, and the RMON-1 MIB is due  to move from Draft Standard to Full 
Standard.  The WG Editor will produce converted drafts of these MIBs and the WG 
will discuss the conformance sections (and any other details) on the mailing list.  No 
timeframe has been set for this task, but it is hoped that the reports and drafts will be 
ready be the next IETF in December 1998. 

5.2) RFC 2021 - RMON-2 MIB

The RMON-2 MIB will not be advanced at this time. The associated Protocol Identifiers 
document will cycle at Proposed Standard, and these documents will be advanced 
together at a later time.

5.3) RFC 2074 - RMON Protocol Identifiers

This document will be obsoleted by the final, published version of the PIv2 draft [1]. The 
document will be split into two RFCs, as described in section 1.1. The standards track 
"PI Reference" document will cycle at Proposed Standard. The more dynamic "PI 
Repository" document will become an informational RFC, and will be decoupled from 
RFC 2021 and the PI Reference.

6) Application/Service Performance Monitoring

The WG discussed some ideas for future work. Ideas for a charter proposal for 
Application or Service Level Monitoring were discussed briefly, and will be discussed 
further on the mailing list.

The WG Chair and the Area Director want to make sure any proposed work items be 
measurable, verifiable and interoperable.  The proposed charter should perhaps be 
based on metrics defined by the IPPM WG. 

There are differing opinions on all the features needed to do Application and/or Service 
Level Monitoring, as there is disagreement to what these terms even mean.  The proposed 
charter should consider precise goals and not be limited in scope to passive protocol 
response timing.

The WG also discussed a couple other features that may be considered in the new charter:
* a "username-to-L3-address" mapping function 
* distribution counters for DIFFSERV codepoint usage; Augmentation to some RMON-
   2 tables (e.g., protocolDistStatsTable and alHostTable)

Ideas and comments on the proposed charter should be sent to the WG mailing list. A 
final version is expected to be forwarded to the Area Director before the next IETF in 
December 1998.