RE: Re: RSTP-MIB extension suggestion

Hi Johannes and Les,

Since neither object was added to the mib module during the initial
development of the module, and unless there is significant outcry over
their importance, I will assume it was, and continues to be, the
consensus of the WG that these do not need to be in the current
document. 

Justification:

I've taken the responsibility for driving the documents through the
process, and it has been difficult to get them finalized. I have real
hesitation about adding any new work without finalizing the existing
work first. 

Since Les has been involved in the design of these mib modules and in
the IEEE discussions longer than I have, I accept his analysis that
autoedgeport is intended to be more diagnostic than about operational
state. Information designed for diagnostic/debug purposes typically
doesn't belong in a standards-track mib module; mib modules should
expose information about operational state in real-world deployments.
Proprietary mib modules can be used to provide diagnostic/debug
information for testing an implementation. 

Since autoedgeport is optional, I accept that it isn't critical to
support it in this release of the mib module, and let the IEEE deal
with it. IEEE 802.1 is continuing to add new features, and since the
bridgemib WG designs mib modules as a follow-on activity, we have a
real problem with being in sync with the emerging feature set. Our
intention is to transition the responsibility for the mib module
development to the 802.1 WG where it should be easier to keep the
feature set and the mib module in sync.

David Harrington
dbharrington <at> comcast.net
Bridge-mib acting co-chair

-----Original Message-----
From: bridge-mib-bounces <at> ietf.org [mailto:bridge-mib-bounces <at> ietf.org]
On Behalf Of Les Bell
Sent: Monday, September 13, 2004 4:02 AM
To: Johannes Herlitz
Cc: vivian_ngai <at> acm.org; bridge-mib <at> ietf.org
Subject: [Bridge-mib] Re: RSTP-MIB extension suggestion

I think the 'Port Role' fits in the category of diagnostic information
that is potentially useful for developers while debugging their
implementations.  I do not object to adding a MIB item for it, but I
do not think it is essential.

A change that was introduced in 802.1D-2004 (clause 17.3.3) that does
require a new MIB item is the 'autoEdgePort' parameter.  This extends
the adminEdgePort functionality to allow automatic detection of an
Edge Port, with a short delay before it enters the Forwarding state.
802.1D-2004 chose to add this as an optional, seperately managed
object so as not to make implementations that supported the existing
adminEdgePort non-conformant.

It may be worth completing the RSTP MIB as it is currently, and
waiting for IEEE
802.1 to pick up any new work to add these MIB objects.  Any opinons?

Les...

Johannes Herlitz <herlitz <at> rhrk.uni-kl.de> on 11/09/2004 19:09:24

Sent by:  Johannes Herlitz <herlitz <at> rhrk.uni-kl.de>

To:   Les Bell/GB/3Com, vivian_ngai <at> acm.org
cc:
Subject:  RSTP-MIB extension suggestion

Hi,

I've been working on a master thesis which deals a lot with the
spanning tree protocol. Since

http://ietfreport.isoc.org/ids/draft-ietf-bridge-rstpmib-04.txt

is a draft and later on should be a request for comments, I hereby
suggest an extension: Since RSTP decouples the role of a port from its
state (see table 17-1 of IEEE 802.1w, chapter 17.5, p.30) the role of
a port should be accessible via the RSTP MIB, too. The port role could
be added to the dot1dStpExtPortTable using this OID/MIB:

dot1dStpPortRole (.1.3.6.1.2.1.17.2.19.1.7)

which should be an enum holding the values "Unknown (0)", "Alternate
(1)", "Backup (2)", "Root (3)", "Designated (4)" and "Disabled (5)".
Alternatively, it also could be a less detailed enum just
differentiating between the port role as transmitted in the flags
field of a RST BPDU (see chapter 9.2.9. of IEEE 802.1w, p.12):
"Unknown (0)", "Alternate or Backup (1)", "Root (2)", "Designated (3)"
I'd prefer the first, more detailed enum.

Whats your opinion about this extension?

_______________________________________________
Bridge-mib mailing list
Bridge-mib <at> ietf.org
https://www1.ietf.org/mailman/listinfo/bridge-mib