CURRENT_MEETING_REPORT_ Reported by Fred Baker/ACC BRIDGE Minutes The Bridge MIB Working Group convened for two sessions on Tuesday, March 12, 1991. The Bridge MIB under review had been posted to the bridge-mib discussion group on February 16, 1991, as Working Document Bridge MIB, Draft 6, by Decker, Langille, Rijsinghani, and McCloghrie. Chair Fred Baker opened the meeting with a review of the proposed Agenda, which had been posted to the discussion group earlier. All present agreed to the Agenda, which follows: o Static Table (dot1dStatic) Four objects in the entry o Window Table (dot1dWindow) Two objects in the entry o Base Group/Port Table (dot1dBase) Three objects in the group Three objects in the port entry o STP Group/Port Table (dot1dStp) Fourteen objects in the group Eleven objects in the entry o SR Group/Port Table (dot1dSr) Sixteen objects o Transparent Group/FDB and Port Tables (dot1dTp) Two objects in the group Three objects in the FDB Entry Five objects in the Port Entry Anil Rijsinghani presented the dot1dStatic table. He gave a review of how Forwarding Database entries come to be and how entries in the static Table are made. The SNMP concept of entries with a status of ``invalid'' was also discussed. Jim Kinder initiated a lengthy discussion of the relationship of table entries with a dot1dStaticReceivePort of value zero to other entries. Various hypothetical scenarios were discussed and the resulting decision was that an entry with a dot1dStaticReceivePort can coexist along with other entries for the same address. 1 The discussion of the dot1dStatic table was suspended when the Working Group was addressed by Phill Gross, IETF Chair. He talked about the interaction between the IETF and the IEEE 802.1d Committee. Last year a letter was received from the IEEE expressing concern about a possible duplication of efforts by the IETF Bridge MIB Working Group and the IEEE 802.1d Committee. Phill reviewed the IETF philosophy for using the work of a standards body in conjunction with its own work. The IETF will use the reference work as a starting point, while being free to subset it, and within the confines of sound engineering principles, to augment it. A draft of a response letter to the IEEE was presented (see below) and the group approved of sending it along with a copy of the Bridge MIB. Jeff Case pointed out that we need to be sensitive to the fact that a reference document that is used for a starting point may change as work is done within the IETF and that an incompatibility may result between the final reference document and the final IETF work. After the break, talk resumed on the the dot1dStatic table. The agreement was that an entry in the table with dot1dStaticReceivePort=0 is the default value to use if a specific dot1dStaticReceivePort is not specified. The hierarchy of the Forwarding Database is this, then. o Static information for a specific receive port (dot1dStaticReceivePort>0). o Static information for all ports (dot1dStaticReceivePort=0). o Learned information. The dot1dStatic table was approved with wording to accomplish the above changes. Keith McCloghrie presented the dot1dTpFdbWindowTable, starting with an overview of the design considerations The Problem: To provide an efficient means of retrieving the whole or a significant portion of a transparent bridge's Forwarding Database. Alternatives: 2 o Get-Next Sweep - 1 Powerful Get Next per Conceptual Row 1 Conceptual Row per Round Trip o Bulk Algorithm (RFC 1187) either - 1+ Powerful Get Next per Conceptual Row say, 3 Conceptual Rows per Round Trip o or say, 1 Powerful Get Next per 2 Conceptual Rows + 1 Get Request per 10 Conceptual Rows o say, 4 Conceptual Rows per Round Trip o Window Table: 1 Powerful Get Next per 40 Conceptual Rows 40 Conceptual Rows per Round Trip Advantages: o Less ASN.1 encoding/decoding (size and performance) o Can access starting in the middle of a table (e.g., all DECNET addresses) Disadvantages: o Have to look into data to get address for next Powerful Get Next o DUMB MIB sweepers will retrieve redundant information. (but in the same number of requests) Why 40? o A round number o PDU size < 576 o Benefit of >40 not considered worth the effort Keith then compared the dot1dTpFdbTable and the dot1dTpFdbWindowTable, noting that they contain the same number of entries. Window Table FDB Table _______________ _______________ | N | | N | _|_____________| _|_____________| | (N-1),N || | N-1 || | | | | 3 . . . . . . . . . . . . _______________ _______________ | 2-41 | | 2 | _|_____________| _|_____________| | 1-40 || | 1 || | | | | |_____________| |_____________| A discussion of the dot1dTpFdbWindowTable followed Keith's presentation. Bob Stewart argued for including 42 entries from the FDB in each dot1dTpFdbWindowTable. He presented a sound engineering underpinning for his argument but the group decided to leave the number at 40. A corollary discussion took place about the viability of having a variable length window. Jeff Case pointed out that the SNMP Protocol Specification says in part: ``An implementation of this protocol need not accept messages whose length exceeds 484 octets.'' He recommended that the Bridge MIB should not allow arbitrarily large PDUs. The Working Group agreed to leave the number at 40. A question was raised about the dot1dTpFdbWindowTable being in the spirit of SNMP vis a vis, not supporting aggregate objects. Jeff Case spoke once again and indicated that although the dot1dTpFdbWindowTable did not particularly excite him, he had no philosophical objection to it. Various optimization ideas were presented for Powerful Get Next walks and although no consensus was reached, four options were discussed for the disposition of this table. 1. Delete it. 2. Leave it in the MIB as is (Status Optional). 3. Port it to another document to be developed in the Experimental tree. 4. Leave it in the MIB, but change the status to Mandatory. 4 No consensus was reached and the dot1dTpFDBWindow group discussion was tabled. After the break, Chair Fred Baker led a review of the document section by section. Keith McCloghrie clarified that the wording ``protocols that are bridged'' is used to differentiate between those PDUs that are bridged versus those that are not. Bill Anderson spoke from a user's perspective. He presented a need for the Bridge MIB FDB to cover all addresses, bridged and otherwise. Various members of the group pointed out that the Remote LAN Monitoring group was addressing this issue, and in fact had specified this functionality. Two IEEE 802.1d managed objects were left out of the ``not included'' group on page 8. These are SpanningTreeProtocolPort objects DiscardLackOfBuffers and DiscardErrorDetails. These will be added. The discussion moved to the dot1dBase group. Bob Stewart noted that bit ordering for the ``Bridge ID'' was not specified, and it was necessary here and other places in the document. The discussion moved to the dot1dStp group. The incompatibility between IEEE 802.1d specification of time in 1/256ths of a second and the Bridge MIB of 1/100ths of a second was brought up. A challenge was issued by Fred Baker to name a chip that gave 1/256ths granularity for its clock, and the issued died. A side issue of the syntax of dot1dStoMaxAge was brought up. After a discussion of the correct use of TimeTicks vs INTEGER, no change was recommended. A change was made to dot1dStpPriority description to uniquely identify two octets within the Bridge ID. Maurice Turcotte pointed out that dot1dStpPortMulticastAddress should not be on a per port basis and that this address can be determined from the variables dot1dStpProtocolSpecification and ifType. This variable was included at the request of Eric Decker and since he was not present, the group decided to delete this variable, and allow Eric to comment. In the afternoon session, the broken(6) dot1dStpPortState was discussed 5 at great length. No agreement was reached and the issue was tabled. Steve Sherry requested that new TCN counters be added. The consensus of the group was that these counters would present information available elsewhere and were most useful for debugging code rather than networks. No variables were added for TCN counters. A discussion of BridgeID vs. (Priority - Address) with respect to dot1dStpPortDesignatedPort. The broad issue was whether to represent BridgeID variables as one variable or separated into BridgePriority and BridgeAddress. The decision was to leave the variables as they are in the document. The range of dot1dStpPortPathCost should have been (1-65535) The dot1dSr group passed without comment. The dot1dTp group passed without comment. After a brief recess the broken(6) dot1dStpPortState was revisited. The two major points raised in favor of keeping this state were: 1. We need to know when the Spanning Tree Protocol cannot bridge through a port because it is dysfunctional and it would be nice to know that from one variable and, 2. It is possible for the Spanning Tree Protocol to have the port in forwarding state and the port be non-operational. The two major points against this state were: 1. There is no broken(6) state in the Spanning Tree Protocol and, 2. This information is already available from the combination of ifAdminStatus, ifOperStatus, and dot1dStpPortState. After more intense discussion, the group reached consensus and removed the broken(6) value from the dot1dStpPortState. Next the dot1dFdbWindow group was reopened for discussion. After a 6 brief discussion, the consensus was reached that we separate the dot1dFdbWindow group into a separate document and develop it further in the Experimental branch of the MIB. Next the traps were reviewed and agreement was reached after some discussion to let the traps stand. A slight modification was made to the newRoot trap description, with a view to ensuring (to the extent possible) that the Network Management Station would be able to receive the trap. The Bridge MIB Working Group agreed to forward the Bridge MIB Draft 6, with the above modifications, to the IETF for acceptance as a Proposed Standard. LETTER TO IEEE 802.1 William P. Lidinsky Chairman, IEEE 802.1 Institute of Electrical and Electronics Engineers Dear Mr. Lidinsky: Enclosed with this letter, please find the current working draft of the SNMP Bridge MIB, produced by the IETF Bridge MIB Working Group. The Bridge MIB Working Group was organized under the IETF's Network Management Directorate in May 1990, and has studied the semantics of 802.1(d) with a goal of representing it in an SNMP SMI-compliant MIB. The IETF wishes to cooperate with, and coordinate its MIB development efforts with, other ongoing MIB development activities in other standards organizations. In cases where the IETF wishes to develop an SNMP MIB for technology already being considered by another standards group, we have established the following policy: 1) The IETF will always utilize the current effort of another group as the starting point for its own MIB development activities. Therefore, a major portion of the IETF effort may simply be translating the other MIB into the SNMP SMI idiom. 2) Because the requirements of other organizations may not be precisely the same as those of the IETF, we may choose initially to include only a subset of the other MIB. In such a case, we would reserve the 7 opportunity to consider adding the remaining objects to the SNMP MIB in the future. 3) In some cases, we may wish to propose additional objects based on operational experience. It is not expected that this would be a very common occurrence, and in such cases we would make every effort to communicate the IETF proposed objects back to the appropriate group for their consideration. A comparison of 802.1(d) and the current IETF draft should show that, in fact, there are few significant differences. I hope your group will have the opportunity to review the IETF SNMP Bridge MIB. We would appreciate hearing any comments or suggestions you may have. We look forward to working together with you in the future. Thank you, IAB Chair IETF Chair IETF NM Area Director IETF Bridge MIB Working Group Chair Attendees William Anderson wda@mitre.org Fred Baker fbaker@emerald.acc.com Steve Bostock steveb@novell.com Howard Brown brown@ctron.com Theodore Brunner tob@thumper.bellcore.com Jeffrey Case case@cs.utk.edu John Casey Chris Chiotasso chris@roswell.spartacus.com Bill Durham durham@MDC.COM Nadya El-Afandi nadya@network.com Richard Fox rfox@synoptics.com 8 Shawn Gallagher gallagher@quiver.enet.dec.com Martin Gray mg@spider.co.uk Jeremy Greene greene@coral.com B.V. Jagadeesh bvj@esd.3com.com Frank Kastenholz kasten@asherah.clearpoint.com Manu Kaycee kaycee@trlian.enet.dec.com Kenneth Key key@cs.utk.gdy Jim Kinder jdk@fibercom.com Cheryl Krupczak clefor@secola.columbia.ncr.com Then Liu Keith McCloghrie kzm@hls.com John Morrison jfm@lanl.gov Robert Peglar robp@anubis.network.com David Perkins dave_perkins@3com.com Anil Rijsinghani anil@levers.enet.dec.com Mark Schaefer schaefer@davidsys.com Dror Shindelman pbrenner@sparta.spartacus.com Bob Stewart rlstewart@eng.xyplex.com Maurice Turcotte dnmrt@rm1.uucp 9