NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 27-Mar-98
Chair(s):
Keith McCloghrie <kzm@cisco.com>
Operations and Management Area Director(s):
John Curran <jcurran@bbnplanet.com>
Michael O'Dell <mo@uu.net>
Operations and Management Area Advisor:
John Curran <jcurran@bbnplanet.com>
Mailing Lists:
General Discussion:bridge-mib@external.cisco.com
To Subscribe: bridge-mib-request@cisco.com
Archive:
Description of Working Group:
The Bridge MIB Working Group is chartered to define a set of managed objects that instrument devices that conform to the IEEE 802.1 standard for MAC-layer bridges.
This set of objects should be largely compliant with (and even draw from) IEEE 802.1(b), although there is no requirement that any specific object be present or absent.
The MIB object definitions produced will be for use by SNMP and will be consistent with other SNMP objects, standards, and conventions.
Goals and Milestones:
Done |
|
Publish initial proposal. |
Done |
|
Submit an Internet-Draft. |
Done |
|
Submit draft for RFC publication. |
Done |
|
Publish a draft SNMP MIB that instruments functions specific to source routed bridges as an Internet-Draft. |
Done |
|
Publish a draft revision to RFC 1286 that reflects implementation experience and the result of alignments with IEEE work as an Internet-Draft. |
Done |
|
Submit a draft MIB for source routing bridge functions to the IESG for consideration as a Proposed Standard. |
Aug 98 |
|
Evaluate status of RFC 1493 and report to the IESG if it should be recycled at Draft or can be elevated to Full Standard. |
Aug 98 |
|
Evaluate status of RFC 1525 and report to the IESG if it should be recycled at Proposed or can be elevated to Draft Standard. |
Sep 98 |
|
Submit a new MIB document with support for recently developed 802.1 specifications to the IESG for consideration as a Proposed Standard. |
No Current Internet-Drafts
Request For Comments:
RFC |
Status |
Title |
RFC1493 |
DS |
Definitions of Managed Objects for Bridges |
RFC1525 |
PS |
Definitions of Managed Objects for Source Routing Bridges |
Minutes of the Bridge MIB (bridge) Working Group
The Chair, Keith McCloghrie, started the meeting with administrivia. One of the important items was to give the correct mailing list information.
Mail list : bridge-mib@external.cisco.com
Subscribe : bridge-mib-request@cisco.com
Keith then went over the agenda for the meeting. For Keith's slides, see: ftp://ftpeng.cisco.com/ftp/kzm/bridgemib/april98/kzm-slides.ps
An item was added to cover the relationship of VLANs and SMON. SMON has already done some work to cover VLANs.
Keith listed the two reasons to re-activate the WG.
1) RFC1493 (Bridge MIB) and RFC1525 (Source Routing MIB) still valid, have been implemented, etc.
2) New features from IEEE 802.1 that need MIBs (.1p/.1Q).
1493 is still valid for "old" 1D bridges that are not VLAN aware. But there are issues with using 1493 as is, for VLAN aware bridges (FdbTable and StaticFilterTable). More on this later.
Do we make these tables optional for .1Q bridges? If not, how are they used?
Keith asked for feedback on the current 1493.
"Who has implemented 1493?" Some vendors have implemented it in multiple products. The Area Director agreed that this was more than sufficient indication that the MIB meets the criteria for elevation to Full Standard as set out in RFC 2026.
ACTION ITEM for the Chair : "Present the evidence that 1493 has been implemented by multiple vendors."
Jeff Case stated that he heard complaints that there were not enough notifications.
ACTION ITEM for Jeff: Get more specific input. What notifications were requested.
There was some discussion about the need to index the FDB by MAC address. Andrew Smith felt that this is not required and puts a large burden on switches since most hardware doesn't keep the table in lexigraphical order (therefore these switches keep a copy of the table in RAM in order...if you have 128K MAC address, this can be expensive.) Others in the room agreed it was a burden but a necessary one to allow the efficient search for a specific MAC address in the FDB. Andrew would like to index the FDB by some integer instead.
We discussed converting RFC1493 to SNMPv2. Keith felt that this was just "busy work." You cannot simple convert to V2 without going through the whole standards process, despite it being largely an editorial exercise. This is a generic issue to many RFCs therefore this was referred to the SNMPv3 Working Group. There are no current plans to convert the Bridge RFCs to V2.
Keith asked if vendors have implemented RFC1525. Just a few hands (Cisco and IBM). Fred Baker has asked this question in the past with no response. The question needs to be re-raised with the results clearly presented.
The chair of SMON, Andy Bierman, discussed briefly some of the relationships between VLANs and SMON.
ACTION ITEM to all : Read SMON (draft-ietf-rmonmib-smon-04.txt).
Andrew Smith presented slides about 802.1Q and 802.1p. See:
ftp://ftpeng.cisco.com/ftp/kzm/bridgemib/april98/andrew-smith-slides.p
(GARP - Generic Attribute Registration Protocol
GVRP - GARP VLAN Registration Protocol
GMRP - GARP Multicast Registration Protocol)
Fred Baker mentioned that there might be a patent from Lucent for GVRP and/or GARP. But, either way, this is not an issue for a MIB.
Andrew explained about FIDs (Forward Database Indentifiers) and GVRP. There are two models:
1) 1 single FDB that is used by ALL VLANs defined in the switch, this is called SVL for Shared VLAN Learning.
2) 1 FDB per VLAN (or really 1 FDB with a lookup key of MAC + VLAN_ID). This is called IVL for Independent VLAN Learning.
A switch may implement either one or a combination of these two models.802.1Q (and the proposed MIB) has a set of rules for configuring this.
GVRP is a protocol used in .1Q to automatically determine where VLANs are to be forwarded.
We then discussed the relationship of VLANs and the ifTable. Each physical port will still have its own ifEntry. But what about VLANs? Andrew had two models in his slides:
1) Each virtual bridge port has an ifEntry. This has some serious scaling issues (100 port switch with 4K VLANs would need 1,000s of ifEntries.)
2) Each VLAN has an ifEntry. Perhaps, this could be like the "virtual interface" ifTable entry that the existing bridge MIB models for management packets? That is, a VLAN could be modeled as an interface onto each virtual bridge.
SMON tried to use the ifStackTable at first but then decided to wait for the Bridge WG to attack the issue.
There is also a difficulty representing 802.1Q's notion that a VLAN can egress onto a physical port even when it cannot ingress from that port (and vice-versa). Neither the ifTable nor the ifStackTable have this concept of "one-way" connectivity.
VLAN IDs : Andrew questioned whether the VLAN ID (VID) is a good indexing variable into the VLAN Table because he wants to model virtual 802.1D bridges, that have no VID, with this same table. He proposed using the ifIndex of the VLAN (assuming that an ifIndex is assigned to a VLAN.)
He would like the ability to create VLANs that are local to a single switch without having to use one of the 4,094 VIDs. However, it was noted that using the VID as the index allows for simpler SNMP queries on the VLAN Table if the requestor is looking for information about a specific VLAN with a global VID, but has no effect for a requestor querying by VLAN-name.
Another solution proposed was to use VIDs with a value greater then 4,096 for "local" VLANs, i.e., VLANs which are not tagged on any ports, and are not registered by GVRP.
What to do with RFC1493 objects?
Dynamic FDB : We could store ALL MACs from ALL VLANs. This has a problem in that an IVL switch allows the same MAC address to be on different ports in different VLANs. The only suggestion
for representing this in the 1493 FDB was to show the MAC address on the "latest" port learnt, by some definition of "latest."
StaticTable: Similar problem. In an IVL switch, which FID does the entry apply to?
The purpose of trying to keep these objects is to allow an old NMS to manage these new .1Q switches. But we have to be careful not to mislead the NMS.
With time running out, Andrew concluded by just listing the other issues he had (see his slides).
We agreed to the make the current draft from Les Bell (et. al.) the WG draft.
An update will be coming from Les in a few weeks. He is also working on converting this draft to SMIv2.
Schedule
We agreed to hold an interim meeting, and to defer the scheduled WG agreement on the new MIB until the December 98 meeting.
BRIDGE MIB - Administrivia
BRIDGE MIB - Extensions to RFC1493