Minutes - IETF #40 Washington, D.C. ------------------------------------ WG: PTOPOMIB Area: OPS Meeting: 10dec97 0900-1130 WG Chair: Ken Jones Minutes: Andy Bierman Summary ------- The PTOPOMIB WG met at this meeting to advance the documents in progress, the PTOPO MIB and the PTOPO Discovery Protocol (PDP). A 'page by page' review of the documents was conducted. The sections below contain a summary of every issue raised in each of the two documents. Most issues were resolved, and the next set of drafts are expected to be the final versions before a "WG Last Call" is held. Agenda ------ Document Reviews: - draft-ietf-ptopomib-mib-01.txt (PTOPO MIB) - draft-ietf-ptopomib-pdp-01.txt (PDP Protocol and MIB) PTOPO MIB Review ---------------- Sec 2.) Update boiler-plate text The introductory text describes the SNMPv2 SMI, and should be updated to mention the SNMPv3 framework. Sec 3.4) Clarify design goals The bullet on 'Partial Topology Support' says a PTOPO agent keeps information derived from the "best" source. This will be clarified to indicate that redundant information is okay, and an agent does not have to remove "good data" when adding new information. However, an agent should not present topology information known to be incorrect. The bullet on 'Agent Location Neutrality' will be removed, since the working group decided not to develop a MIB to support both the Topology Agent and Topology Server functions. Sec 5.2 and 5.3) Mandatory Entity MIB and Interfaces MIB Support A suggestion was made to decouple the identification of physical components from the Interfaces MIB and Entity MIB, and allow proprietary identifiers instead. After much debate, the WG decided not to change this requirement, but clarifying text will be added to these sections, to indicate the level of compliance required for PTOPO MIB support. p. 18 - PtopoAddrSeenState TC) Clarify Enumeration Semantics The TC will be clarified to indicate that an agent maintains a 'best effort' approach. The agent must have some internal information to justify changing the "AddrSeenState" from the value 'unknown(2)' to either 'one-addr(3)' or 'multi-addr(4)'. p. 19 - ptopoConnTable DESCRIPTION) Incorrect Text The text states that the table contains one row per physical entry. This will be changed to "one or more rows" per physical entry. p. 21 - ptopoConnIndex DESCRIPTION) Index Reuse Issue A long discussion on the index reuse issue was held. Either an index value must be reused (e.g., relearn a connection, so reuse the old index), may be reused, or must not be reused between reboots. Resolution: No semantics are attached to the ptopoConnIndex, so index values may be reused between reboots. An NMS should not assume a particular ptopoConnIndex value maps to a particular remote port (e.g., even columns such as ptopoConnRemoteChassis can change). p. 27 - ptopoConnTabReplaces object) Useless Counter It was decided that this counter will be incrementing too often to be useful, and it will increment as a result of normal operation of a PTOPO agent. This counter will be removed. p. 29 - ptopoConfigChange NOTIFICATION) Trap Throttling A debate was held over the throttling behavior for this trap. At issue was the default throttling interval (5 sec.) and whether this should be a configurable parameter instead of a constant. The notion of a "startup quiet time" and a "reconfig quiet time", i.e., different throttling intervals based on 'condition', was discussed. Resolutions: A r/w MIB object will be added to configure the throttling interval, which also replaces the 'ptopoConfigTrapsEnabled' MIB object. The range of the new MIB object will be (0 | 5..3600) seconds. The DEFVAL is zero, which means transmission of the trap is disabled by default. It is suggested that the interval be set to 60 as a default, when transmission of this notification is enabled. General) PDP Dependencies There are several places in the document where the PTOPO Discovery Protocol is used as an example of a protocol suitable for supporting the PTOPO MIB. Clarifying text will be added as appropriate, to indicate that PDP implementation is not required for compliant implementation of the PTOPO MIB. PDP Review ---------- Sec. 4.3.1) Proposal to make checksum validation optional A proposal was made to make the PDP checksum completely optional. Currently, checksum generation is optional and checksum validation is mandatory. This issue caused a great deal of discussion. Many feel that the data link layer FCS is sufficient, and another checksum, even a simple checksum, is not needed. Some believed that optional validation makes the feature completely unreliable, and would rather have the checksum removed. Resolution: The checksum field will be removed from the PDP message. Sec. 4.5.5) PDP Shutdown procedures are too restrictive The PDP Shutdown procedures described for transmission (4.5.5.1) and reception (4.5.5.2) will be changed. The restrictions related to pdpOperStatus will be removed. p. 21 - pdpSuppressEntry INDEX) Support on Repeater devices The granularity of PDP suppression can't be supported by repeaters, particularly for PDP message transmission. Clarifying text will be added to this section, relaxing the 'per-port' transmission granularity requirement for repeaters. For devices which cannot limit transmission of a PDP message to a single port (but rather a group of ports), an agent implementor should choose one port to identify the port group, and should limit PDP transmission to one message per port group (rather than one per port) if possible. p. 26 -- pdpStatsInPkts) MIB object name is unclear The name of the MIB object is unclear, since it doesn't convey whether the counter includes all received PDP messages, or just valid received PDP messages. The MIB object will be renamed to 'pdpStatsInGoodPkts', and the behavior is unchanged (i.e., the counter will increment only when a valid PDP message is received). sec. 4.1) Frame encapsulation The WG must decide if a special multicast MAC address can be obtained from IEEE, and if not, then can a special MAC address be assigned by IANA. The WG Last Call for this document cannot start until this issue is resolved, although the actual value of the special address can be assigned later in the process. The Ethertype used to identify the PDP message must also be assigned. This may actually be defined under LLC/SNAP, i.e., by using 'IANA' as the numbering authority in the SNAP OUI field. Conclusions) After both drafts are revised and republished, and the frame encapsulation issues are resolved, the WG Last Call for both documents can begin. Note that the 'Persistent Identifiers' document has been deferred to the recently reactivated Entity MIB WG. The PTOPOMIB WG expects that the entPhysicalAlias object definition will be made stable as soon as possible, so PTOPO MIB implementations can be started.