Subject: [Bridge-mib] MSTP MIB proposals

From: "David B Harrington" <[email-masked]>
Date: Mon, 1 Nov 2004 13:35:32 -0500

Hi,

A number of people have asked about MSTP (802.1s) MIB work, and
offered a starting document.

The Bridge WG will not be developing a mib module for MSTP. MSTP mib
work will be done by the IEEE 802.1 WG.

The IEEE 802.1 WG will meet the week following IETF61, and the
co-chair is planning to schedule time to discuss an 802.1s mib PAR.
For those who are not acquainted with IEEE, a PAR discussion is
something like a BOF or a re-charter discussion. This is the point at
which they decide whether to ask the <area director equivalent> to
approve work on a new document.

One proposal has been submitted, and it will be reviewed by the 802.1
WG next week, as part of the PAR discussions. If you want your
proposal considered as a basis for the effort, then now is the time to
submit it. If you don't, it is likely the effort will be based on
somebody else's proposal. You can submit your proposal to Paul Congdon
[[email-masked]].

You can send your proposal in a format consistent with IETF internet
draft requirements. You do not have to have it published by the I-D
editor, since it will be published on the IEEE web site.

David Harrington
[email-masked]

p.s. Please do NOT name your draft draft-ietf-bridge-XXXXX.txt, since
that is reserved for the Bridge WG.

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

---

From: [email-masked] (Alex Ruzin)
Date: Tue, 2 Nov 2004 14:06:55 +0200

Hi,
I dare make a number of comments, regarding the proposed
draft-ietf-bridge-mstpmib-01.txt draft, that Paul Congdon had uploaded on
http://www.ieee802.org/1/files/public/docs2004/malhotra-mstpmib-01.txt

1. dot1sStpEnable. It is not clear, what does it mean and how it corresponds
    with .1s
2. dot1sStpBridgeForwardDelay. It must a pair of objects like in RFC1493 -
    dot1dStpForwardDelay &  dot1dStpBridgeForwardDelay:
    dot1dStpForwardDelay  is one that this bridge is currently using, in
    contrast to dot1dStpBridgeForwardDelay which is the value that
    this bridge and all others would start using if/when this bridge were to
    become the root". The same remark is true also for
dot1sStpBridgeHelloTime
    and dot1sStpBridgeMaxAge.
3. dot1sStpProtocolSpecification. The question is - can a Bridge run in
several
    modes depending on configuration? In other words, are we sure, that this
object is
    "read-only"?
4. dot1sStpInstForwardDelay. I am not sure, that we have this object per
instance.
    The same remark is true also for dot1sStpInstHelloTime,
dot1sStpInstMaxAge.
5. dot1sStpInstAdminEnable and dot1sStpInstOperEnable: what do they mean.
    What is "disabled" instance, does it has ports, does it participate in
MST
    Configuration Identifier and in MSTI Configuration Messages?
6. dot1sStpPortTable. Objects dot1sPortAdminExternalPathCost  and
   dot1sPortOperExternalPathCost are absent. The same: dot1sPortAutoEdge,
   dot1sPortHelloTime, dot1sPortProtocolMigration.
7. dot1sStpInstPortPathCost should be renamed to
dot1sStpInstInternalPortPathCost.
    Better: to have to objects  dot1sStpInstAdminInternalPortPathCost and
    dot1sStpInstAdminInternalPortPathCost.
8. dot1sStpInstPortRole (if it must be...) should distinguish between
'alternate'
    and 'backup' values.
9. dot1sStpVlanTable. It looks better, than my dot1sMapTable
10. Trap section is absent (see traps in my proposition in attachment).
11. Conformance/Compliances are absent (while my mib doesn't have them too).

Attached is my version of proposition, please consider it as a start
template
for further development.

With regards, Alex