Editor's Note: Minutes received 7/22 CURRENT_MEETING_REPORT_ Reported by Fred Baker/ACC Minutes of the Bridge MIB Working Group (BRIDGE) The Group met for three purposes: 1. To discuss IEEE 802.5's changes to their MIB, and its impacts on the MIB described in RFC 1286. 2. To discuss implementation experience with RFC 1286. 3. To determine whether RFC 1286 is ready to advance to Draft Standard status. Anil Rijsinghani proposed to facilitate convergence with the Source Routing Addendum to 802.1 by including an optional group for SRT bridges, called the Source Route Bridge Port Pair Group. It contains the following objects: dot1dSrPortPairTableSize INTEGER "The total number of entries in the Bridge Port Pair Database." This number is n(n+1)/2, given that source routing is occurring over n bridge ports. dot1dSrPortPairTable dot1dSrPortPairEntry [dot1dSrPortPairLowPort, dot1dSrPortPairHighPort] dot1dSrPortPairLowPort - an Source Route Port Number dot1dSrPortPairHighPort - an SOURCE ROUTE Port Number dot1dSrPortPairBridgeNum - the bridge number used in the Source Route Descriptor tuple dot1dSrPortPairState - "enabled", "disabled", or "invalid" Richard Sweat, IEEE 802.5's designated liaison to the Bridge MIB Working Group, then presented their view of RFC 1286. To converge with our work, IEEE 802.5 has deleted or modified a number of its managed objects and attributes. They also have some specific requests for changes in the Source Routing Group of RFC 1286. IEEE 802.5, having already made these changes in its own MIB, suggests that we: 1 o Adopt Anil's Port Pair Group. o Divide dot1dSrPortHopCountExceededDiscards and dot1dSrPortHopCount, which relate to the maximum number of routing descriptors in an All Paths Explorer (APE) or Spanning Tree Explorer (STE) frame, into two maxima and two counters: one each for APEs and STEs. o Extend dot1dSrPortLargestFrame (which is an enumerated integer with 8 values) to have 64 possible values as described in draft 7 of the Source Route Addendum. o Count occurrences of duplicate LAN IDs or Tree errors, in an effort to detect problems in networks containing older IBM Source Routing Bridges. o Count LAN ID Mismatches (cases where a frame is being forwarded, but the ``from'' LAN ID is incorrect. o Instead of counting frames in and frames out, count frames through a device. This applies to dot1dSrPortSpecInFrames, dot1dSrPortSpecOutFrames, dot1dSrPortApeInFrames, dot1dSrPortApeOutFrames, dot1dSrPortSteInFrames, and dot1dSrPortSteOutFrames. o To the dot1dSrGroup, add a scalar read-write variable enumerated the same way as dot1dSrPortLargestFrame to indicate the largest frame that may pass through the bridge. o Add a read-write LF Mode field indicating whether the bridge operates using older 3 bit length negotiation fields or the newer 6 bit length field in its RIF. o Either change the names of objects or include text explaining the use of the path type acronyms, as IEEE 802.5 has changed their names. The mapping is: - Spanning Tree Explorer (STE) becomes a Spanning Tree Explorer (STE). - All Paths Explorer (APE) becomes an All Routes Explorer (ARE). - Specifically Routed Frame (Spec) becomes a Source Routed Frame (SRF). Fred Baker applauds the efforts of IEEE 802.5 to achieve convergence. The Working Group felt that the proposals made by Anil and Richard were basically workable, and drew the following conclusions. We also felt (although there were three source routing implementations represented) that our best expertise was not present at the meeting, and so feel that the subject should be discussed on the mailing list before reaching a final conclusion. 2 The Group's initial conclusions were: o Adopt Anil's Port Pair Group. o The Group is not sure of the necessity of dividing the hop counts and hop count discards by APEs and STEs. o Extend dot1dSrPortLargestFrame (which is an enumerated integer with 8 values) to have 64 possible values as described in draft 7 of the Source Routing Addendum. o Count occurrences of duplicate LAN IDs or Tree errors, in an effort to detect problems in networks containing older IBM Source Routing Bridges. o Count LAN ID Mismatches (cases where a frame is being forwarded, but the ``from'' LAN ID is incorrect. o Do not change the way we count frames, as our implementations do in fact count them (IEEE was concerned that these could not be counted), and this method is consistent with other IETF MIBs. o To the dot1dSrGroup, add a scalar read-write variable enumerated the same way as dot1dSrPortLargestFrame to indicate the largest frame that may pass through the bridge. o Add a read-write LF Mode field indicating whether the bridge operates using older 3 bit length negotiation fields or the newer 6 bit length field in its RIF. o Include text explaining the use of the path type acronyms. The Group then moved on to discuss implementation experience. Six vendors indicated that they had implemented the MIB, and were largely happy with it. The following suggestions for clarification were made: o Anil will provide clarifying text for the DESCRIPTION of dot1dStpPortPathCost, which some have found inadequate. o The Default Value of dot1dStaticAllowedToGoTo be specified in the DESCRIPTION as a string of ones of appropriate length. o The Default Value of dot1dStaticStatus is ``permanent''. o Port Numbers use the range 1..65535. o Update the bibliography. 3 o dot1dTpPortInFrames and dot1dTpPortOutFrames be clarified by changing the last few words in the description from ``processed by the local bridging function'' to ``processed by the bridging function, including management frames.'' We will ask the list to ratify these clarifications. One other issue was raised which affects the strategic direction of this Working Group. Some vendors are interested in proxying for IBM Source Routing Bridges, which use a modified version of the 802.1(d) BPDU. Also, IEEE 802.1(g) currently proposes that the BPDU be modified in remote bridges when sent on the lines. It is quite possible, then, that a bridge might participate in more than one spanning tree on a port by port basis. Fred Baker proposed that the object dot1dStpProtocolSpecification, which indicates a single spanning tree protocol in use in the system, be deprecated and replaced with an INTEGER bit string indicating the spanning tree protocols that the device is capable of: 1 other 2 decLb100 4 ieee8021d 8 ibmTolkienRing 16 ieee8021g In addition, an object is added to the dot1dStePortEntry indicating which of those protocols is running on the indicated port. This allows for some flexibility. The proposal of the Working Group, given ratification of the above changes on the list, is that: o The Group do nothing now with IEEE 801.2(g)'s proposals, as it is not sufficiently close to completion. o The Group separate the Source Routing Group into a separate document, apply the ratified subset of Anil's and Richard's proposals, and recommend that this remain at Proposed Standard status. o The Group apply the requested clarifications and, if ratified, Fred's proposed object change, and advance the bulk of the Bridge MIB to Draft Standard Status. Attendees 4 ^L David Arneson arneson@ctron.com Sam Ayers s.ayers@sybus.com Fred Baker fbaker@acc.com Andy Bierman bierman@davidsys.com Greg Celmainis gregc@newbridge.com Chris Chiotasso chris@artel.com Cathy Cunningham cmc@microcom.com David Engel david@ods.com Pria Graves priag@nsd.3com.com George Kajos kajos@coral.com Mark Kepke mak@cnd.hp.com Steven Lynes lyness@rimail.interlan.com Cindy Mazza Keith McCloghrie kzm@hls.com David Minnich dwm@fibercom.com Rina Nathaniel rina!rnd!rndi@uunet.uu.net John Payne jop@wang.com Venkat Prasad vsp@3com.com Guenter Roeck roeck@conware.de Michael Sapich sapich@conware.de Koichiro Seto seto@hitachi-cable.co.jp Timon Sloane peernet!timon@uunet.uu.net Chris Sullivan mm@gandalf.ca Richard Sweatt rsweatt@synoptics.com Stephen Tsun snt@nsd.3com.com Luanne Waul luanne@wwtc.timeplex.com Gerard White Kiho Yum kxy@nsd.3com.com 5