CURRENT_MEETING_REPORT_ Reported by Maurice Turcotte/Racal BRIDGE Minutes Fred Baker gave a recap of the Knoxville meeting and the subsequent activity on the Bridge-Mib mailing list. Fred then outlined the objectives of this meeting, which were o to decide on which proposed MIB to pursue, and o to then evaluate each of the MIB variables one by one. The two proposals were Richard Fox's and McCloghrie/Decker/Langille/Rijsinghani's. Each MIB ``camp'' was asked to give an overview of their respective proposal. For reference, ``MDLR'' is the Multiple Vendor MIB, and ``Fox'' is Richard Fox's MIB in the discussion that follows. Richard Fox explained the historical background and philosophical underpinning of his MIB. It was acknowledged that this proposal predated the other. His goal was to have a MIB that was as general as possible, and did not favor one implementation over another. He tried to tie the Source Routing and Transparent Bridge variables together, more than has been done elsewhere. He also indicated that he felt we should stay close to the IEEE specs. The high level organization of the MIB was presented. It was organized into three main areas, Transparent Bridge, Spanning Tree, and Source Routing. Anil Rijsinghani presented the MDLR proposal. He explained the structure of the MIB, as laid out on page 6 of the document, and explained that, for the most part, it covered IEEE 802.1d Bridges. Bob Stewart asked that we keep in mind the network manager, the human kind, in our discussion. This precipitated a discussion of the definition of network management. 1 After numerous folks had their say about the true meaning of network management, it was proposed that each camp talk about the differences between the two proposals. The main differences, other than organization, were in the Source Routing area. A discussion revolved around the source routing cache table. The MDLR proposal had none, and the Fox proposal had an optional table. These points were made primarily by Keith McCloghrie and Richard Fox. Another difference claimed by Richard Fox is that his MIB has multi-port source routing capability, which explained why his MIB works and the other MIB fails. Fred Baker talked about the use of the Target Segment to do multi-port bridging via a ``virtual ring'' in the bridge. Anil Rijsinghani pointed out the the real question here was whether an implementation should be inferred by the MIB. Keith McCloghrie noted that a significant difference is the size of the MIB, the MDLR MIB having 70 odd variables and the Fox MIB having 132. There was some confusion about the exact number, but Richard Fox said that he included more than necessary with the hope of removing useless variables as part of the RFC process. The discussion of the respective MIB proposals ended there, with Bob Stewart and Maurice Turcotte both making the points that the MLDR MIB was more mature, largely due to the Knoxville meeting, and that the Fox MIB had more strength in the source routing area. The respective authors were allowed to leave the room, and a consensus was reached in their absence. We agreed to continue with the MLDR draft and invite Richard Fox to be added as an author, if he wanted to contribute to the document. His expertise in Source Routing was acknowledged and solicited. We then attempted to move on to the objects. First, however, a discussion of the Bridge/Router model errupted. This contentious issue became apparent when the relationship between the ifTable counts and the bridge port counts was brought up for discussion. It took the remainder of the morning session and a good deal of the afternoon session to agree to disagree. The one point that seemed unanimous, however, was that counts on an interface could not replace the counts on a bridge port. In other words, ifInOctets in MIB I/II may not have anything to do with bridgePortInOctets, if such a thing existed, which it doesn't. There were two interconnected architectural issues involved in the Bridge/Router model discussions. The first addresses the question ``Where is the ifTable?''. The second deals with the question, ``Where are packets counted?''. 2 A small but vociferous group maintained the the MIB I/II if group is between layers and not necessarily associated with hardware. In the bridge case, the ifTable variables refer to traffic destined for this bridge, and traffic that is forwarded by the bridge should not be counted in the ifTable. The picture looks like this: ---------- | IP | ---------- /\ / \ / \ / \ / \ ----- ----- | if | | if | --------------- | bridge | --------------- | 802 | | 802 | ----- ----- The rationale for this picture is that the ifTable is intended to count traffic that is destined for the local Network Element and that bridged traffic is merely passed on by the MAC layer. 3 In the process of tossing this idea around, another picture emerged: ---------- | IP | ---------- /\ / \ / \ / \ / \ ----- ----- | if | | if | --------------- | bridge | --------------- | if | | if | ----- ----- | 802 | | 802 | ----- ----- The difference here is that there are interfaces (ifTableEntries) both above and below the bridge layer. Some attendees liked this picture. The remainder, and the majority, favored one of these two pictures: ---------- | IP | --------------- | bridge | --------------- | if | | if | ----- ----- | 802 | | 802 | ----- ----- 4 or -------- ------ | bridge | IP | -------- ------ | \ / | | \ / | | X | | / \ | | / \ | ----- ----- | if | | if | ----- ----- | 802 | | 802 | ----- ----- The main point here is that the ifTable counts all traffic that is received or transmitted by the 802.x port. For a bridge this means an Ethernet chip put in promiscuous mode receives and counts a LOT of traffic. The difference between the two previous pictures illustrates the second issue. There were three camps present. The first thought that all traffic entering a bridge should be directed to the bridge software. This means that the counts on a bridge port basis are redundant, and the ifTable counts in MIB I/II are sufficient. The picture: ---------- | IP | --------------- | bridge | --------------- | if | | if | ----- ----- | 802 | | 802 | ----- ----- The second point of view was that locally destined packets, from the bridge point of view, should not be counted in the bridge software instrumentation, largely because the bridge software never sees this traffic. This traffic may be forwarded by a higher layer, such as a router or trap exploder. The point is that each incoming packet goes to 5 one and only one software layer, even if it is a multicast. The picture: -------- /| bridge | / -------- ---- / ---- | if | -----| IP | ---- \ ---- \ \ ------------------- | other Application | ------------------- The third point of view held that incoming traffic, multicast in particular, may be directed, and counted, in more than one software module. The same picture applies, with the distinction that the paths are shared. The architectural issues were discussed at great length, and closure was not reached. It was decided to carry on the discussion via mail on the net. The final topic discussed in the afternoon had to do with filtering. Fred Baker gave an overview of the IEEE 802.1d definition, and then reviewed the proposal that was put out on the net as a result of the Knoxville meeting. It was pointed out that everyone does filtering in their own way and reaching consensus may be impossible and best left up to the enterprise MIBs. Bob Stewart suggested that an alternative was to define every possible type of filter and use an Object ID to define which one is used by this bridge. Anil Rijsinghani presented the IEEE 802.1d approach and argued for including it as an optional table. A suggestion was also made that it might be extended to include source addresses. A consensus was reached to include this table as Optional, without source addresses. This represents a middle ground between camps wanting no static filtering, 802.1 static filtering, and rather complete source and destination address filtering. 6 It was also agreed to include the number of ports as part of the MIB. It was agreed that static and permanent forwarding table entries appeared the same in the MIB. The distinction is that permanent entries are saved on some reliable storage medium and present at startup. For the bridge MIB there is no distinction. Attendees Karl Auerbach karl@eng.sun.com Fred Baker fbaker@acc.com Terry Bradley tbradley@wellfleet.com Theodore Brunner tob@thumper.bellcore.com Jeffrey Buffum jbuffum@apollo.hp.com Chris Chiotasso chris@roswell.spartacus.com Anthony Chung anthony@hls.com James (Chuck) Davin jrd@ptt.lcs.mit.edu Nadya El-Afandi nadya@network.com Gary Ellis garye@hpspd.spd.hp.com Richard Fox sytek!rfox@sun.com Frank Kastenholz kasten@interlan.com Shimshon Kaufman Jim Kinder jdk@fibercom.com Cheryl Krupczak clefor@secola.columbia.ncr.com Peter Lin lin@eng.vitalink.com Keith McCloghrie kzm@hls.com Donna McMaster mcmaster@davidsys.com David Perkins dave_perkins@3com.com Jim Reinstedler jimr@ub.com Anil Rijsinghani anil@levers.enet.dec.com Bob Stewart rlstewart@eng.xyplex.com Emil Sturniolo Maurice Turcotte dnmrt@rm1.uucp Fei Xu fei@tdd.sj.nec.com 7