Subject: [Bridge-mib] Bridge-MIB support for recent IEEE 802.1 standards

From: "Les Bell" <[email-masked]>
Date: Fri, 8 Jun 2001 15:02:08 +0100

Hi folks,

with the 51st IETF Meeting in London coming up in August, we need
to decide if there is any work for the Bridge-MIB WG to do.

So I have made a list of the MIB objects I think we need to define
to support the management requirements from the recent IEEE 802.1t,
IEEE 802.1u, IEEE 802.1v and IEEE 802.1w standards.

There should be an Internet-Draft to cover these MIB objects in a
few weeks.  In the meantime, I hope this gets you thinking about it.

Your feedback and support are welcome.

-- ------------------------------------------------------------------ --
New interpretation for existing objects from the Bridge MIB (RFC 1493):
-- ------------------------------------------------------------------ --

dot1dStpPriority
    Permissible values are 0-61440, in steps of 4096.
    REFERENCE "IEEE 802.1t clause 8.10.2, Table 8-4, clause 14.3."

dot1dStpPortPriority
    Permissible values are 0-240, in steps of 16.
    REFERENCE "IEEE 802.1t clause 8.10.2, Table 8-4, clause 14.3."

dot1dStpPortPathCost
    The permissible values must be extended to 1-200,000,000.
    REFERENCE "IEEE 802.1t clause 8.10.2, Table 8-5."

dot1dStpTimeSinceTopologyChange
    For RSTP, this reports the time since the tcWhile timer for
    any port on this Bridge was non-zero.
    REFERENCE "IEEE 802.1w clause 14.8.1.1."

dot1dStpTopChanges
    For RSTP, this reports the count of times that there have
    been at least one non-zero tcWhile timer on this Bridge.
    REFERENCE "IEEE 802.1w clause 14.8.1.1."

-- ------------------------------------------------------------------ --
New objects that apply to Spanning Tree on the Bridge:
-- ------------------------------------------------------------------ --

dot1dStpVersion
    The administratively assigned version of the IEEE 802.1
    Spanning Tree protocol to be used by this Bridge.  The
    default value for this object is 2, for RSTP support.  The
    only other currently permissible value is 0, for STP
    version 0 support.  It is expected that further values will
    be defined for future IEEE 802.1 standards.
    REFERENCE "IEEE 802.1w clause 14.8.1, 17.12, 17.16.1."

dot1dStpPathCostDefault
    The version of the Spanning Tree default Path Costs that are
    to be used by this Bridge.  A value of stp8021d1998(1) uses
    Path Costs from IEEE Std. 802.1D-1998.  A value of
    stp8021t2000(2) uses Path Costs from IEEE Std. 802.1t.
    REFERENCE "Not defined by IEEE 802.1."

-- ------------------------------------------------------------------ --
New objects that apply to Spanning Tree on each port of the Bridge:
-- ------------------------------------------------------------------ --

dot1dStpPortAdminEdgePort
    The administratively assigned Edge Port state.  This object
    may take the value TRUE, indicating that this port is assumed
    to be an Edge Port, or FALSE, indicating that this port
    should not be assumed to be an Edge Port.
    REFERENCE "IEEE 802.1t clause 14.8.2."

dot1dStpPortOperEdgePort
    The operationally determined Edge Port state.  The value TRUE
    indicates that this port was administratively assumed to be
    an Edge Port, and there has not been another Bridge detected
    as being connected to it.  FALSE indicates that this port was
    either not administratively assumed to be an Edge Port, or
    there has been another Bridge detected by this port.
    REFERENCE "IEEE 802.1t clause 14.8.2."

dot1dStpPortProtocolMigration
    A boolean value.  When operating in RSTP (version 2) mode,
    writing TRUE to this object forces the Bridge to try using
    version 2 BPDUs on this port.  When operating in STP (version
    0) mode, writing TRUE to this object has no effect.  Writing
    FALSE to this object has no effect.  This object always
    returns FALSE when read.
    REFERENCE "IEEE 802.1w clause 14.8.2.4, 17.26."

