NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98
Chair(s):
Keith McCloghrie <kzm@cisco.com>
Operations and Management Area Director(s):
Harald Alvestrand <Harald.Alvestrand@maxware.no>
Bert Wijnen <wijnen@vnet.ibm.com>
Operations and Management Area Advisor:
Bert Wijnen <wijnen@vnet.ibm.com>
Mailing Lists:
General Discussion:bridge-mib@external.cisco.com
To Subscribe: bridge-mib-request@cisco.com
Archive: ftp://ftpeng.cisco.com/ftp/kzm/bridgemib/list-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. |
Jan 99 |
|
Submit a new MIB document with support for recently developed 802.1 specifications to the IESG for consideration as a Proposed Standard. |
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 42nd IETF meeting
Chicago, August 1998
Bridge Working Group
Minutes recorded by Les Bell
RFC 1525
Keith McCloghrie gave an overview of the status of RFC 1525 and a proposal for how to
move it to a full standard. Response from the mailing list indicated that Cisco and IBM
have implemented this MIB, though not fully. It is proposed to deprecate those items that
have not been implemented, and to optionally allow all read-write items to be implemented
as read-only. It is not proposed to re-write this MIB in SMIv2 syntax.
Bridge-MIB Extensions
Changes in ietf-bridge-bridgemib-draft-01.txt
The changes since the previous draft were reviewed, with the opportunity for the group to
comment on the issues before they are closed. The group accepted the changes in the
current draft with the following comments:
Issue 31
- VLAN Bridge up-time - it was noted that it would be easy to implement this per-
VLAN, but the group decided not to change the current draft.
Issue 33
- The compliance clauses for the service requirements objects are to be defined as an
optional group, instead of with "MIN-ACCESS not-accessible".
Bridge-MIB Extensions
Open Issues in ietf-bridge-bridgemib-draft-01.txt
- The open issues without proposed resolutions in this draft were discussed, with
recommendations (from Andrew) for closing them.
Issue 5
- Use of the ifStackTable - a proposal on how this should be used, complementing
the Q-BRIDGE-MIB, should be made to the mailing list. Feedback from this
proposal should be added to section 3.4.2.2 of the next draft.
Issue 50
- The range restrictions should be removed from dot1qVlanFdbId,
dot1qMaxSupportedVlans and dot1qNumVlans.
Issue 51
- dot1qConfigurablePvidTagging - the description of this object should be modified
to indicate that attempts to set more than one VLAN to be untagged on egress may
be rejected by devices which do not support this option.
Issue 55
- dot1qStaticUnicastAllowedToGoTo should not be split into 'Fixed' and 'Forbidden'
port lists. No change is required.
Issue 56
- The value of '0' for dot1qTpFdbPort is required to indicate an address may defined
in the static table, but has not been learnt on any port yet. No change is required.
Issue 57
- Change dot1qVlanStaticUntagged to dot1qVlanStaticUntaggedPorts as proposed.
Issue 58
- The value of dot1qVlanStaticName does not need to be unique, as proposed. No
change is required.
Issue 59
- dot1qPvid should have syntax 'VlanIndex' (instead of 'VlanId') as proposed.
Issue 60
- Clarify the descriptions of dot1qPortAcceptableFrameTypes and dot1qPortIngressFiltering
to indicate they also apply to GMRP packets.
Issue 61
- dot1qLearningContraintsLastChange should be removed.
Issue 62 (not in the current draft)
- The proposal to remove support for multiple egress ports in static unicast FDB
entries is not applicable, as they indicate ports the address MAY be learnt on, not
ports they MUST be forwarded to. No change is required.
Issue 44
- It was agreed that {per-port, per-VLAN} counters are useful, but the full set defined
by 802.1Q is not required. A subset similar to the per-port counters defined by RFC
1493 should be adopted: dot1qTpVlanPortInFrames, dot1qTpVlanPortOutFrames and
dot1qTpVlanPortInDiscards. 'InDiscards' does not include error frames.
'DiscardOnIngressFiltering' is not counted. 'DelayExceeded' is only counted per-port
(RFC1493). Optional 64-bit and 32-bit versions are to be defined. These counters
apply to transparent and SRT bridges
Issue 49
- A new object should be added for the 'next free vlan index' available for local vlans
without a standard 802.1Q vlan tag. The value of this object may be read by a manager
and used to create a new local vlan entry. This value will automatically change when
the current value is used.
Issue 52
- An explicit "dot1dExtendedFilteringServicesStatus" is not required to enable/disable
this feature. This can already be achieved by disabling GMRP and providing
appropriate entries in the dot1qForwardAllTable. No change is required.
Bridge-MIB Extensions
New Issues with ietf-bridge-bridgemib-draft-01.txt
David Melman raised the following issues, with the promise of more to come on the
mailing list.
Issue 72 (not in the current draft)
- The default value for 'dot1qForwardAllStaticPorts' is defined as 'a string of ones
of appropriate length'. The description needs to be clarified to indicate this applies
only to ports in the vlan for each entry. This applies to several of the PortList
objects in the MIB.
Issue 76 (not in the current draft)
- The statistics counted per-port/per-VLAN can be excessive, so it was suggested that
a control table could be defined, in which the manager could define a sub-set of the
port/VLAN combinations for statistics to be collected. The group did not seem to think
this was worthwhile.
RFC 1493
- Keith McCloghrie will poll for implementation experience on the mailing-list, and
many folks volunteered to respond.