RE: Re: RSTP-MIB extension suggestion

As far as I understand Les, he doesn't think, that
'autoEdgePort' parameter  "is intended to be more diagnostic
than about operational state" - this parameter is really important
and essential one, if a bridge supports this feature.

By "diagnostic" parameter Les meant 'Port Role'. IMHO this
parameter, while it is not indispensable for unit management,
is *very* important for managers as a tool to understand
reasons of ports states transitions.

In addition I'd like to raise a question about traps.
IMO, topologyChange trap has to have parameters:
dot1dStpPort, dot1dStpPortState and, may be,
dot1dStpPortRole.
It would be fine for managers to have also a new
trap, let's say, rootPortChange: any non-root Bridge would send
it, when it selects a new RootPort.

With great respect, Alex

> 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
> [email protected]
> Bridge-mib acting co-chair
>  
> Les Bell wrote:
>> 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 on 11/09/2004 19:09:24 wrote:
>>> 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?
>>>