draft-ietf-bridge-bridgemib-02.txt   draft-ietf-bridge-bridgemib-03.txt 
Internet Draft E.L. Bell Internet Draft E.L. Bell
Expires April 1999 3Com Corp. Expires May 1999 3Com Corp.
draft-ietf-bridge-bridgemib-02.txt A. Smith draft-ietf-bridge-bridgemib-03.txt A. Smith
Standards Track Extreme Networks Standards Track Extreme Networks
P. Langille P. Langille
Acacia Networks Acacia Networks
A. Rijhsinghani A. Rijhsinghani
Cabletron Systems Cabletron Systems
K. McCloghrie K. McCloghrie
cisco Systems cisco Systems
October 1998 November 1998
Definitions of Managed Objects for Bridges with Traffic Definitions of Managed Objects for Bridges with Traffic
Classes, Multicast Filtering and Virtual LAN Extensions Classes, Multicast Filtering and Virtual LAN Extensions
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working its Working Groups. Note that other groups may also distribute working
documents as Internet Drafts. documents as Internet Drafts.
skipping to change at page 4, line 46 skipping to change at page 4, line 46
consistent with the spirit of the SNMP Framework, a subjective judgement consistent with the spirit of the SNMP Framework, a subjective judgement
was made to omit the objects from those standards most 'costly' to was made to omit the objects from those standards most 'costly' to
implement in an agent and least 'essential' for fault and configuration implement in an agent and least 'essential' for fault and configuration
management. The omissions are described in section 3 below. management. The omissions are described in section 3 below.
Historical note: Historical note:
RFC 1493 used the following principles for determining inclusion of an RFC 1493 used the following principles for determining inclusion of an
object in the BRIDGE-MIB module: object in the BRIDGE-MIB module:
(1) Start with a small set of essential objects and add only as further (1) Start with a small set of essential objects and add only as
objects are needed. further objects are needed.
(2) Require objects be essential for either fault or configuration (2) Require objects be essential for either fault or configuration
management. management.
(3) Consider evidence of current use and/or utility. (3) Consider evidence of current use and/or utility.
(4) Limit the total of objects. (4) Limit the total of objects.
(5) Exclude objects which are simply derivable from others in this or (5) Exclude objects which are simply derivable from others in this or
other MIBs. other MIBs.
(6) Avoid causing critical sections to be heavily instrumented. The (6) Avoid causing critical sections to be heavily instrumented. The
guideline that was followed is one counter per critical section per guideline that was followed is one counter per critical section
layer. per layer.
3. Structure of MIBs 3. Structure of MIBs
This document defines additional objects, on top of those existing in This document defines additional objects, on top of those existing in
the base BRIDGE-MIB module defined in RFC1493: that MIB module is the base BRIDGE-MIB module defined in RFC1493: that MIB module is
maintained unchanged for backwards compatibility. Section 3.4.3 of the maintained unchanged for backwards compatibility. Section 3.4.3 of the
present document contains some recommendations regarding usage of present document contains some recommendations regarding usage of
objects in RFC1493 by devices implementing the enhancements defined objects in RFC1493 by devices implementing the enhancements defined
here. here.
Two MIB modules are defined here: Two MIB modules are defined here:
(1) Managed objects for an extended bridge MIB module P-BRIDGE-MIB for (1) Managed objects for an extended bridge MIB module P-BRIDGE-MIB
the traffic class and multicast filtering enhancements defined by for the traffic class and multicast filtering enhancements
IEEE 802.1D-1998. defined by IEEE 802.1D-1998.
(2) Managed objects for a virtual bridge MIB module Q-BRIDGE-MIB for (2) Managed objects for a virtual bridge MIB module Q-BRIDGE-MIB for
the Virtual LAN bridging enhancements defined by IEEE 802.1Q-1998. the Virtual LAN bridging enhancements defined by IEEE
802.1Q-1998.
3.1. Structure of Extended Bridge MIB module 3.1. Structure of Extended Bridge MIB module
Objects in this MIB are arranged into groups. Each group is organized Objects in this MIB are arranged into groups. Each group is organized
as a set of related objects. The overall structure and assignment of as a set of related objects. The overall structure and assignment of
objects to their groups is shown below. objects to their groups is shown below.
3.1.1. Relationship to IEEE 802.1D-1998 Manageable Objects 3.1.1. Relationship to IEEE 802.1D-1998 Manageable Objects
This section contains a cross-reference to the objects defined in IEEE This section contains a cross-reference to the objects defined in IEEE
skipping to change at page 18, line 21 skipping to change at page 18, line 21
(2) Added support for multiple traffic classes and dynamic multicast (2) Added support for multiple traffic classes and dynamic multicast
filtering as per IEEE 802.1D-1998. filtering as per IEEE 802.1D-1998.
(3) Added support for bridged Virtual LANs as per IEEE 802.1Q-1998. (3) Added support for bridged Virtual LANs as per IEEE 802.1Q-1998.
(4) Added support for 64-bit versions of existing RFC1493 port (4) Added support for 64-bit versions of existing RFC1493 port
counters. counters.
5. Change Log and Editorial Stuff 5. Change Log and Editorial Stuff
5.1. Changes since draft-ietf-bridge-bridgemib-01.txt [Editor: this section will be removed before publication.]
Traffic Classes:
Split into separate conformance groups, according to the
requirements for the supported media. Descriptions and
capabilities updated to reflect this.
Statistics:
Simplified to be more like RFC1493.
VID and FID: 5.1. Changes since draft-ietf-bridge-bridgemib-02.txt
Restrictions removed to allow local identities outside of the
802.1Q range.
SMIv2 conformance: SMIv2 conformance:
Replaced INTEGER with 'UInteger32' (where no range was specified). Replaced 'UInteger32' with 'Unsigned32'. Replaced 'BIT STRING'
Replaced 'Timeout' with 'TimeInterval'. with 'BITS'. Import 'MacAddress' from RFC1903 (SNMPv2-TC) instead
of RFC1493 (BRIDGE-MIB).
New objects added:
dot1qTpVlanPortInFrames, dot1qTpVlanPortOutFrames,
dot1qTpVlanPortInDiscards, dot1qTpVlanPortHCInFrames,
dot1qTpVlanPortHCOutFrames, dot1qTpVlanPortHCInDiscards,
dot1dTrafficClasses, dot1dTrafficClassPriority,
dot1qNextFreeLocalVlanIndex
Old objects deleted:
dot1qFramesReceived, dot1qOctetsReceived, dot1qForwardOutbound,
dot1qDiscardInbound, dot1qDiscardNoBuffers,
dot1qDiscardTransitDelayExceeded, dot1qDiscardError,
dot1qDiscardOnIngressFiltering, dot1qHCFramesReceived,
dot1qHCOctetsReceived, dot1qHCForwardOutbound,
dot1qHCDiscardInbound, dot1qHCDiscardNoBuffers,
dot1qHCDiscardTransitDelayExceeded, dot1qHCDiscardError,
dot1qHCDiscardOnIngressFiltering,
dot1qLearningConstraintsLastChange
Objects renamed/moved:
dot1qTpGroupAllowedToGoTo -> dot1qTpGroupEgressPorts
dot1qVlanStaticUntagged -> dot1qVlanStaticUntaggedPorts
dot1dPortCapabilities.dot1qConfigurablePvidTagging
-> dot1dDeviceCapabilities.dot1qConfigurablePvidTagging
Object descriptions clarified: Object descriptions clarified:
dot1dPortDefaultUserPriority, dot1dUserPriorityRegenTable, dot1dTpHCPortInDiscards, dot1qTpVlanPortInDiscards,
dot1dTrafficClassTable, dot1qGvrpStatus, dot1qTpGroupEgressPorts, dot1qTpVlanPortHCInDiscards
dot1qForwardAllStaticPorts, dot1qStaticUnicastAllowedToGoTo,
dot1qStaticMulticastStaticEgressPorts,
dot1qStaticMulticastForbiddenEgressPorts, dot1qVlanStatus,
dot1qVlanStaticName, dot1qVlanStaticUntaggedPorts,
dot1qPortAcceptableFrameTypes, dot1qPortIngressFiltering,
dot1qGvrpPortStatus
Updated compliance clauses:
pBridgeDeviceGmrpGroup, pBridgeDevicePriorityGroup,
pBridgeDefaultPriorityGroup, pBridgeRegenPriorityGroup,
pBridgePriorityGroup, pBridgeAccessPriorityGroup,
qBridgeFdbUnicastGroup, qBridgeVlanGroup, qBridgeVlanStaticGroup,
qBridgeVlanStatisticsGroup, qBridgeVlanHCStatisticsGroup,
qBridgeLearningConstraintsGroup
New issues: (62)-(77) added.
To Do List (1): New issues 78-80
Update boilerplate for appropriate new SNMP framework(s). - SNMP
Framework (section 1), Security (section 10) and References updated
to comply with proposed new SNMPv3 guidelines.
Editorial: Editorial - updated REVISION dates
References updated to latest document versions, other editorial
changes.
5.2. Open Issues 5.2. Open Issues
The following issues were raised on the mailing list after the Plenary (80) Definition of dot1qTpVlanPortInDiscards and
meeting in Chicago, IL in August 1998. These issues have not been dot1qTpVlanPortHCInDiscards is inconsistent with counters in IEEE
addressed in this draft. 802.1Q-1998 and is underspecified (AHS)
(77) Should dot1qTpVlanPortInDiscards and dot1qTpVlanPortHCInDiscards
count all frames discarded at receive by the VLAN layer? (AR) -
Assume NO for now.
5.3. Issues closed in this draft 5.3. Issues closed in this draft
The following issues were still open after the Plenary meeting in The following issues were raised on the mailing list since publication
Chicago, IL in August 1998. New issues raised on the mailing list after of the previous draft. Suggested resolutions discussed on the mailing
the Chicago meeting are also included. Suggested resolutions discussed list are noted here and the changes have been made to the text - they
on the mailing list are noted here and the changes have been made to the are listed here for comment:
text - they are listed here for comment:
(5) ifStackTable usage - how to represent binding of IP interfaces to
VLANs now that we do not necessarily have one ifEntry per VLAN. -
Not included due to lack of enthusiasm from the group.
(62) Remove support for multiple egress ports in static unicast FDB
entries? (KK) - Not applicable. The entry indicates ports a
unicast address MAY be learnt on, not ports it MUST be forwarded
to. Description clarified.
(63) dot1dGmrpStatus is a member of a mandatory group and has a DEFVAL
of "enabled". This is inappropriate for devices which do not
support extended filtering services but do support priority
forwarding and therefore implement this MIB. (DM) - Similar
problem with dot1dTrafficClassesEnabled. Defined both of these in
separate groups, each group is mandatory only if that feature is
supported by the bridge. Capabilities bit added to indicate
support for traffic classes. Removed MIN-ACCESS for
dot1dTrafficClassesEnabled.
(64) dot1dPortCapabilities, dot1qPortIngressFiltering - tighten up the
text to read: "supports the discarding of any frame received on
that Port whose VLAN classification does not include that Port in
its Member set." (DM) - Done. Also changed the name of the
capability bit for this to dot1qIngressFiltering to resolve
duplicate name. Changed the description of
dot1qPortIngressFiltering object to match the above text.
(65) dot1qConfigurablePvidTagging - According to 802.1Q it is a
requirement. Is there a reason to treat it as optional in the MIB?
(DM) - Reference is 12.10.1.1.3/b/2. The 802.1Q description is
"whether the implementation supports the ability to override the
default PVID setting and its egress status (VLAN-Tagged or
Untagged) on each port". Capability description modified with the
above quote from the standard.
(66) PVID tagging should be moved from dot1dPortCapabilities to
dot1dDeviceCapabilities. (AHS) - Done.
(67) dot1dUserPriorityRegenTable - is not relevant for Ethernet LANs. A
statement to this effect and a reference (ISO/IEC 15802-3 6.4) may
be helpful. (DM) - Done. Also put this in a separate conformance
group, mandatory for media which support native User Priority.
dot1dTrafficClassTable updated to be independent of this table.
(68) What should the compliance be for dot1dPortDefaultUserPriority?
(AHS) - Put this in a separate conformance group, mandatory for
media which do not support native User Priority.
(69) There are no definitions for qBridgeFdbGroup or qBridgeTpFdbGroup -
remove references to these in qBridgeCompliance section. (AHS) -
Done.
(70) Should we count the number of dynamic group address entries per
VLAN? (AHS) - This can be derived by counting rows in
dot1dTpGroupTable. Added it to the 'not included' list in section
3.2.1.
(71) dot1qTpGroupAllowedToGoTo really means 'forward to'. (DM) - The
description has been clarified and the object renamed as
'dot1qTpGroupEgressPorts'.
(72) Why provide a default value for dot1qStaticUnicastAllowedToGoTo?
It should include only member ports of the frame's VLAN
classification. The phrase "a string of ones" is incorrect. Also
for dot1qStaticMulticastStaticEgressPorts. (DM) - Clarified the
description, this value only applies to ports also in the
dot1qVlanCurrentEgressPorts list for the VLAN. Also applied this
clarification to dot1qForwardAllStaticPorts.
(73) dot1qStaticUnicastAllowedToGoTo: why is the term "allowed" used
here? Doesn't this object define exactly to which port(s) the
frame is to be forwarded? (DM) - No. The consensus from recent
discussions interpret this as 'may be dynamically learnt on'.
Clarified the description.
(74) The Untagged Set for a VLAN is only modified statically by
management and this object will always have the same value as the
dot1qVlanStaticUntagged. If so, should it be eliminated. (DM) -
Untagged VLANs may also be dynamically learned. No change
required.
(75) The meaning of dot1qVlanStatus is confusing. (DM) - The description
has been clarified.
(76) dot1qVlanStatisticsTable potentially requires a very large number
of counters and may not be achievable in many architectures. A
control table which specifies for which VLANs the counters would be
maintained could limit the number of counters required. (DM) - Not
considered worthwhile. No change required.
Issues that were closed at the August 1998 plenary meeting and have been
addressed in this draft:
(44) Clarification of dot1qHC counter descriptions - what does inbound
mean? What counts as errors? 2 separable issues:
1. It was requested that the meaning of dot1qDiscardInbound be
clarified to ensure it is distinct from other counters.
(Specifically, why is it different from 1493?) (KZM) - this can be
derived from other counters - NUKE IT!
2. Why are all of these so different from RFC1493? e.g. do they
refer to Transparent-only? What about SRT or SR? - Counters
limited to a set equivalent to RFC1493.
(49) Now that dot1qVlanStaticTable is indexed by VlanIndex/VlanId we
need a "next free" variable since these values must be managed by
agent. - Added dot1qVlanNextFreeIndex.
(50) dot1qVlanFdbId, dot1qMaxSupportedVlans, dot1qNumVlans should not be
range-limited. If they are then we need new objects to represent
the number of non-802.1Q "VLANs" too. (AHS) - Range restrictions
removed.
(51) dot1qConfigurablePvidTagging: does this also cover the "I can only
set a single VLAN to be untagged on egress" implementation option
in 802.1Q? - Description of dot1qVlanStaticUntaggedPorts clarified
to cover this.
(52) Do we need an explicit "dot1dExtendedFilteringServicesStatus"
enable/disable object? (AHS) - No.
(55) Need to split dot1qStaticAllowedToGoTo into two portmaps in order
to represent the 3 possible states from 802.1Q 8.11.2: static,
forbidden and allowed to be influenced by dynamic info. (ELB) DONE
for multicast - split dot1qStaticAllowedToGoTo into
dot1qStaticMulticastStaticEgressPorts and
dot1qStaticMulticastForbiddenEgressPorts. Same issue for unicast
table. - Not required to split this for unicast.
(56) Should a value of 0 be allowed for dot1qTpFdbPort? This is
inherited from RFC1493. (ELB) - Yes it is allowed. No change
required.
(57) Rename dot1qVlanStaticUntagged as dot1qVlanStaticUntaggedPorts for
consistency. (ELB) - Done.
(58) If an empty string is used for dot1qVlanStaticName, does it have to
be unique? The description implies it must be unique. (ELB) NO -
clarified this.
(59) Should dot1qPvid have syntax VlanIndex (currently it is VlanId)? (77) Should dot1qTpVlanPortInDiscards and dot1qTpVlanPortHCInDiscards
(ELB) - Yes, done. count all frames discarded at receive by the VLAN layer? (AR) -
YES: descriptions updated.
(60) Do dot1qPortAcceptableFrameTypes and dot1qPortIngressFiltering also (78) Some SMIv2/syntax errors: UInteger32 should be Unsigned32, BIT
apply to tagged GMRP packets? (ELB) - Yes, descriptions clarified. STRINg should be BITS. FIXED.
(61) Do we need dot1qLearningContraintsLastChange? It just reminds the (79) MacAddress should be imported from RFC1903, not RFC1493. FIXED.
manager of changes that he or some other manager made. (ELB) - No,
object removed.
5.4. Issues closed in previous drafts 5.4. Issues closed in previous drafts
(1) Should this MIB offer support for SMIv1-only agents (Counter32/64)? (1) Should this MIB offer support for SMIv1-only agents (Counter32/64)?
ADDED Counter32/Counter64 versions of the per-VLAN statistics. ADDED Counter32/Counter64 versions of the per-VLAN statistics.
ADDED Counter64 versions of the per-port statistics from RFC1493. ADDED Counter64 versions of the per-port statistics from RFC1493.
Added appropriate conformance clauses for all. Added appropriate conformance clauses for all.
(2) Indexing of tables by VlanId or by ifIndex? use VlanId with special (2) Indexing of tables by VlanId or by ifIndex? use VlanId with special
semantics for values >=4096. This raises new issue 49. semantics for values >=4096. This raises new issue 49.
(3) Indexing of FDB tables by MacAddress or by something else? Use (3) Indexing of FDB tables by MacAddress or by something else? Use
MacAddress. MacAddress.
(4) Include RFC1493 by value or reference? REFERENCE (4) Include RFC1493 by value or reference? REFERENCE
(5) ifStackTable usage - how to represent binding of IP interfaces to
VLANs now that we do not necessarily have one ifEntry per VLAN. -
Not included due to lack of enthusiasm from the group.
(6) Representations of filtering entry for "AllGroups" and (6) Representations of filtering entry for "AllGroups" and
"AllUnregisteredGroups" DONE "AllUnregisteredGroups" DONE
(7) Should we represent all available FIDs up front or use a "next (7) Should we represent all available FIDs up front or use a "next
free" object for the manager to create them as needed? NEITHER - free" object for the manager to create them as needed? NEITHER -
see issue 25 above. see issue 25 above.
(8) Learned entry discards counter per-VLAN or per-device? Per-device, (8) Learned entry discards counter per-VLAN or per-device? Per-device,
already in RFC1493. already in RFC1493.
skipping to change at page 27, line 13 skipping to change at page 22, line 43
NVRAM - Leave it the same. NVRAM - Leave it the same.
(41) MIN-ACCESS read-only for dot1dTrafficClass, dot1dRegenUserPriority (41) MIN-ACCESS read-only for dot1dTrafficClass, dot1dRegenUserPriority
(KZM) - done. (KZM) - done.
(42) dot1qTpGroupGmrp/Igmp (KZM) - merge these to dot1qTpGroupLearnt - (42) dot1qTpGroupGmrp/Igmp (KZM) - merge these to dot1qTpGroupLearnt -
Yes. Yes.
(43) Do we need 64-bit dot1qHC errors? (KZM) - Yes. (43) Do we need 64-bit dot1qHC errors? (KZM) - Yes.
(44) Clarification of dot1qHC counter descriptions - what does inbound
mean? What counts as errors? 2 separable issues:
1. It was requested that the meaning of dot1qDiscardInbound be
clarified to ensure it is distinct from other counters.
(Specifically, why is it different from 1493?) (KZM) - this can be
derived from other counters - NUKE IT!
2. Why are all of these so different from RFC1493? e.g. do they
refer to Transparent-only? What about SRT or SR? - Counters
limited to a set equivalent to RFC1493.
(45) Do we need dot1qVersion? (KZM) - Yes. (45) Do we need dot1qVersion? (KZM) - Yes.
(46) Nuke dot1qTpFdbClear? dot1qFdbClear? (KZM) - Yes (802.1Q "reset (46) Nuke dot1qTpFdbClear? dot1qFdbClear? (KZM) - Yes (802.1Q "reset
bridge" operation is not now supported). bridge" operation is not now supported).
(47) Do we need dot1qFdbTable which now contains only dot1qFdbId? - YES (47) Do we need dot1qFdbTable which now contains only dot1qFdbId? - YES
(it also now has dot1qFdbDynamicCount). (it also now has dot1qFdbDynamicCount).
(48) Should dot1qTpFdbTable be {FID,MAC} or {MAC,FID} - the former. (48) Should dot1qTpFdbTable be {FID,MAC} or {MAC,FID} - the former.
(49) Now that dot1qVlanStaticTable is indexed by VlanIndex/VlanId we
need a "next free" variable since these values must be managed by
agent. - Added dot1qVlanNextFreeIndex.
(50) dot1qVlanFdbId, dot1qMaxSupportedVlans, dot1qNumVlans should not be
range-limited. If they are then we need new objects to represent
the number of non-802.1Q "VLANs" too. (AHS) - Range restrictions
removed.
(51) dot1qConfigurablePvidTagging: does this also cover the "I can only
set a single VLAN to be untagged on egress" implementation option
in 802.1Q? - Description of dot1qVlanStaticUntaggedPorts clarified
to cover this.
(52) Do we need an explicit "dot1dExtendedFilteringServicesStatus"
enable/disable object? (AHS) - No.
(53) Should mention that VLAN entries in ifTable should have (53) Should mention that VLAN entries in ifTable should have
ifPhysAddress zero-length/filled (KK). No longer relevant since we ifPhysAddress zero-length/filled (KK). No longer relevant since we
do not include such ifTable entries. do not include such ifTable entries.
(54) dot1qVlanAdminUntaggedPorts - expand DESCRIPTION to include meaning (54) dot1qVlanAdminUntaggedPorts - expand DESCRIPTION to include meaning
of 0 (KK). Changed description to talk about include/exclude from of 0 (KK). Changed description to talk about include/exclude from
the set of ports: refer to Portlist TC for 0/1 meaning. the set of ports: refer to Portlist TC for 0/1 meaning.
(55) Need to split dot1qStaticAllowedToGoTo into two portmaps in order
to represent the 3 possible states from 802.1Q 8.11.2: static,
forbidden and allowed to be influenced by dynamic info. (ELB) DONE
for multicast - split dot1qStaticAllowedToGoTo into
dot1qStaticMulticastStaticEgressPorts and
dot1qStaticMulticastForbiddenEgressPorts. Same issue for unicast
table. - Not required to split this for unicast.
(56) Should a value of 0 be allowed for dot1qTpFdbPort? This is
inherited from RFC1493. (ELB) - Yes it is allowed. No change
required.
(57) Rename dot1qVlanStaticUntagged as dot1qVlanStaticUntaggedPorts for
consistency. (ELB) - Done.
(58) If an empty string is used for dot1qVlanStaticName, does it have to
be unique? The description implies it must be unique. (ELB) NO -
clarified this.
(59) Should dot1qPvid have syntax VlanIndex (currently it is VlanId)?
(ELB) - Yes, done.
(60) Do dot1qPortAcceptableFrameTypes and dot1qPortIngressFiltering also
apply to tagged GMRP packets? (ELB) - Yes, descriptions clarified.
(61) Do we need dot1qLearningContraintsLastChange? It just reminds the
manager of changes that he or some other manager made. (ELB) - No,
object removed.
(62) Remove support for multiple egress ports in static unicast FDB
entries? (KK) - Not applicable. The entry indicates ports a
unicast address MAY be learnt on, not ports it MUST be forwarded
to. Description clarified.
(63) dot1dGmrpStatus is a member of a mandatory group and has a DEFVAL
of "enabled". This is inappropriate for devices which do not
support extended filtering services but do support priority
forwarding and therefore implement this MIB. (DM) - Similar
problem with dot1dTrafficClassesEnabled. Defined both of these in
separate groups, each group is mandatory only if that feature is
supported by the bridge. Capabilities bit added to indicate
support for traffic classes. Removed MIN-ACCESS for
dot1dTrafficClassesEnabled.
(64) dot1dPortCapabilities, dot1qPortIngressFiltering - tighten up the
text to read: "supports the discarding of any frame received on
that Port whose VLAN classification does not include that Port in
its Member set." (DM) - Done. Also changed the name of the
capability bit for this to dot1qIngressFiltering to resolve
duplicate name. Changed the description of
dot1qPortIngressFiltering object to match the above text.
(65) dot1qConfigurablePvidTagging - According to 802.1Q it is a
requirement. Is there a reason to treat it as optional in the MIB?
(DM) - Reference is 12.10.1.1.3/b/2. The 802.1Q description is
"whether the implementation supports the ability to override the
default PVID setting and its egress status (VLAN-Tagged or
Untagged) on each port". Capability description modified with the
above quote from the standard.
(66) PVID tagging should be moved from dot1dPortCapabilities to
dot1dDeviceCapabilities. (AHS) - Done.
(67) dot1dUserPriorityRegenTable - is not relevant for Ethernet LANs. A
statement to this effect and a reference (ISO/IEC 15802-3 6.4) may
be helpful. (DM) - Done. Also put this in a separate conformance
group, mandatory for media which support native User Priority.
dot1dTrafficClassTable updated to be independent of this table.
(68) What should the compliance be for dot1dPortDefaultUserPriority?
(AHS) - Put this in a separate conformance group, mandatory for
media which do not support native User Priority.
(69) There are no definitions for qBridgeFdbGroup or qBridgeTpFdbGroup -
remove references to these in qBridgeCompliance section. (AHS) -
Done.
(70) Should we count the number of dynamic group address entries per
VLAN? (AHS) - This can be derived by counting rows in
dot1dTpGroupTable. Added it to the 'not included' list in section
3.2.1.
(71) dot1qTpGroupAllowedToGoTo really means 'forward to'. (DM) - The
description has been clarified and the object renamed as
'dot1qTpGroupEgressPorts'.
(72) Why provide a default value for dot1qStaticUnicastAllowedToGoTo?
It should include only member ports of the frame's VLAN
classification. The phrase "a string of ones" is incorrect. Also
for dot1qStaticMulticastStaticEgressPorts. (DM) - Clarified the
description, this value only applies to ports also in the
dot1qVlanCurrentEgressPorts list for the VLAN. Also applied this
clarification to dot1qForwardAllStaticPorts.
(73) dot1qStaticUnicastAllowedToGoTo: why is the term "allowed" used
here? Doesn't this object define exactly to which port(s) the
frame is to be forwarded? (DM) - No. The consensus from recent
discussions interpret this as 'may be dynamically learnt on'.
Clarified the description.
(74) The Untagged Set for a VLAN is only modified statically by
management and this object will always have the same value as the
dot1qVlanStaticUntagged. If so, should it be eliminated. (DM) -
Untagged VLANs may also be dynamically learned. No change
required.
(75) The meaning of dot1qVlanStatus is confusing. (DM) - The description
has been clarified.
(76) dot1qVlanStatisticsTable potentially requires a very large number
of counters and may not be achievable in many architectures. A
control table which specifies for which VLANs the counters would be
maintained could limit the number of counters required. (DM) - Not
considered worthwhile. No change required.
6. Definitions for Extended Bridge MIB 6. Definitions for Extended Bridge MIB
P-BRIDGE-MIB DEFINITIONS ::= BEGIN P-BRIDGE-MIB DEFINITIONS ::= BEGIN
-- ------------------------------------------------------------- -- -------------------------------------------------------------
-- IEEE 802.1p MIB -- IEEE 802.1p MIB
-- ------------------------------------------------------------- -- -------------------------------------------------------------
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Counter32, Counter64 MODULE-IDENTITY, OBJECT-TYPE, Counter32, Counter64
FROM SNMPv2-SMI FROM SNMPv2-SMI
TruthValue, TimeInterval, TEXTUAL-CONVENTION TruthValue, TimeInterval, MacAddress, TEXTUAL-CONVENTION
FROM SNMPv2-TC FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF FROM SNMPv2-CONF
MacAddress, dot1dTp, dot1dTpPort, dot1dTp, dot1dTpPort, dot1dBridge,
dot1dBridge, dot1dBasePortEntry, dot1dBasePort dot1dBasePortEntry, dot1dBasePort
FROM BRIDGE-MIB; FROM BRIDGE-MIB;
pBridgeMIB MODULE-IDENTITY pBridgeMIB MODULE-IDENTITY
LAST-UPDATED "9810070000Z" LAST-UPDATED "9811030000Z"
ORGANIZATION "IETF Bridge MIB Working Group" ORGANIZATION "IETF Bridge MIB Working Group"
CONTACT-INFO CONTACT-INFO
" Les Bell " Les Bell
Postal: 3Com Europe Ltd. Postal: 3Com Europe Ltd.
3Com Centre, Boundary Way 3Com Centre, Boundary Way
Hemel Hempstead, Herts. HP2 7YU Hemel Hempstead, Herts. HP2 7YU
UK UK
Phone: +44 1442 438025 Phone: +44 1442 438025
Email: Les_Bell@3Com.com Email: Les_Bell@3Com.com
skipping to change at page 29, line 30 skipping to change at page 28, line 30
Phone: +1 (408) 526 5260 Phone: +1 (408) 526 5260
Email: kzm@cisco.com" Email: kzm@cisco.com"
DESCRIPTION DESCRIPTION
"The Bridge MIB Extension module for managing Priority "The Bridge MIB Extension module for managing Priority
and Multicast Filtering, defined by IEEE 802.1D-1998." and Multicast Filtering, defined by IEEE 802.1D-1998."
REVISION "9810070000Z" REVISION "9810070000Z"
DESCRIPTION "Updated with revisions from August 1998 Plenary DESCRIPTION "Updated with revisions from August 1998 Plenary
meeting." meeting."
REVISION "9811030000Z"
DESCRIPTION "Updated with changes agreed on mailing list
after August 1998 IETF."
::= { dot1dBridge 6 } ::= { dot1dBridge 6 }
pBridgeMIBObjects OBJECT IDENTIFIER ::= { pBridgeMIB 1 } pBridgeMIBObjects OBJECT IDENTIFIER ::= { pBridgeMIB 1 }
-- ------------------------------------------------------------- -- -------------------------------------------------------------
-- Textual Conventions -- Textual Conventions
-- ------------------------------------------------------------- -- -------------------------------------------------------------
EnabledStatus ::= TEXTUAL-CONVENTION EnabledStatus ::= TEXTUAL-CONVENTION
STATUS current STATUS current
skipping to change at page 30, line 17 skipping to change at page 29, line 21
dot1dGarp OBJECT IDENTIFIER ::= { pBridgeMIBObjects 3 } dot1dGarp OBJECT IDENTIFIER ::= { pBridgeMIBObjects 3 }
dot1dGmrp OBJECT IDENTIFIER ::= { pBridgeMIBObjects 4 } dot1dGmrp OBJECT IDENTIFIER ::= { pBridgeMIBObjects 4 }
-- ------------------------------------------------------------- -- -------------------------------------------------------------
-- ------------------------------------------------------------- -- -------------------------------------------------------------
-- the dot1dExtBase group -- the dot1dExtBase group
-- ------------------------------------------------------------- -- -------------------------------------------------------------
dot1dDeviceCapabilities OBJECT-TYPE dot1dDeviceCapabilities OBJECT-TYPE
SYNTAX BIT STRING { SYNTAX BITS {
dot1dExtendedFilteringServices(0), dot1dExtendedFilteringServices(0),
-- can perform filtering of -- can perform filtering of
-- individual multicast addresses -- individual multicast addresses
-- controlled by GMRP. -- controlled by GMRP.
dot1dTrafficClasses(1), dot1dTrafficClasses(1),
-- can map user priority to -- can map user priority to
-- multiple traffic classes. -- multiple traffic classes.
dot1qStaticEntryIndividualPort(2), dot1qStaticEntryIndividualPort(2),
-- dot1qStaticUnicastReceivePort & -- dot1qStaticUnicastReceivePort &
-- dot1qStaticMulticastReceivePort -- dot1qStaticMulticastReceivePort
skipping to change at page 32, line 18 skipping to change at page 31, line 22
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A set of capabilities information about this port "A set of capabilities information about this port
indexed by dot1dBasePort." indexed by dot1dBasePort."
AUGMENTS { dot1dBasePortEntry } AUGMENTS { dot1dBasePortEntry }
::= { dot1dPortCapabilitiesTable 1 } ::= { dot1dPortCapabilitiesTable 1 }
Dot1dPortCapabilitiesEntry ::= Dot1dPortCapabilitiesEntry ::=
SEQUENCE { SEQUENCE {
dot1dPortCapabilities dot1dPortCapabilities
BIT STRING BITS
} }
dot1dPortCapabilities OBJECT-TYPE dot1dPortCapabilities OBJECT-TYPE
SYNTAX BIT STRING { SYNTAX BITS {
dot1qDot1qTagging(0), -- supports 802.1Q VLAN tagging of dot1qDot1qTagging(0), -- supports 802.1Q VLAN tagging of
-- frames and GVRP. -- frames and GVRP.
dot1qConfigurableAcceptableFrameTypes(1), dot1qConfigurableAcceptableFrameTypes(1),
-- allows modified values of -- allows modified values of
-- dot1qPortAcceptableFrameTypes. -- dot1qPortAcceptableFrameTypes.
dot1qIngressFiltering(2) dot1qIngressFiltering(2)
-- supports the discarding of any -- supports the discarding of any
-- frame received on a Port whose -- frame received on a Port whose
-- VLAN classification does not -- VLAN classification does not
-- include that Port in its Member -- include that Port in its Member
skipping to change at page 42, line 6 skipping to change at page 41, line 11
bridge management frames." bridge management frames."
REFERENCE REFERENCE
"ISO/IEC 15802-3 Section 14.6.1.1.3" "ISO/IEC 15802-3 Section 14.6.1.1.3"
::= { dot1dTpHCPortEntry 2 } ::= { dot1dTpHCPortEntry 2 }
dot1dTpHCPortInDiscards OBJECT-TYPE dot1dTpHCPortInDiscards OBJECT-TYPE
SYNTAX Counter64 SYNTAX Counter64
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Count of valid frames received which were discarded "Count of valid frames that have been received by this
(i.e., filtered) by the Forwarding Process." port from its segment which were discarded (i.e.,
filtered) by the Forwarding Process."
REFERENCE REFERENCE
"ISO/IEC 15802-3 Section 14.6.1.1.3" "ISO/IEC 15802-3 Section 14.6.1.1.3"
::= { dot1dTpHCPortEntry 3 } ::= { dot1dTpHCPortEntry 3 }
-- ------------------------------------------------------------- -- -------------------------------------------------------------
-- IEEE 802.1p MIB - Conformance Information -- IEEE 802.1p MIB - Conformance Information
-- ------------------------------------------------------------- -- -------------------------------------------------------------
pBridgeConformance OBJECT IDENTIFIER ::= { pBridgeMIB 2 } pBridgeConformance OBJECT IDENTIFIER ::= { pBridgeMIB 2 }
skipping to change at page 47, line 15 skipping to change at page 47, line 15
7. Definitions for Virtual Bridge MIB 7. Definitions for Virtual Bridge MIB
Q-BRIDGE-MIB DEFINITIONS ::= BEGIN Q-BRIDGE-MIB DEFINITIONS ::= BEGIN
-- ------------------------------------------------------------- -- -------------------------------------------------------------
-- IEEE 802.1Q MIB -- IEEE 802.1Q MIB
-- ------------------------------------------------------------- -- -------------------------------------------------------------
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, MODULE-IDENTITY, OBJECT-TYPE,
Counter32, Counter64, UInteger32 Counter32, Counter64, Unsigned32
FROM SNMPv2-SMI FROM SNMPv2-SMI
RowStatus, TruthValue, DisplayString, TEXTUAL-CONVENTION RowStatus, TruthValue, DisplayString, TEXTUAL-CONVENTION
FROM SNMPv2-TC FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF FROM SNMPv2-CONF
MacAddress, dot1dBridge, dot1dBasePortEntry, dot1dBasePort MacAddress, dot1dBridge, dot1dBasePortEntry, dot1dBasePort
FROM BRIDGE-MIB FROM BRIDGE-MIB
EnabledStatus EnabledStatus
FROM P-BRIDGE-MIB FROM P-BRIDGE-MIB
TimeFilter TimeFilter
FROM RMON2-MIB; FROM RMON2-MIB;
qBridgeMIB MODULE-IDENTITY qBridgeMIB MODULE-IDENTITY
LAST-UPDATED "9810070000Z" LAST-UPDATED "9811030000Z"
ORGANIZATION "IETF Bridge MIB Working Group" ORGANIZATION "IETF Bridge MIB Working Group"
CONTACT-INFO CONTACT-INFO
" Les Bell " Les Bell
Postal: 3Com Europe Ltd. Postal: 3Com Europe Ltd.
3Com Centre, Boundary Way 3Com Centre, Boundary Way
Hemel Hempstead, Herts. HP2 7YU Hemel Hempstead, Herts. HP2 7YU
UK UK
Phone: +44 1442 438025 Phone: +44 1442 438025
Email: Les_Bell@3Com.com Email: Les_Bell@3Com.com
skipping to change at page 48, line 34 skipping to change at page 48, line 34
Phone: +1 (408) 526 5260 Phone: +1 (408) 526 5260
Email: kzm@cisco.com" Email: kzm@cisco.com"
DESCRIPTION DESCRIPTION
"The VLAN Bridge MIB module for managing Virtual Bridged "The VLAN Bridge MIB module for managing Virtual Bridged
Local Area Networks, as defined by IEEE 802.1Q-1998." Local Area Networks, as defined by IEEE 802.1Q-1998."
REVISION "9810070000Z" REVISION "9810070000Z"
DESCRIPTION "Updated with revisions from August 1998 Plenary DESCRIPTION "Updated with revisions from August 1998 Plenary
meeting." meeting."
REVISION "9811030000Z"
DESCRIPTION "Updated with changes agreed on mailing list
after August 1998 IETF."
::= { dot1dBridge 7 } ::= { dot1dBridge 7 }
qBridgeMIBObjects OBJECT IDENTIFIER ::= { qBridgeMIB 1 } qBridgeMIBObjects OBJECT IDENTIFIER ::= { qBridgeMIB 1 }
-- ------------------------------------------------------------- -- -------------------------------------------------------------
-- Textual Conventions -- Textual Conventions
-- ------------------------------------------------------------- -- -------------------------------------------------------------
PortList ::= TEXTUAL-CONVENTION PortList ::= TEXTUAL-CONVENTION
STATUS current STATUS current
skipping to change at page 49, line 22 skipping to change at page 49, line 26
VlanIndex ::= TEXTUAL-CONVENTION VlanIndex ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A value used to index per-VLAN tables: values of 0 and "A value used to index per-VLAN tables: values of 0 and
4095 are not permitted; if the value is between 1 and 4095 are not permitted; if the value is between 1 and
4094 inclusive, it represents an 802.1Q VLAN-ID with 4094 inclusive, it represents an 802.1Q VLAN-ID with
global scope within a given bridged domain (see VlanId global scope within a given bridged domain (see VlanId
textual convention). If the value is greater than 4095 textual convention). If the value is greater than 4095
then it represents a VLAN with scope local to the then it represents a VLAN with scope local to the
particular agent." particular agent."
SYNTAX UInteger32 SYNTAX Unsigned32
VlanId ::= TEXTUAL-CONVENTION VlanId ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The 12-bit VLAN ID used in the VLAN Tag header." "The 12-bit VLAN ID used in the VLAN Tag header."
SYNTAX INTEGER (1..4094) SYNTAX INTEGER (1..4094)
-- ------------------------------------------------------------- -- -------------------------------------------------------------
-- groups in the Q-BRIDGE MIB -- groups in the Q-BRIDGE MIB
-- ------------------------------------------------------------- -- -------------------------------------------------------------
skipping to change at page 50, line 25 skipping to change at page 50, line 30
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The maximum IEEE 802.1Q VLAN ID that this device "The maximum IEEE 802.1Q VLAN ID that this device
supports." supports."
REFERENCE REFERENCE
"IEEE 802.1Q/D11 Section 9.3.2.3" "IEEE 802.1Q/D11 Section 9.3.2.3"
::= { dot1qBase 2 } ::= { dot1qBase 2 }
dot1qMaxSupportedVlans OBJECT-TYPE dot1qMaxSupportedVlans OBJECT-TYPE
SYNTAX UInteger32 SYNTAX Unsigned32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The maximum number of IEEE 802.1Q VLANs that this "The maximum number of IEEE 802.1Q VLANs that this
device supports." device supports."
REFERENCE REFERENCE
"IEEE 802.1Q/D11 Section 12.10.1.1" "IEEE 802.1Q/D11 Section 12.10.1.1"
::= { dot1qBase 3 } ::= { dot1qBase 3 }
dot1qNumVlans OBJECT-TYPE dot1qNumVlans OBJECT-TYPE
SYNTAX UInteger32 SYNTAX Unsigned32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The current number of IEEE 802.1Q VLANs that are "The current number of IEEE 802.1Q VLANs that are
configured in this device." configured in this device."
REFERENCE REFERENCE
"IEEE 802.1Q/D11 Section 12.7.1.1" "IEEE 802.1Q/D11 Section 12.7.1.1"
::= { dot1qBase 4 } ::= { dot1qBase 4 }
dot1qGvrpStatus OBJECT-TYPE dot1qGvrpStatus OBJECT-TYPE
skipping to change at page 52, line 6 skipping to change at page 52, line 9
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Information about a specific Filtering Database." "Information about a specific Filtering Database."
INDEX { dot1qFdbId } INDEX { dot1qFdbId }
::= { dot1qFdbTable 1 } ::= { dot1qFdbTable 1 }
Dot1qFdbEntry ::= Dot1qFdbEntry ::=
SEQUENCE { SEQUENCE {
dot1qFdbId dot1qFdbId
UInteger32, Unsigned32,
dot1qFdbDynamicCount dot1qFdbDynamicCount
Counter32 Counter32
} }
dot1qFdbId OBJECT-TYPE dot1qFdbId OBJECT-TYPE
SYNTAX UInteger32 SYNTAX Unsigned32
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The identity of this Filtering Database." "The identity of this Filtering Database."
::= { dot1qFdbEntry 1 } ::= { dot1qFdbEntry 1 }
dot1qFdbDynamicCount OBJECT-TYPE dot1qFdbDynamicCount OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
skipping to change at page 66, line 9 skipping to change at page 66, line 12
INDEX { dot1qVlanTimeMark, dot1qVlanIndex } INDEX { dot1qVlanTimeMark, dot1qVlanIndex }
::= { dot1qVlanCurrentTable 1 } ::= { dot1qVlanCurrentTable 1 }
Dot1qVlanEntry ::= Dot1qVlanEntry ::=
SEQUENCE { SEQUENCE {
dot1qVlanTimeMark dot1qVlanTimeMark
TimeFilter, TimeFilter,
dot1qVlanIndex dot1qVlanIndex
VlanIndex, VlanIndex,
dot1qVlanFdbId dot1qVlanFdbId
UInteger32, Unsigned32,
dot1qVlanCurrentEgressPorts dot1qVlanCurrentEgressPorts
PortList, PortList,
dot1qVlanCurrentUntaggedPorts dot1qVlanCurrentUntaggedPorts
PortList, PortList,
dot1qVlanStatus dot1qVlanStatus
INTEGER INTEGER
} }
dot1qVlanTimeMark OBJECT-TYPE dot1qVlanTimeMark OBJECT-TYPE
SYNTAX TimeFilter SYNTAX TimeFilter
skipping to change at page 66, line 36 skipping to change at page 66, line 39
dot1qVlanIndex OBJECT-TYPE dot1qVlanIndex OBJECT-TYPE
SYNTAX VlanIndex SYNTAX VlanIndex
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The VLAN-ID or other identifier refering to this VLAN." "The VLAN-ID or other identifier refering to this VLAN."
::= { dot1qVlanEntry 2 } ::= { dot1qVlanEntry 2 }
dot1qVlanFdbId OBJECT-TYPE dot1qVlanFdbId OBJECT-TYPE
SYNTAX UInteger32 SYNTAX Unsigned32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The Filtering Database used by this VLAN. This is one "The Filtering Database used by this VLAN. This is one
of the dot1qFdbId values in the dot1qFdbTable. This of the dot1qFdbId values in the dot1qFdbTable. This
value is allocated automatically by the device whenever value is allocated automatically by the device whenever
the VLAN is created: either dynamically by GVRP, or by the VLAN is created: either dynamically by GVRP, or by
management, in dot1qVlanStaticTable. Allocation of this management, in dot1qVlanStaticTable. Allocation of this
value follows the learning constraints defined for this value follows the learning constraints defined for this
VLAN in dot1qLearningConstraintsTable." VLAN in dot1qLearningConstraintsTable."
skipping to change at page 75, line 10 skipping to change at page 75, line 12
VLAN (e.g. GMRP, but not GVRP or STP)." VLAN (e.g. GMRP, but not GVRP or STP)."
REFERENCE REFERENCE
"IEEE 802.1Q/D11 Section 12.6.1.1.3(d)" "IEEE 802.1Q/D11 Section 12.6.1.1.3(d)"
::= { dot1qPortVlanStatisticsEntry 2 } ::= { dot1qPortVlanStatisticsEntry 2 }
dot1qTpVlanPortInDiscards OBJECT-TYPE dot1qTpVlanPortInDiscards OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of valid frames received by this port from "The number of frames received by this port which were
its segment which were classified as belonging to this discarded due to VLAN related reasons. Examples of such
VLAN and which were discarded by the local forwarding reasons are VLAN ingress filtering, VLAN egress filtering,
process for this VLAN due to filtering database and Acceptable Frame Type."
decisions. Note that this does not include frames
discarded due to ingress filtering."
REFERENCE REFERENCE
"IEEE 802.1Q/D11 Section 12.6.1.1.3(c)" "IEEE 802.1Q/D11 Section 12.6.1.1.3"
::= { dot1qPortVlanStatisticsEntry 3 } ::= { dot1qPortVlanStatisticsEntry 3 }
dot1qPortVlanHCStatisticsTable OBJECT-TYPE dot1qPortVlanHCStatisticsTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1qPortVlanHCStatisticsEntry SYNTAX SEQUENCE OF Dot1qPortVlanHCStatisticsEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A table containing per port, per VLAN statistics for "A table containing per port, per VLAN statistics for
traffic received on high capacity interfaces." traffic received on high capacity interfaces."
::= { dot1qVlan 7 } ::= { dot1qVlan 7 }
skipping to change at page 76, line 39 skipping to change at page 76, line 41
VLAN (e.g. GMRP, but not GVRP or STP)." VLAN (e.g. GMRP, but not GVRP or STP)."
REFERENCE REFERENCE
"IEEE 802.1Q/D11 Section 12.6.1.1.3(d)" "IEEE 802.1Q/D11 Section 12.6.1.1.3(d)"
::= { dot1qPortVlanHCStatisticsEntry 2 } ::= { dot1qPortVlanHCStatisticsEntry 2 }
dot1qTpVlanPortHCInDiscards OBJECT-TYPE dot1qTpVlanPortHCInDiscards OBJECT-TYPE
SYNTAX Counter64 SYNTAX Counter64
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of valid frames received by this port from "The number of frames received by this port which were
its segment which were classified as belonging to this discarded due to VLAN related reasons. Examples of such
VLAN and which were discarded by the local forwarding reasons are VLAN ingress filtering, VLAN egress filtering,
process for this VLAN due to filtering database and Acceptable Frame Type."
decisions. Note that this does not include frames
discarded due to ingress filtering."
REFERENCE REFERENCE
"IEEE 802.1Q/D11 Section 12.6.1.1.3(c)" "IEEE 802.1Q/D11 Section 12.6.1.1.3"
::= { dot1qPortVlanHCStatisticsEntry 3 } ::= { dot1qPortVlanHCStatisticsEntry 3 }
-- ------------------------------------------------------------- -- -------------------------------------------------------------
-- The VLAN Learning Constraints Table -- The VLAN Learning Constraints Table
-- ------------------------------------------------------------- -- -------------------------------------------------------------
dot1qLearningConstraintsTable OBJECT-TYPE dot1qLearningConstraintsTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1qLearningConstraintsEntry SYNTAX SEQUENCE OF Dot1qLearningConstraintsEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A table containing learning constraints for sets of "A table containing learning constraints for sets of
Shared and Independendent VLANs." Shared and Independendent VLANs."
skipping to change at page 90, line 19 skipping to change at page 90, line 19
considered sensitive or vulnerable in some network environments. The considered sensitive or vulnerable in some network environments. The
support for SET operations in a non-secure environment without proper support for SET operations in a non-secure environment without proper
protection can have a negative effect on network operations. protection can have a negative effect on network operations.
SNMPv1 by itself is not a secure environment. Even if the network SNMPv1 by itself is not a secure environment. Even if the network
itself is secure (for example by using IPSec), even then, there is no itself is secure (for example by using IPSec), even then, there is no
control as to who on the secure network is allowed to access and GET/SET control as to who on the secure network is allowed to access and GET/SET
(read/change/create/delete) the objects in this MIB. (read/change/create/delete) the objects in this MIB.
It is recommended that the implementers consider the security features It is recommended that the implementers consider the security features
as provided by the SNMPv3 framework. Specifically, the use of the as provided by the SNMPv3 framework. Specifically, the use of the User-
User-based Security Model RFC 2274 [12] and the View-based Access based Security Model RFC 2274 [12] and the View-based Access Control
Control Model RFC 2275 [15] is recommended. Model RFC 2275 [15] is recommended.
It is then a customer/user responsibility to ensure that the SNMP entity It is then a customer/user responsibility to ensure that the SNMP entity
giving access to an instance of this MIB, is properly configured to give giving access to an instance of this MIB, is properly configured to give
access to the objects only to those principals (users) that have access to the objects only to those principals (users) that have
legitimate rights to indeed GET or SET (change/create/delete) them. legitimate rights to indeed GET or SET (change/create/delete) them.
11. Authors' Addresses 11. Authors' Addresses
Les Bell Les Bell
3Com Europe Limited 3Com Europe Limited
skipping to change at page 92, line 39 skipping to change at page 92, line 39
3.4.2.1 Layering Model ............................................ 15 3.4.2.1 Layering Model ............................................ 15
3.4.2.2 ifStackTable .............................................. 15 3.4.2.2 ifStackTable .............................................. 15
3.4.2.3 ifRcvAddressTable ......................................... 15 3.4.2.3 ifRcvAddressTable ......................................... 15
3.4.3 Relation to Basic Bridge MIB ................................ 16 3.4.3 Relation to Basic Bridge MIB ................................ 16
3.4.3.1 The dot1dBase Group ....................................... 16 3.4.3.1 The dot1dBase Group ....................................... 16
3.4.3.2 The dot1dStp Group ........................................ 16 3.4.3.2 The dot1dStp Group ........................................ 16
3.4.3.3 The dot1dTp Group ......................................... 16 3.4.3.3 The dot1dTp Group ......................................... 16
3.4.3.4 The dot1dStatic Group ..................................... 17 3.4.3.4 The dot1dStatic Group ..................................... 17
4 Extensions to RFC 1493 .......................................... 18 4 Extensions to RFC 1493 .......................................... 18
5 Change Log and Editorial Stuff .................................. 18 5 Change Log and Editorial Stuff .................................. 18
5.1 Changes since draft-ietf-bridge-bridgemib-01.txt .............. 18 5.1 Changes since draft-ietf-bridge-bridgemib-02.txt .............. 18
5.2 Open Issues ................................................... 20 5.2 Open Issues ................................................... 18
5.3 Issues closed in this draft ................................... 20 5.3 Issues closed in this draft ................................... 19
5.4 Issues closed in previous drafts .............................. 23 5.4 Issues closed in previous drafts .............................. 19
6 Definitions for Extended Bridge MIB ............................. 28 6 Definitions for Extended Bridge MIB ............................. 27
7 Definitions for Virtual Bridge MIB .............................. 47 7 Definitions for Virtual Bridge MIB .............................. 47
8 Acknowledgments ................................................. 86 8 Acknowledgments ................................................. 86
9 References ...................................................... 87 9 References ...................................................... 87
10 Security Considerations ........................................ 90 10 Security Considerations ........................................ 90
11 Authors' Addresses ............................................. 91 11 Authors' Addresses ............................................. 91
Copyright (C) The Internet Society (date). All Rights Reserved. Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise to others, and derivative works that comment on or otherwise
explain it or assist in its implmentation may be prepared, copied, explain it or assist in its implmentation may be prepared, copied,
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/