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