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.