dot1dStpPortAdminPointToPoint
    A value indicating whether a port is administratively defined
    to be treated as a point-to-point connection to another
    system.  The value ForceTrue indicates this port should be
    considered to have a point-to-point link.  The value
    ForceFalse indicates this port should be considered to have a
    shared media link.  The value Auto indicates this port should
    be considered to have a point-to-point link if it is an
    Aggregator and all of its members are aggregatable; or if the
    MAC supports auto-negotiation and it has been determined to
    operate in full duplex mode.
    REFERENCE "IEEE 802.1w clause 6.4.3, 14.8.2."

dot1dStpPortOperPointToPoint
    A boolean value indicating whether or not a port has been
    determined to have a point-to-point connection to another
    system.  See dot1dStpPortAdminPointToPoint.
    REFERENCE "IEEE 802.1w clause 6.4.3, 14.8.2."

-- ------------------------------------------------------------------ --
New objects that apply to GVRP on each port of the Bridge:
-- ------------------------------------------------------------------ --

This definition was posted on the P8021 and Bridge MIB mailing lists
by Anders SW Christensen, Intel, on 04/05/2000.  I added the REFERENCE.

dot1qPortRestrictedRegistration OBJECT-TYPE
    SYNTAX      TruthValue
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "The state of Restricted Registration on this port.
        If the value of this control is true(1), then
        creation of a new dynamic VLAN entry is permitted only
        if there is a Static VLAN Registration Entry for the
        VLAN concerned, in which the Registrar Administrative
        Control value for this port is Normal Registration."
    REFERENCE "IEEE 802.1u clause 11.2.3.2.3, 12.10.1.7."
    DEFVAL      { false }
    ::= { dot1qPortVlanEntry 5 }

-- ------------------------------------------------------------------ --
New objects that apply to 802.1v on the Bridge:
-- ------------------------------------------------------------------ --

dot1vProtocolTemplateCapabilities
    A BITS object, listing the supported capalities for "ethernet",
    "rfc1042", "snap8021H", "snapOther", and "llcOther".
    REFERENCE "IEEE 802.1v 8.6.2, 12.10.1.1."

-- ------------------------------------------------------------------ --
New objects that apply to 802.1v on each port of the Bridge:
-- ------------------------------------------------------------------ --

dot1vProtocolGroup
    This object is indexed by {FrameType,ProtocolValue}.
    It defines the Protocol Group assigned to traffic that
    matches the Frame Type and Protocol Value given.
    REFERENCE "IEEE 802.1v 8.4.4, 12.10.1.1."

dot1vProtocolGroupVid
    This object is indexed by {port,ProtocolGroup}.
    It defines the VID assigned to traffic received on a port, that
    matches the Protocol Group given.
    REFERENCE "IEEE 802.1v 8.4.4, 12.10.2.1."

Les...

_______________________________________________
Bridge-mib mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/bridge-mib

---

From: Mike MacFaden <[email-masked]>
Date: Fri, 08 Jun 2001 10:16:57 -0700

>Your feedback and support are welcome.

Great. 1493 could use some work besides being rewritten in SMIv2.

My comments inline but here is some additional items for
consideration.

1. Clarify the indexing for the dot1dBasePortTable. Can
this table be implemented with sparse indexing?
Seems to me Section 3.2.2 has the same problem as ifIndex used to
have.

>  ...case a port number will have the same value as the corresponding
>   interface's interface number.  Port numbers are in the range
 > (1..dot1dBaseNumPorts).

2. During a case where one takes two physical ports from the bridge
and combines them into a link aggregation, what would
be the effect on the above table? Anil R. mentioned sparse indexing
should be allowed.

3. Perform Hotswap out of a bridged port, should the table be reindexed? 
If so, how should a management station be notified?

4. We should also have an object to enable/disable the *STP protocol
per port. Many fielded implementations needed this capability.

5. I also think the object dot1dStpPortEnable should be deprecated
in favor of the ifAdminStatus object.

6. Bridge counters do not have an explicitly defined counter discontinuity time object.

7. More features such as port/mac lock?

8. Notifications?

>New interpretation for existing objects from the Bridge MIB (RFC 1493):

I would not recommend a change of  SYNTAX. 
I think we can just add conformance statements
that these are the correct values and any value set above these
should result in an appropriate error. Otherwise we need to deprecate
the objects and create new ones.

>    REFERENCE "IEEE 802.1t clause 8.10.2, Table 8-5."

This will require a new object. One can't extend without breaking
backward compatiblity.

Regards
Mike MacFaden