From mailman-bounces@ietf.org Mon Nov 1 06:04:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16736 for ; Mon, 1 Nov 2004 06:04:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COaEG-0004PI-95 for bridge-mib-archive@ietf.org; Mon, 01 Nov 2004 06:20:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZK3-0004iO-3D for bridge-mib-archive@ietf.org; Mon, 01 Nov 2004 05:21:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: bridge-mib-archive@ietf.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:07:06 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for bridge-mib-archive@ietf.org: List Password // URL ---- -------- bridge-mib@ietf.org zopaeb https://www1.ietf.org/mailman/options/bridge-mib/bridge-mib-archive%40ietf.org From bridge-mib-bounces@ietf.org Mon Nov 1 14:10:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18883 for ; Mon, 1 Nov 2004 14:10:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COhoQ-00008x-GL for bridge-mib-archive@ietf.org; Mon, 01 Nov 2004 14:25:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COhBA-0001GS-9P; Mon, 01 Nov 2004 13:45:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COh28-0004BT-L2 for bridge-mib@megatron.ietf.org; Mon, 01 Nov 2004 13:36:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15856 for ; Mon, 1 Nov 2004 13:35:58 -0500 (EST) Message-Id: <200411011835.NAA15856@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COhH4-0007iz-VE for bridge-mib@ietf.org; Mon, 01 Nov 2004 13:51:28 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc12) with SMTP id <2004110118352801200a02hte>; Mon, 1 Nov 2004 18:35:28 +0000 From: "David B Harrington" To: Date: Mon, 1 Nov 2004 13:35:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTAQZGAaUy7JQVsTh6QOz0TCU78HA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] MSTP MIB proposals X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit 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 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 [paul.congdon@hp.com]. 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 dbharrington@comcast.net 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 Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Tue Nov 2 05:08:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03063 for ; Tue, 2 Nov 2004 05:08:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COvpa-0005Ty-7q for bridge-mib-archive@ietf.org; Tue, 02 Nov 2004 05:24:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COvQI-0000nH-Ga; Tue, 02 Nov 2004 04:57:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COvJc-0007C5-4w for bridge-mib@megatron.ietf.org; Tue, 02 Nov 2004 04:51:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02271 for ; Tue, 2 Nov 2004 04:50:53 -0500 (EST) Received: from columba.eur.3com.com ([161.71.171.238]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COvYc-0005Cj-0x for bridge-mib@ietf.org; Tue, 02 Nov 2004 05:06:30 -0500 Received: from toucana.eur.3com.com (eurelay.eur.3com.com [140.204.220.50]) by columba.eur.3com.com with ESMTP id iA29qQuQ026388; Tue, 2 Nov 2004 09:52:26 GMT Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id iA29t8AI009097; Tue, 2 Nov 2004 09:55:09 GMT Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256F40.00361844 ; Tue, 2 Nov 2004 09:50:51 +0000 X-Lotus-FromDomain: 3COM From: "Les Bell" To: j.schoenwaelder@iu-bremen.de Message-ID: <80256F40.003616A1.00@notesmta.eur.3com.com> Date: Tue, 2 Nov 2004 09:50:14 +0000 Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Use of the 32-bit path cost was defined in both 802.1w (RSTP) and 802.1t. 802.1t was a collection of enhacements to Bridges, including those that support legacy STP. So the 32-bit path costs do not just apply to RSTP. I think you are right that dot1dStpPortPathCost32 should be conditionally mandatory, but for any Spanning Tree implementation that supports 32-bit path costs, not just for RSTP. Implementations that support 32-bit path costs should not use the 16-bit path cost object, dot1dStpPortPathCost, but I am not sure what is the best way to deal with this. Are we allowed to allocate a special value to indicate it is not in use? I think it would be safer to return an SNMP error indicating the old object is not supported. Les... Juergen Schoenwaelder @ietf.org on 22/10/2004 12:05:23 Please respond to j.schoenwaelder@iu-bremen.de Sent by: bridge-mib-bounces@ietf.org To: bridge-mib@ietf.org cc: Subject: [Bridge-mib] dot1dStpPortPathCost32 The revised BRIDGE-MIB adds dot1dStpPortPathCost32 and makes it mandatory. I think this is broken since existing deployed implementations won't support that object and thus are not compliant. Can someone please explain in which situations the increased range of dot1dStpPortPathCost32 is actually needed? Is this only relevant for rapid spanning tree? In that case, I think the object should be conditionally mandatory for boxes that do rapid spanning tree and the old one stays current, probably with a special value to use in case dot1dStpPortPathCost32 actually has the larger path cost. Please give advise. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Tue Nov 2 11:22:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05766 for ; Tue, 2 Nov 2004 11:22:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1fM-0005Zc-96 for bridge-mib-archive@ietf.org; Tue, 02 Nov 2004 11:37:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1Bc-0003sb-E3; Tue, 02 Nov 2004 11:07:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COxS3-0001J3-S8 for bridge-mib@megatron.ietf.org; Tue, 02 Nov 2004 07:07:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11058 for ; Tue, 2 Nov 2004 07:07:49 -0500 (EST) Received: from apollo.nbase.co.il ([194.90.137.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COxh8-0007rn-5N for bridge-mib@ietf.org; Tue, 02 Nov 2004 07:23:28 -0500 Received: from Alexr ([194.90.136.135]) by apollo.nbase.co.il (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-44418U200L2S100) with SMTP id AAA2633; Tue, 2 Nov 2004 14:05:55 +0200 From: arozin@mrv.com (Alex Ruzin) To: , , Subject: RE: [Bridge-mib] MSTP MIB proposals Date: Tue, 2 Nov 2004 14:06:55 +0200 Message-ID: <016501c4c0d4$73be0810$87885ac2@Alexr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0166_01C4C0E5.37485EB0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200411011835.NAA15856@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.3 (/) X-Scan-Signature: b82a343a837540fddd003340b02c7b43 X-Mailman-Approved-At: Tue, 02 Nov 2004 11:07:06 -0500 X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arozin@mrv.com List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3eec21359cc773323f0aab45cb0596af This is a multi-part message in MIME format. ------=_NextPart_000_0166_01C4C0E5.37485EB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 On Monday, November 01, 2004 8:36 PM David B Harrington wrote: > 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 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 > [paul.congdon@hp.com]. > > 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 > dbharrington@comcast.net > > p.s. Please do NOT name your draft draft-ietf-bridge-XXXXX.txt, since > that is reserved for the Bridge WG. > > ------=_NextPart_000_0166_01C4C0E5.37485EB0 Content-Type: text/plain; name="draft-mstp-mib-00.txt" Content-Disposition: attachment; filename="draft-mstp-mib-00.txt" Content-Transfer-Encoding: quoted-printable Internet Draft = =20 draft-mstp-mib-00.txt = Alex Rozin MRV = International = T.B.D. =20 = Oct 2004 Definitions of Managed Objects for Bridges with Multiple Spanning Tree Protocol Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines a MIB module for managing the Multiple Spanning Tree capability defined by the IEEE Std 802.1s amendment to IEEE Std 802.1D-1998 for bridging between Local Area Network (LAN) = segments. This memo gives a MIB module for managing the MSTP protocol in a = manner that is compliant to SMIv2 [RFC2578]. Table of Contents 1 The SNMP Management Framework ................................ =20 2 Overview ..................................................... =20 2.1 Scope ...................................................... =20 3 Structure of MSTP-MIB......................................... =20 4 Relation to Original Bridge MIB............................... =20 5 Definition for MSTP-MIB ...................................... =20 6 Acknowledgments .............................................. =20 7 Security consideration ....................................... =20 8 References ................................................... =20 9 Authors' Addresses ........................................... =20 10 Full Copyright .............................................. =20 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Overview A common device present in many networks is the Bridge. This device is used to connect Local Area Network segments below the network layer. These devices are often known as 'layer 2 switches'. There are two major modes defined for this bridging: Source-Route and transparent. Management of Source-Route bridging is not discussed=20 in this document. MSTP is defined by IEEE 802.1s. MST is defined as one or more logical topologies on a common physical interface. Typically one or more = VLANs are mapped to a logical topology. 2.1. Scope This MIB includes a comprehensive set of managed objects which attempts to match the set defined in IEEE 802.1s. 3. Structure of MSTP-MIB MSTP-MIB Name IEEE 802.1s Name/Purpose dot1s T.B.D. 4. Relation to Original Bridge MIB =20 The interpretation of all the existing groups in the original Bridge = MIB [BRIDGEMIB] remains unchanged. In addition to the objects in the = original=20 Bridge MIB [BRIDGEMIB], this document adds dot1sStp group with the = following=20 OID to manage the Multiple Spanning Tree Protocol: dot1sStp 7 MSTP-MIB DEFINITIONS ::=3D BEGIN=0A= -- draft !=0A= =0A= IMPORTS=0A= MODULE-IDENTITY, OBJECT-TYPE, Counter32, TimeTicks=0A= FROM SNMPv2-SMI=0A= TEXTUAL-CONVENTION, DisplayString, TruthValue=0A= FROM SNMPv2-TC=0A= mib-2=0A= FROM RFC1213-MIB=0A= Timeout, BridgeId=0A= FROM BRIDGE-MIB=0A= enterprises=0A= FROM RFC1155-SMI;=0A= =0A= dot1s MODULE-IDENTITY=0A= LAST-UPDATED "200107130000Z"=0A= ORGANIZATION "MRV Communications, Inc."=0A= CONTACT-INFO=0A= "Alex Rozin=0A= MRV Communication, Inc=0A= http://www.mrv.com=0A= Email: ARozin@mrv.com"=0A= =0A= DESCRIPTION=0A= "The MIB module for managing Multiple & Rapid = Spanning Treescw=0A= Protocol and algorith. It is dedicated to reflect = IEEE 802.1s."=0A= ::=3D { dot1dBridge XX }=0A= =0A= --=0A= -- Textual Conventions=0A= --=0A= =0A= PortIndex ::=3D TEXTUAL-CONVENTION=0A= DISPLAY-HINT "d"=0A= STATUS current=0A= DESCRIPTION=0A= "A unique value, greater than zero, for each Port=0A= in the managed Bridge.=0A= The value for each PortIndex remain=0A= constant at least from one re-initialization of the entity's=0A= network management system to the next re-initialization."=0A= SYNTAX Integer32 (1..2147483647)=0A= =0A= PortIndexOrZero ::=3D TEXTUAL-CONVENTION=0A= DISPLAY-HINT "d"=0A= STATUS current=0A= DESCRIPTION=0A= "This textual convention is an extension of the=0A= PortIndex convention. The latter defines a greater=0A= than zero value used to identify a Port=0A= in the managed Bridge. This extension permits the=0A= additional value of zero. the value zero is object-specific=0A= and must therefore be defined as part of the description of=0A= any object which uses this syntax. Examples of the usage of=0A= zero might include situations where Port was unknown,=0A= or when none or all Ports need to be referenced."=0A= SYNTAX Integer32 (0..2147483647)=0A= =0A= MstiInstanceIndex ::=3D TEXTUAL-CONVENTION=0A= DISPLAY-HINT "d"=0A= STATUS current=0A= DESCRIPTION=0A= "A unique value, greater than zero, for each Multiple = Spanning=0A= Tree Instance (MSTI) in the managed Bridge.=0A= The value for each MstiInstanceIndex remains=0A= constant for the instance,"=0A= SYNTAX Integer32 (1..64)=0A= =0A= MstiOrCistInstanceIndex ::=3D TEXTUAL-CONVENTION=0A= DISPLAY-HINT "d"=0A= STATUS current=0A= DESCRIPTION=0A= "This textual convention is an extension of the=0A= MstiInstanceIndex convention. This extension permits the=0A= additional value of zero, which means Common and Internal=0A= Spanning Tree (CIST)."=0A= SYNTAX Integer32 (0..64)=0A= =0A= PortId ::=3D TEXTUAL-CONVENTION=0A= DISPLAY-HINT "d"=0A= STATUS current=0A= DESCRIPTION=0A= "The Port Identifier of the Port, see IEEE 802.1s clause = 12.8.2.1.3.c)."=0A= SYNTAX OCTET STRING (SIZE (2))=0A= =0A= dot1sGen OBJECT IDENTIFIER ::=3D { dot1s 10 }=0A= -- dot1sGen group reflects configurations/statuses=0A= -- the Bridge as a unit=0A= =0A= dot1sGenBridgeMaxAge OBJECT-TYPE=0A= SYNTAX Timeout (600..4000)=0A= ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "12.8.1.3.a)"=0A= ::=3D { dot1sGen 2 }=0A= =0A= dot1sGenBridgeHelloTime OBJECT-TYPE=0A= SYNTAX Timeout (100..1000)=0A= ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "12.8.1.3.b)"=0A= ::=3D { dot1sGen 3 }=0A= =0A= dot1sGenBridgeForwardDelay OBJECT-TYPE=0A= SYNTAX Timeout (400..3000)=0A= ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "12.8.1.3.c)"=0A= ::=3D { dot1sGen 4 }=0A= =0A= dot1sGenMaxAge OBJECT-TYPE=0A= SYNTAX Timeout (600..4000)=0A= ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "12.8.1.3.a)"=0A= ::=3D { dot1sGen 8 }=0A= =0A= dot1sGenHelloTime OBJECT-TYPE=0A= SYNTAX Timeout (100..1000)=0A= ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "12.8.1.3.b)"=0A= ::=3D { dot1sGen 9 }=0A= =0A= dot1sGenForwardDelay OBJECT-TYPE=0A= SYNTAX Timeout (400..3000)=0A= ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "12.8.1.3.c)"=0A= ::=3D { dot1sGen 10 }=0A= =0A= dot1sGenMaxHops OBJECT-TYPE=0A= SYNTAX Integer32 (4..30)=0A= ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "13.22.f)"=0A= ::=3D { dot1sGen 14 }=0A= =0A= dot1sGenHoldTime OBJECT-TYPE=0A= SYNTAX Timeout (100..1000)=0A= ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sGen 15 }=0A= =0A= dot1sGenMigrateTime OBJECT-TYPE=0A= SYNTAX Timeout (100..1000)=0A= ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "13.22.d)"=0A= ::=3D { dot1sGen 16 }=0A= =0A= dot1sGenPathCostDefault OBJECT-TYPE=0A= SYNTAX INTEGER {=0A= pathCostDefault8021d1998(1),=0A= pathCostDefault8021t2001(2)=0A= }=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION=0A= "(Copied from = draft-ietf-bridge-rstpmib-02.txt).=0A= The version of the Spanning Tree default Path = Costs that=0A= are to be used by this Bridge. A value of = pathCostDefault8021d1998(1)=0A= uses the 16-bit default Path Costs from IEEE = Std. 802.1D-1998.=0A= A value of pathCostDefault8021t2001(2) uses = the 32-bit default Path=0A= Costs from IEEE Std. 802.1t."=0A= REFERENCE=0A= "IEEE 802.1D & 802.1t Table 8-5"=0A= ::=3D { dot1sGen 18 }=0A= =0A= dot1sGenCapable OBJECT-TYPE=0A= SYNTAX INTEGER {=0A= nonStp(0),=0A= dot1d1998(1),=0A= dot1w(2),=0A= dot1d2004(3),=0A= dot1s(4),=0A= unknown(5)=0A= }=0A= ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "An indication of wheter the Bridge supports=0A= 'maximum' level Spanning Tree Protocol.=0A= The value nonStp(0) indicates, the Bridge doesn't=0A= support any Spanning Tree Protocol.=0A= The value 'dot1d1998(1)' indicates the Spanning Tree = Protocol=0A= specified in EEE 802.1D-1998, 'dot1w(2)' indicates = the Rapid=0A= Spanning Tree Protocol specified in IEEE 802.1w,=0A= 'dot1d2004' indicates IEEE 802.1D-2004 and=0A= 'dot1s(3)means MSTP IEEE 802.1s."=0A= ::=3D { dot1sGen 19 }=0A= =0A= =0A= dot1sGenForceVersion OBJECT-TYPE=0A= SYNTAX INTEGER {=0A= forceNonStp(0),=0A= forceLegacyDot1d(1),=0A= forceDot1w(2),=0A= autoDot1s(3),=0A= unknown(4)=0A= }=0A= ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "The value forceNonStp(0) indicates, the Spanning Tree = Protocol=0A= is disabled on the Bridge (or the Spanning Tree = Protocol=0A= Emulation operates). Other possible values are = described=0A= in IEEE 802.1s clause 12.8.1.3.e)"=0A= DEFVAL { autoDot1s }=0A= ::=3D { dot1sGen 20 }=0A= =0A= dot1sGenCfgName OBJECT-TYPE=0A= SYNTAX DisplayString (SIZE (32))=0A= ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "12.12.3.4.2.b)"=0A= ::=3D { dot1sGen 21 }=0A= =0A= dot1sGenRevLevel OBJECT-TYPE=0A= SYNTAX Integer32=0A= ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "12.12.3.4.2.c)"=0A= ::=3D { dot1sGen 22 }=0A= =0A= dot1sGenBridgeId OBJECT-TYPE=0A= SYNTAX BridgeId=0A= ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sGen 25 }=0A= =0A= dot1sGenReginalRoot OBJECT-TYPE=0A= SYNTAX BridgeId=0A= ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sGen 26 }=0A= =0A= dot1sGenExternalRootCost OBJECT-TYPE=0A= SYNTAX Integer32=0A= ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sGen 27 }=0A= =0A= =0A= dot1sPortTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF Dot1sPortEntry=0A= ACCESS not-accessible=0A= STATUS mandatory=0A= DESCRIPTION=0A= "A table that contains generic information about=0A= every port that is associated with this bridge.=0A= Transparent, source-route, and srt ports are=0A= included."=0A= ::=3D { dot1s 11 }=0A= =0A= dot1sPortEntry OBJECT-TYPE=0A= SYNTAX Dot1sPortEntry=0A= ACCESS not-accessible=0A= STATUS mandatory=0A= DESCRIPTION=0A= "A list of information for each port of the=0A= bridge."=0A= INDEX { dot1sPortIndex }=0A= ::=3D { dot1sPortTable 1 }=0A= =0A= Dot1sPortEntry ::=3D SEQUENCE {=0A= dot1sPortIndex PortIndex,=0A= dot1sPortAdminMACEnable TruthValue,=0A= dot1sPortOperMACEnable TruthValue,=0A= dot1sPortUpTime TimeTicks,=0A= dot1sPortAdminExternalPathCost Integer32,=0A= dot1sPortOperExternalPathCost Integer32,=0A= dot1sPortAdminEdge TruthValue,=0A= dot1sPortOperEdge TruthValue,=0A= dot1sPortAutoEdge TruthValue,=0A= dot1sPortAdminPointToPoint INTEGER,=0A= dot1sPortOperPointToPoint TruthValue,=0A= dot1sPortHelloTime Timeout,=0A= dot1sPortAdminNonStp TruthValue,=0A= dot1sPortProtocolMigration TruthValue,=0A= dot1sPortRxTcnBpduCounter Counter32,=0A= dot1sPortRxCfgBpduCounter Counter32,=0A= dot1sPortRxRstBpduCounter Counter32,=0A= dot1sPortTxMstBpduCounter Counter32,=0A= dot1sPortTxTcnBpduCounter Counter32,=0A= dot1sPortTxCfgBpduCounter Counter32,=0A= dot1sPortTxRstBpduCounter Counter32,=0A= dot1sPortTxMstBpduCounter Counter32=0A= }=0A= =0A= =0A= dot1sPortIndex OBJECT-TYPE=0A= SYNTAX PortIndex=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "A unique value, greater than zero, for = each Port.=0A= The value for each interface sub-layer=0A= must remain constant at least from one = re-initialization=0A= of the entity's network management = system to the next re-=0A= initialization."=0A= ::=3D { dot1sPortEntry 1 }=0A= =0A= dot1sPortAdminMACEnable OBJECT-TYPE =0A= SYNTAX TruthValue=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause = 12.8.2.5.2"=0A= ::=3D { dot1sPortEntry 2 }=0A= =0A= dot1sPortOperMACEnable OBJECT-TYPE =0A= SYNTAX TruthValue=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause = 12.8.2.5.2"=0A= ::=3D { dot1sPortEntry 3 }=0A= =0A= dot1sPortUpTime OBJECT-TYPE =0A= SYNTAX TimeTicks=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "The value of sysUpTime at the time = when the Port=0A= has been enabled by = dot1sPortAdminMACEnable or linked=0A= last time."=0A= ::=3D { dot1sPortEntry 4 }=0A= =0A= dot1sPortAdminExternalPathCost OBJECT-TYPE=0A= SYNTAX Integer32 (0..200000000)=0A= MAX-ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "The administrative value of the = External Port Cost parameter.=0A= The value 0 means, that Port Cost will = be selected=0A= automatically in correspondence with = the speed of=0A= the attached LAN."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 5 }=0A= =0A= dot1sPortOperExternalPathCost OBJECT-TYPE=0A= SYNTAX Integer32=0A= MAX-ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 6 }=0A= =0A= dot1sPortAdminEdge OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 7 }=0A= =0A= dot1sPortOperEdge OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 8 }=0A= =0A= dot1sPortAutoEdge OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 9 }=0A= =0A= dot1sPortAdminPointToPoint OBJECT-TYPE=0A= SYNTAX INTEGER {=0A= forceTrue(0),=0A= forceFalse(1),=0A= auto(2)=0A= }=0A= MAX-ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 10 }=0A= =0A= dot1sPortOperPointToPoint OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 11 }=0A= =0A= dot1sPortHelloTime OBJECT-TYPE=0A= SYNTAX Timeout (100..1000)=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 12 }=0A= =0A= dot1sPortAdminNonStp OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 13 }=0A= =0A= dot1sPortProtocolMigration OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 14 }=0A= =0A= dot1sPortRxTcnBpduCounter OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 15 }=0A= =0A= dot1sPortRxCfgBpduCounter OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 16 }=0A= =0A= dot1sPortRxRstBpduCounter OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 17 }=0A= =0A= dot1sPortTxMstBpduCounter OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 18 }=0A= =0A= dot1sPortTxTcnBpduCounter OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 19 }=0A= =0A= dot1sPortTxCfgBpduCounter OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 20 }=0A= =0A= dot1sPortTxRstBpduCounter OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 21 }=0A= =0A= dot1sPortTxMstBpduCounter OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 22 }=0A= =0A= =0A= dot1sMapTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF Dot1sMapEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION=0A= "MST Configuration table (VID=3D>MSTID translation): = allocates=0A= each and every possible VLAN to CST or a specific MSTI."=0A= ::=3D { dot1s 12 }=0A= =0A= dot1sMapEntry OBJECT-TYPE=0A= SYNTAX Dot1sMapEntry=0A= MAX-ACCESS not-accessible=0A= STATUS mandatory=0A= DESCRIPTION=0A= "MST Configuration table (VID=3D>MSTID translation): = allocates=0A= each and every possible VLAN to CST or a specific MSTI."=0A= INDEX { dot1sMapMSTiID, dot1sMapVlanId }=0A= ::=3D { dot1sMapTable 1 }=0A= =0A= Dot1sMapEntry ::=3D SEQUENCE {=0A= dot1sMapMSTiID MstiInstanceIndex,=0A= dot1sMapVlanId Integer32,=0A= dot1sMapRowStatus INTEGER=0A= }=0A= =0A= dot1sMapMSTiID OBJECT-TYPE=0A= SYNTAX MstiInstanceIndex=0A= MAX-ACCESS not-accessible=0A= STATUS mandatory=0A= DESCRIPTION=0A= "GETNEXT opration shows only entries, which have = non-zero=0A= dot1sMapVlanId."=0A= ::=3D { dot1sMapEntry 1 }=0A= =0A= dot1sMapVlanId OBJECT-TYPE=0A= SYNTAX Integer32 (0..4095)=0A= MAX-ACCESS not-accessible=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sMapEntry 2 }=0A= =0A= dot1sMapRowStatus OBJECT-TYPE=0A= SYNTAX INTEGER {=0A= create(1),=0A= delete(2),=0A= exists(3),=0A= isAbsent(4)=0A= }=0A= MAX-ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sMapEntry 3 }=0A= =0A= dot1sXstTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF Dot1sXstEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1s 13 }=0A= =0A= dot1sXstEntry OBJECT-TYPE=0A= SYNTAX Dot1sXstEntry=0A= MAX-ACCESS not-accessible=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= INDEX { dot1sXstId }=0A= ::=3D { dot1sXstTable 1 }=0A= =0A= Dot1sXstEntry ::=3D SEQUENCE {=0A= dot1sXstId MstiOrCistInstanceIndex,=0A= dot1sXstBridgePriority Integer32,=0A= dot1sXstBridgeId BridgeId,=0A= dot1sXstDesignatedRoot BridgeId,=0A= dot1sXstDesignatedBridge BridgeId,=0A= dot1sXstInternalRootCost Integer32,=0A= dot1sXstRootPort dot1sXstRootPort,=0A= dot1sXstTimeSinceTopologyChange TimeTicks,=0A= dot1sXstTopologyChangesCount Counter32,=0A= dot1sXstTopologyChangeFlag TruthValue=0A= }=0A= =0A= dot1sXstId OBJECT-TYPE=0A= SYNTAX MstiOrCistInstanceIndex=0A= MAX-ACCESS not-accessible=0A= STATUS mandatory=0A= DESCRIPTION=0A= "0 means CIST."=0A= ::=3D { dot1sXstEntry 1 }=0A= =0A= =0A= dot1sXstBridgePriority OBJECT-TYPE=0A= SYNTAX Integer32 (0..61440)=0A= MAX-ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "Bridge priority, in steps of 4096."=0A= DEFVAL { 32768 }=0A= ::=3D { dot1sXstEntry 2 }=0A= =0A= dot1sXstBridgeId OBJECT-TYPE=0A= SYNTAX BridgeId=0A= MAX-ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstEntry 3 }=0A= =0A= dot1sXstDesignatedRoot OBJECT-TYPE=0A= SYNTAX BridgeId=0A= MAX-ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstEntry 4 }=0A= =0A= dot1sXstDesignatedBridge OBJECT-TYPE=0A= SYNTAX BridgeId=0A= MAX-ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstEntry 5 }=0A= =0A= dot1sXstInternalRootCost OBJECT-TYPE=0A= SYNTAX Integer32=0A= MAX-ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstEntry 6 }=0A= =0A= dot1sXstRootPort OBJECT-TYPE=0A= SYNTAX PortIndexOrZero=0A= MAX-ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstEntry 7 }=0A= =0A= dot1sXstTimeSinceTopologyChange OBJECT-TYPE=0A= SYNTAX TimeTicks=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstEntry 11 }=0A= =0A= dot1sXstTopologyChangesCount OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstEntry 12 }=0A= =0A= dot1sXstTopologyChangeFlag OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstEntry 13 }=0A= =0A= =0A= dot1sXstPortTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF Dot1sXstPortEntry=0A= ACCESS not-accessible=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1s 14 }=0A= =0A= dot1sXstPortEntry OBJECT-TYPE=0A= SYNTAX Dot1sXstPortEntry=0A= ACCESS not-accessible=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= REFERENCE=0A= "."=0A= INDEX { dot1sXstPortXstId, dot1sXstPortIndex }=0A= ::=3D { dot1sXstPortTable 1 }=0A= =0A= =0A= Dot1sXstPortEntry ::=3D=0A= SEQUENCE {=0A= dot1sXstPortXstId = MstiOrCistInstanceIndex,=0A= dot1sXstPortIndex PortIndex,=0A= dot1sXstPortState INTEGER, =0A= dot1sXstPortRole INTEGER, =0A= dot1sXstPortDesignatedRoot BridgeId,=0A= dot1sXstPortExternalRootCost Integer32,=0A= dot1sXstPortRegionalBridge BridgeId,=0A= dot1sXstPortInternalRootCost Integer32,=0A= dot1sXstPortDesignatedBridge BridgeId,=0A= dot1sXstPortDesignatedPort PortId,=0A= dot1sXstPortPriority Integer32,=0A= dot1sXstPortAdminInternalPathCost Integer32,=0A= dot1sXstPortOperInternalPathCost Integer32=0A= }=0A= =0A= dot1sXstPortXstId OBJECT-TYPE=0A= SYNTAX MstiOrCistInstanceIndex=0A= MAX-ACCESS not-accessible=0A= STATUS mandatory=0A= DESCRIPTION=0A= "0 means CIST."=0A= ::=3D { dot1sXstPortEntry 1 }=0A= =0A= dot1sXstPortIndex OBJECT-TYPE=0A= SYNTAX PortIndex=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "The value of dot1sPortIndex of the = Port=0A= in dot1sPortTable."=0A= ::=3D { dot1sXstPortEntry 2 }=0A= =0A= dot1sXstPortState OBJECT-TYPE =0A= SYNTAX INTEGER {=0A= disabled(1),=0A= discarding(1),=0A= learning(2),=0A= forwarding(3),=0A= unknown(4)=0A= }=0A= =0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstPortEntry 3 }=0A= =0A= dot1sXstPortRole OBJECT-TYPE =0A= SYNTAX INTEGER {=0A= disabled(1),=0A= alternate(2),=0A= backup(3), =0A= root(4),=0A= designated(5),=0A= master(6),=0A= nonStp(7),=0A= unknown(8)=0A= }=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstPortEntry 4 }=0A= =0A= dot1sXstPortDesignatedRoot OBJECT-TYPE =0A= SYNTAX BridgeId=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstPortEntry 6 }=0A= =0A= dot1sXstPortExternalRootCost OBJECT-TYPE =0A= SYNTAX Integer32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstPortEntry 7 }=0A= =0A= dot1sXstPortRegionalBridge OBJECT-TYPE =0A= SYNTAX BridgeId=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstPortEntry 8 }=0A= =0A= dot1sXstPortInternalRootCost OBJECT-TYPE =0A= SYNTAX Integer32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstPortEntry 9 }=0A= =0A= dot1sXstPortDesignatedBridge OBJECT-TYPE =0A= SYNTAX BridgeId=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstPortEntry 10 }=0A= =0A= dot1sXstPortDesignatedPort OBJECT-TYPE =0A= SYNTAX PortId=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstPortEntry 14 }=0A= =0A= dot1sXstPortPriority OBJECT-TYPE =0A= SYNTAX Integer32 (0..255)=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION=0A= "Port priority, in steps of 16."=0A= DEFVAL { 128 }=0A= ::=3D { dot1sXstPortEntry 15 }=0A= =0A= dot1sXstPortAdminInternalPathCost OBJECT-TYPE =0A= SYNTAX Integer32 (0..200000000)=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION=0A= "The value 0 means, that the cost = will be selected=0A= automatically."=0A= ::=3D { dot1sXstPortEntry 16 }=0A= =0A= dot1sXstPortOperInternalPathCost OBJECT-TYPE=0A= SYNTAX Integer32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstPortEntry 17 }=0A= =0A= -- Traps=0A= =0A= dot1sTraps OBJECT IDENTIFIER ::=3D { dot1s 0 }=0A= =0A= dos1sNewRootBridge NOTIFICATION-TYPE=0A= OBJECTS { dot1sXstId }=0A= STATUS current=0A= DESCRIPTION=0A= "The dos1sNewRootBridge trap indicates that the=0A= sending agent has become the new root of the=0A= Spanning Tree in the CIST or in any MSTI; the=0A= trap is sent by a bridge soon after its election=0A= as the new root, e.g., upon expiration of the=0A= Topology Change Timer immediately subsequent to=0A= its election. Implementation of this trap is=0A= optional."=0A= ::=3D { dot1sTraps 1 }=0A= =0A= dos1sNewRootPort NOTIFICATION-TYPE=0A= OBJECTS { dot1sXstId, dot1sXstPortIndex }=0A= STATUS current=0A= DESCRIPTION=0A= "The dos1sNewRootPort trap indicates that the=0A= sending agent has changed the root Port of the=0A= Spanning Tree in the CIST or in any MSTI. If the = instance=0A= has become a root one, the sending value of the=0A= parameter dot1sXstPortIndex is equal to zero. The=0A= trap is sent by a bridge soon after its election=0A= as the new root Port, e.g., upon expiration of the=0A= Topology Change Timer immediately subsequent to=0A= its election. Implementation of this trap is=0A= optional."=0A= ::=3D { dot1sTraps 2 }=0A= =0A= dos1sTopologyChange NOTIFICATION-TYPE=0A= OBJECTS { dot1sXstId, dot1sXstPortIndex, dot1sXstPortState }=0A= STATUS current=0A= DESCRIPTION=0A= "A dos1sTopologyChange trap is sent by a bridge = when=0A= any of its configured ports n any instance (CIST = or MSTI)=0A= transitions from the=0A= Learning state to the Forwarding state, or from=0A= the Forwarding state to the Blocking state. The=0A= trap is not sent if a dos1sNewRootBridge trap is = sent for the=0A= same transition. Implementation of this trap is=0A= optional."=0A= ::=3D { dot1sTraps 3 }=0A= =0A= END=0A= =0A= 5. Acknowledgments This document was produced on behalf of the Bridge MIB Working Group in the Operations and Management area of the Internet Engineering Task Force. 6. Security Considerations Security Issues are not discussed in this memo. 7. References [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, An Architecture for Describing SNMP Management Frameworks, RFC 2571, April 1999. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, Structure of Management Information Version 2 (SMIv2), STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, Textual Conventions for SMIv2, STD 58, RFC 2579, April 1999. [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2), RFC 1905, January 1996. [RFC1493] Decker, E., Langille, P., Rijsinghani, A. and K. McCloghrie, "Definitions of Managed Objects for Bridges", RFC 1493, July 1993. [802.1d] IEEE 802.1d-1998, "IEEE Standard for Information technology Telecommunications and information exchange between systems Local and metropolitan area networks - Common = Specifications Part 3: Media Access Control (MAC) Bridges". [802.1w] IEEE 802.1w-2001, "(Amendment to IEEE Standard 802.1D) IEEE Standard for Information technology - Telecommunications = and information exchange between systems - Local and metropolitan area networks--Common Specifications - Part 3: Media Access Control (MAC) Bridges: Rapid Reconfiguation". [802.1s] IEEE 802.1s-2002, "(Amendment to IEEE Standard 802.1Q) IEEE Standard for Local and metropolitan area networks-Virtual Bridged Local Area Networks-Amendment 3: Multiple Spanning=20 Trees. 8. Authors' Addresses T.B.D. 9. Full Copyright Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, = copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. =0A= ------=_NextPart_000_0166_01C4C0E5.37485EB0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib ------=_NextPart_000_0166_01C4C0E5.37485EB0-- From bridge-mib-bounces@ietf.org Tue Nov 2 12:01:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11782 for ; Tue, 2 Nov 2004 12:01:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP2HW-000702-Ek for bridge-mib-archive@ietf.org; Tue, 02 Nov 2004 12:17:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1nC-00060R-EP; Tue, 02 Nov 2004 11:45:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1TM-0002oo-L1 for bridge-mib@megatron.ietf.org; Tue, 02 Nov 2004 11:25:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06220 for ; Tue, 2 Nov 2004 11:25:26 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1iU-0005gr-Qr for bridge-mib@ietf.org; Tue, 02 Nov 2004 11:41:07 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 1BAFF2F6C; Tue, 2 Nov 2004 17:24:55 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 29791-08; Tue, 2 Nov 2004 17:24:54 +0100 (CET) Received: from james (james.public.iu-bremen.de [212.201.46.187]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 133EC2F60; Tue, 2 Nov 2004 17:24:54 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CP1So-00016f-L2; Tue, 02 Nov 2004 17:24:54 +0100 Date: Tue, 2 Nov 2004 17:24:54 +0100 From: Juergen Schoenwaelder To: Les Bell Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 Message-ID: <20041102162454.GA4231@james> Mail-Followup-To: Les Bell , bridge-mib@ietf.org References: <80256F40.003616A1.00@notesmta.eur.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80256F40.003616A1.00@notesmta.eur.3com.com> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca On Tue, Nov 02, 2004 at 09:50:14AM +0000, Les Bell wrote: > Use of the 32-bit path cost was defined in both 802.1w (RSTP) and 802.1t. > 802.1t was a collection of enhacements to Bridges, including those that support > legacy STP. So the 32-bit path costs do not just apply to RSTP. > > I think you are right that dot1dStpPortPathCost32 should be conditionally > mandatory, but for any Spanning Tree implementation that supports 32-bit path > costs, not just for RSTP. OK, that language makes sense. > Implementations that support 32-bit path costs should not use the 16-bit path > cost object, dot1dStpPortPathCost, but I am not sure what is the best way to > deal with this. Are we allowed to allocate a special value to indicate it is > not in use? I think it would be safer to return an SNMP error indicating the > old object is not supported. I guess we need to discuss this next week. I know that this issue was discussed before, but we have to make a real engineering decision here. There are several issues involved as far as I can tell: a) Formally, we are not expected (or even allowed?) to add objects while moving from Draft to Standard. So this needs careful consideration from the IETF procedures perspective and support by the AD. b) According to the SMIv2 rules, we can't change the range of the original 16 bit object and have to introduce the new object as done in the current ID. Your question what implementations should do that support 32-bit path costs with the old object requires consideration. Not sure there is a path cost which can be used as a special value (and doing so would most likely change existing semantics) so the requirement might indeed be not to support that object (at least if the value is outside the range). c) It would be nice to know what existing implementations do. I guess that implementation wise simply removing the range restriction is probably the easiest thing to do on the agent. It is hard to judge whether this seriously impacts real-world managers interoperability. If there are implementations which did follow this approach, then this might be important information to consider. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Tue Nov 2 12:48:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16877 for ; Tue, 2 Nov 2004 12:48:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP315-0008Kr-3V for bridge-mib-archive@ietf.org; Tue, 02 Nov 2004 13:04:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP2Wd-0006RI-ET; Tue, 02 Nov 2004 12:32:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP23m-00074z-AJ for bridge-mib@megatron.ietf.org; Tue, 02 Nov 2004 12:03:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11949 for ; Tue, 2 Nov 2004 12:03:04 -0500 (EST) Message-Id: <200411021703.MAA11949@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP2Is-00071z-CE for bridge-mib@ietf.org; Tue, 02 Nov 2004 12:18:45 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <20041102170227015007mp8pe>; Tue, 2 Nov 2004 17:02:28 +0000 From: "David B Harrington" To: "'Les Bell'" , Subject: RE: [Bridge-mib] dot1dStpPortPathCost32 Date: Tue, 2 Nov 2004 12:02:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTAw+SfYolvJfVPQL29CMWqKf+QbgAOXZBA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <80256F40.003616A1.00@notesmta.eur.3com.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit I'm not very knowledgeable about the new object, but I think the support should be conditionally mandatory, and the condition should spell out that one or the other should be used. An alternative would be to have different compliance caluses, one to support the older compliance rules and another to support the new compliance rules, but if there's only one object that would be mandatory in the new clause, that doesn't seem worth it. dbh -----Original Message----- From: bridge-mib-bounces@ietf.org [mailto:bridge-mib-bounces@ietf.org] On Behalf Of Les Bell Sent: Tuesday, November 02, 2004 4:50 AM To: j.schoenwaelder@iu-bremen.de Cc: bridge-mib@ietf.org Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 Use of the 32-bit path cost was defined in both 802.1w (RSTP) and 802.1t. 802.1t was a collection of enhacements to Bridges, including those that support legacy STP. So the 32-bit path costs do not just apply to RSTP. I think you are right that dot1dStpPortPathCost32 should be conditionally mandatory, but for any Spanning Tree implementation that supports 32-bit path costs, not just for RSTP. Implementations that support 32-bit path costs should not use the 16-bit path cost object, dot1dStpPortPathCost, but I am not sure what is the best way to deal with this. Are we allowed to allocate a special value to indicate it is not in use? I think it would be safer to return an SNMP error indicating the old object is not supported. Les... Juergen Schoenwaelder @ietf.org on 22/10/2004 12:05:23 Please respond to j.schoenwaelder@iu-bremen.de Sent by: bridge-mib-bounces@ietf.org To: bridge-mib@ietf.org cc: Subject: [Bridge-mib] dot1dStpPortPathCost32 The revised BRIDGE-MIB adds dot1dStpPortPathCost32 and makes it mandatory. I think this is broken since existing deployed implementations won't support that object and thus are not compliant. Can someone please explain in which situations the increased range of dot1dStpPortPathCost32 is actually needed? Is this only relevant for rapid spanning tree? In that case, I think the object should be conditionally mandatory for boxes that do rapid spanning tree and the old one stays current, probably with a special value to use in case dot1dStpPortPathCost32 actually has the larger path cost. Please give advise. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Tue Nov 2 12:51:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17200 for ; Tue, 2 Nov 2004 12:51:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP34H-0008Qf-9X for bridge-mib-archive@ietf.org; Tue, 02 Nov 2004 13:07:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP2Wf-0006Uv-EB; Tue, 02 Nov 2004 12:32:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP25o-0007X9-7R for bridge-mib@megatron.ietf.org; Tue, 02 Nov 2004 12:05:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12167 for ; Tue, 2 Nov 2004 12:05:09 -0500 (EST) Message-Id: <200411021705.MAA12167@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP2Kw-00075d-8U for bridge-mib@ietf.org; Tue, 02 Nov 2004 12:20:51 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <2004110217043601400sc25pe>; Tue, 2 Nov 2004 17:04:37 +0000 From: "David B Harrington" To: Date: Tue, 2 Nov 2004 12:04:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTA/gXbDlcp0SI6Qf6eOZYLoOiBng== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] Note takers X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Hi, I am looking for volunteers to be notetakers and jabber scribes at the bridge WG session at IETF61. Please respond off-list. Thanks, David Harrington dbharrington@comcast.net _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Tue Nov 2 13:00:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18422 for ; Tue, 2 Nov 2004 13:00:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP3CY-0000Hd-Pd for bridge-mib-archive@ietf.org; Tue, 02 Nov 2004 13:16:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP2ja-0003uQ-Al; Tue, 02 Nov 2004 12:46:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP2Vz-0005wE-7H for bridge-mib@megatron.ietf.org; Tue, 02 Nov 2004 12:32:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15305 for ; Tue, 2 Nov 2004 12:32:12 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP2l8-0007uf-Gi for bridge-mib@ietf.org; Tue, 02 Nov 2004 12:47:55 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iA2HO6qn006599 for ; Tue, 2 Nov 2004 12:24:06 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iA2HMeqn005392 for ; Tue, 2 Nov 2004 12:23:03 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Bridge-mib] dot1dStpPortPathCost32 Date: Tue, 2 Nov 2004 19:30:11 +0200 Message-ID: Thread-Topic: [Bridge-mib] dot1dStpPortPathCost32 Thread-Index: AcTA/sh+Y7VYDYa9TC6BaVk4pe3uEgAApJaQ From: "Romascanu, Dan \(Dan\)" To: , "Les Bell" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Unless I am missing something, I do not see how such a change would not = mandate returning to Proposed.=20 Regards, Dan >=20 > a) Formally, we are not expected (or even allowed?) to add=20 > objects while > moving from Draft to Standard. So this needs careful consideration > from the IETF procedures perspective and support by the AD. >=20 _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Tue Nov 2 15:06:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04756 for ; Tue, 2 Nov 2004 15:06:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP5AA-0003tf-56 for bridge-mib-archive@ietf.org; Tue, 02 Nov 2004 15:21:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP4nT-0002IN-Rx; Tue, 02 Nov 2004 14:58:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP4dQ-0005zV-Lc for bridge-mib@megatron.ietf.org; Tue, 02 Nov 2004 14:48:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02919 for ; Tue, 2 Nov 2004 14:48:03 -0500 (EST) Message-Id: <200411021948.OAA02919@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP4sM-0003QO-47 for bridge-mib@ietf.org; Tue, 02 Nov 2004 15:03:33 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <2004110219471601400sdjj5e>; Tue, 2 Nov 2004 19:47:17 +0000 From: "David B Harrington" To: , "'Les Bell'" , Subject: RE: [Bridge-mib] dot1dStpPortPathCost32 Date: Tue, 2 Nov 2004 14:47:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTAw+SfYolvJfVPQL29CMWqKf+QbgAOXZBAAAW72SA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <200411021703.MAA11949@ietf.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit Cc: bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Hi, Can we resolve this (and any other issues) on the mailing list before IETF61, please? These mib modules are already three years behind the charter schedule. We want to start the WG last call before IETF61, not wait until IETF61 to start discussing possible solutions. dbh > -----Original Message----- > From: bridge-mib-bounces@ietf.org > [mailto:bridge-mib-bounces@ietf.org] On Behalf Of David B Harrington > Sent: Tuesday, November 02, 2004 12:02 PM > To: 'Les Bell'; j.schoenwaelder@iu-bremen.de > Cc: bridge-mib@ietf.org > Subject: RE: [Bridge-mib] dot1dStpPortPathCost32 > > I'm not very knowledgeable about the new object, but I think > the support should be conditionally mandatory, and the > condition should spell out that one or the other should be used. > > An alternative would be to have different compliance caluses, > one to support the older compliance rules and another to > support the new compliance rules, but if there's only one > object that would be mandatory in the new clause, that > doesn't seem worth it. > > dbh > > > -----Original Message----- > From: bridge-mib-bounces@ietf.org [mailto:bridge-mib-bounces@ietf.org] > On Behalf Of Les Bell > Sent: Tuesday, November 02, 2004 4:50 AM > To: j.schoenwaelder@iu-bremen.de > Cc: bridge-mib@ietf.org > Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 > > > > > Use of the 32-bit path cost was defined in both 802.1w (RSTP) > and 802.1t. > 802.1t was a collection of enhacements to Bridges, including > those that support legacy STP. So the 32-bit path costs do > not just apply to RSTP. > > I think you are right that dot1dStpPortPathCost32 should be > conditionally mandatory, but for any Spanning Tree > implementation that supports 32-bit path costs, not just for RSTP. > > Implementations that support 32-bit path costs should not use > the 16-bit path cost object, dot1dStpPortPathCost, but I am > not sure what is the best way to deal with this. Are we > allowed to allocate a special value to indicate it is not in > use? I think it would be safer to return an SNMP error > indicating the old object is not supported. > > Les... > > > > > > Juergen Schoenwaelder @ietf.org on > 22/10/2004 > 12:05:23 > > Please respond to j.schoenwaelder@iu-bremen.de > > Sent by: bridge-mib-bounces@ietf.org > > > To: bridge-mib@ietf.org > cc: > Subject: [Bridge-mib] dot1dStpPortPathCost32 > > > The revised BRIDGE-MIB adds dot1dStpPortPathCost32 and makes > it mandatory. I think this is broken since existing deployed > implementations won't support that object and thus are not compliant. > Can someone please explain in which situations the increased range of > dot1dStpPortPathCost32 is actually needed? > Is this only relevant for rapid spanning tree? In that case, > I think the object should be conditionally mandatory for > boxes that do rapid spanning tree and the old one stays > current, probably with a special value to use in case > dot1dStpPortPathCost32 actually has the larger path cost. > > Please give advise. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, > Germany > > _______________________________________________ > Bridge-mib mailing list > Bridge-mib@ietf.org > https://www1.ietf.org/mailman/listinfo/bridge-mib > > > > > > _______________________________________________ > Bridge-mib mailing list > Bridge-mib@ietf.org > https://www1.ietf.org/mailman/listinfo/bridge-mib > > > > _______________________________________________ > Bridge-mib mailing list > Bridge-mib@ietf.org > https://www1.ietf.org/mailman/listinfo/bridge-mib > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Tue Nov 2 15:48:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10283 for ; Tue, 2 Nov 2004 15:48:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP5pK-0005KH-Ee for bridge-mib-archive@ietf.org; Tue, 02 Nov 2004 16:04:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP5My-0001nv-Jw; Tue, 02 Nov 2004 15:35:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP5C8-00013T-PG for bridge-mib@megatron.ietf.org; Tue, 02 Nov 2004 15:23:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07186 for ; Tue, 2 Nov 2004 15:23:55 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP5RG-0004Kt-HW for bridge-mib@ietf.org; Tue, 02 Nov 2004 15:39:38 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id B8A9E2F82; Tue, 2 Nov 2004 21:23:21 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 11692-06; Tue, 2 Nov 2004 21:23:20 +0100 (CET) Received: from james (Ib121.i.pppool.de [85.73.177.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 93EF02F87; Tue, 2 Nov 2004 21:23:18 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CP5BQ-0000eT-JF; Tue, 02 Nov 2004 21:23:12 +0100 Date: Tue, 2 Nov 2004 21:23:12 +0100 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 Message-ID: <20041102202312.GA2450@james> Mail-Followup-To: David B Harrington , ietfdbh@comcast.net, 'Les Bell' , bridge-mib@ietf.org References: <200411021703.MAA11949@ietf.org> <200411021948.OAA02919@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411021948.OAA02919@ietf.org> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "'Les Bell'" , ietfdbh@comcast.net, bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca On Tue, Nov 02, 2004 at 02:47:11PM -0500, David B Harrington wrote: > Can we resolve this (and any other issues) on the mailing list before > IETF61, please? Will be hard, but we can try. > These mib modules are already three years behind the charter schedule. Yes. But since the IETF meeting is next week, I would say that this week does not cause any significant delay. > We want to start the WG last call before IETF61, not wait until IETF61 > to start discussing possible solutions. Lets try to collect possible solutions: a) We remove the 32-bit path cost, move the BRIDGE-MIB to Standard and start a new MIB module which defines the new object. a') We remove the 32-bit path cost, move the BRIDGE-MIB to Standard and tell the IEEE or who cares that they have to address this issue. b) We agree to change the range restriction by declaring that an error or bug fix (even though it really is not, well yeah ...). We don't introduce a new object, stepping of course formally on SMIv2 rules. c) We do what the document currently does (introducing a new object) and move the whole MIB module back to Proposed. d) We do what the document currently does and move forward, looking for the IESG feedback. Note that RFC 2026 says that a Draft standard "is normally considered to be a final specification, and changes are likely to be made only to solve specific problems encountered." Perhaps this is a specific problem encountered... e) We drop the whole document and just stick to RFC 1493. Any options I did forget? Any ideas how to select the winner? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Wed Nov 3 12:47:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02010 for ; Wed, 3 Nov 2004 12:47:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPPTj-0002hl-WC for bridge-mib-archive@ietf.org; Wed, 03 Nov 2004 13:03:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPP85-0002MW-OW; Wed, 03 Nov 2004 12:41:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPP2B-0000qq-Dq for bridge-mib@megatron.ietf.org; Wed, 03 Nov 2004 12:34:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00472 for ; Wed, 3 Nov 2004 12:34:56 -0500 (EST) Message-Id: <200411031734.MAA00472@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPPHX-0002Ir-7j for bridge-mib@ietf.org; Wed, 03 Nov 2004 12:50:51 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <20041103173418015007gv6ie>; Wed, 3 Nov 2004 17:34:18 +0000 From: "David B Harrington" To: Date: Wed, 3 Nov 2004 12:34:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTBy1VUODoviiRlT4m4H+uVOWNMQA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] WG Last Call:dratf-ietf-bridge-ext-v2-03.txt X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Hi, This starts the WG last call for the update to RFC2674. We missed the IETF61 publication deadline, so the document can be found at: http://www.ibr.cs.tu-bs.de/users/schoenw/draft-ietf-bridge-ext-v2-03.t xt The WG last call will end November 23. This date has been chosen to ensure that 1) IETF61 attendees have two weeks to perform reviews, 2) attendees of the IEEE meeting the following week have two weeks to perform reviews, 3) the ID publication lockout is lifted and the document becomes available in the normal repository If anybody has objection to this date, please post your concerns to bridge-mib@ietf.org. If anybody has comments on the draft, please post them to bridge-mib@ietf.org Thanks, David Harrington dbharrington@comcast.net Bridge-mib co-chair _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Nov 4 10:48:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02435 for ; Thu, 4 Nov 2004 10:48:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPk5y-0007Pl-08 for bridge-mib-archive@ietf.org; Thu, 04 Nov 2004 11:04:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPjhi-0000Wk-8K; Thu, 04 Nov 2004 10:39:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPjcV-0007sB-Dz for bridge-mib@megatron.ietf.org; Thu, 04 Nov 2004 10:33:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01397 for ; Thu, 4 Nov 2004 10:33:49 -0500 (EST) Message-Id: <200411041533.KAA01397@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPjrx-00075b-2u for bridge-mib@ietf.org; Thu, 04 Nov 2004 10:49:56 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <20041104153310015007cvbbe>; Thu, 4 Nov 2004 15:33:10 +0000 From: "David B Harrington" To: Date: Thu, 4 Nov 2004 10:33:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTBGdCFpISCcWJvQsifS9Kn3UEYBgBZV8EA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <20041102202312.GA2450@james> X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] Consensus Call X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit OK, Let me start a discussion here. This is important for a consensus check, so please read and respond. My experience has been working for an equipment vendor. I have worked in both the embedded system space and the pure vendor-neutral software solution space. Here is what I have learned from that experience. Mib module official status becomes important on the agent side first; once a mib hits PS it's a valid target for inclusion in project plans (for those products that include the managed functionality). While some mib modules get implemented from an I-D, the RFC publication finalizes the design and an RFC# is marketable. Advancement to DS or FS makes little difference - if the functionality is in the box, the mib module should be done fairly soon after the functionality is available, and if there is an RFC-level standard, that's good. The tweaking that occurs between PS and DS and between DS and FS makes little difference to an equipment vendor (except as non-marketable maintenance work). MIB modules become important to vendor-neutral software developers when enough equipment vendors support the MIB module to make it worthwhile directly supporting it, and there is customer demand for consistent management of the functionality. Most vendor-neutral software vendors use table-driven or model-driven designs that largely hide whether the implementation is the industry standard MIB module or a proprietary MIB module with similar capabilites. The status of a MIB module standard is largely irrelevant; the customer demand exists or it doesn't. So, we are now faced with a decision to publish the SMIv2 version of RFC1493 **with no semantic changes** or to publish an updated MIB module that reflects the current underlying IEEE standard better, by supporting 32-bit PathCost rather than only the 16-bit PathCost. How many people on this list actually care whether the standard status is at PS or DS or FS, and why? Will advancing the standards level have an **actual** impact on whether the implementation is done by your company? Would recycling the MIB module at PS have a negative effect on your company and its revenue stream? Would the benefit of having a MIB module that is more current with IEEE standards offset any negatives of recycling at PS? If you are not associated with a company, but rather a university or an open-source product or whatever, will the status level have a real impact on what you do? Ultimately the question to be answered is: Should we diminish the functionality in order to advance the document in the standards track, or should we add the 32-bit functionality even if we have to recycle at Proposed? Thanks, David Harrington dbharrington@comcast.net Bridge-mib co-chair > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] On > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, November 02, 2004 3:23 PM > To: David B Harrington > Cc: ietfdbh@comcast.net; 'Les Bell'; bridge-mib@ietf.org > Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 > > On Tue, Nov 02, 2004 at 02:47:11PM -0500, David B Harrington wrote: > > > Can we resolve this (and any other issues) on the mailing > list before > > IETF61, please? > > Will be hard, but we can try. > > > These mib modules are already three years behind the > charter schedule. > > Yes. But since the IETF meeting is next week, I would say > that this week does not cause any significant delay. > > > We want to start the WG last call before IETF61, not wait > until IETF61 > > to start discussing possible solutions. > > Lets try to collect possible solutions: > > a) We remove the 32-bit path cost, move the BRIDGE-MIB to Standard and > start a new MIB module which defines the new object. > > a') We remove the 32-bit path cost, move the BRIDGE-MIB to > Standard and > tell the IEEE or who cares that they have to address this issue. > > b) We agree to change the range restriction by declaring that an error > or bug fix (even though it really is not, well yeah ...). We don't > introduce a new object, stepping of course formally on SMIv2 rules. > > c) We do what the document currently does (introducing a new object) > and move the whole MIB module back to Proposed. > > d) We do what the document currently does and move forward, > looking for > the IESG feedback. Note that RFC 2026 says that a Draft > standard "is > normally considered to be a final specification, and changes are > likely to be made only to solve specific problems encountered." > Perhaps this is a specific problem encountered... > > e) We drop the whole document and just stick to RFC 1493. > > Any options I did forget? > > Any ideas how to select the winner? > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Nov 4 11:35:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07534 for ; Thu, 4 Nov 2004 11:35:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPkq6-00009q-I3 for bridge-mib-archive@ietf.org; Thu, 04 Nov 2004 11:51:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPkPo-0002W1-S8; Thu, 04 Nov 2004 11:24:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPkL2-0001RV-UX for bridge-mib@megatron.ietf.org; Thu, 04 Nov 2004 11:19:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06025 for ; Thu, 4 Nov 2004 11:19:51 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPkab-0008EH-OA for bridge-mib@ietf.org; Thu, 04 Nov 2004 11:35:58 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iA4GBgbh019214 for ; Thu, 4 Nov 2004 11:11:43 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iA4G9fbh016423 for ; Thu, 4 Nov 2004 11:10:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Bridge-mib] Consensus Call Date: Thu, 4 Nov 2004 18:15:56 +0200 Message-ID: Thread-Topic: [Bridge-mib] Consensus Call Thread-Index: AcTBGdCFpISCcWJvQsifS9Kn3UEYBgBZV8EAAAJBINA= From: "Romascanu, Dan \(Dan\)" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: quoted-printable X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: quoted-printable Speaking as a contributor - I always favored the approach that we should = rather update the standard and recycle at Proposed, than progress MIB = modules on the standard track, while they are not exactly in synch with = the IEEE standard. This is the line they we also took in the Ethernet = MIB WG.=20 My employer is a mostly enterprise space vendor. I am not official = speaker for the company, but I could cautiously say that my impression = is that our customers do not care too much about the IETF Standards = Status. If a standard does its job and ensures interoperability between = vendors its fine with them.=20 Only a small category of customers would look at the standards status = before entering it in an RFP. However, my impression is that these = customers will first include the IEEE 802.1 standard, and only second = the MIB standard. What is the good of having a Full Standard with a MIB = that is not in synch with the IEEE specification?=20 In conclusion I personally favor option c in Bert's mail.=20 Regards, Dan > -----Original Message----- > From: bridge-mib-bounces@ietf.org=20 > [mailto:bridge-mib-bounces@ietf.org]On Behalf Of David B Harrington > Sent: 04 November, 2004 5:33 PM > To: bridge-mib@ietf.org > Subject: [Bridge-mib] Consensus Call >=20 >=20 > OK, Let me start a discussion here. This is important for a consensus > check, so please read and respond. >=20 > My experience has been working for an equipment vendor. I have worked > in both the embedded system space and the pure vendor-neutral software > solution space. Here is what I have learned from that experience. >=20 > Mib module official status becomes important on the agent side first; > once a mib hits PS it's a valid target for inclusion in project plans > (for those products that include the managed functionality). While > some mib modules get implemented from an I-D, the RFC publication > finalizes the design and an RFC# is marketable. Advancement to DS or > FS makes little difference - if the functionality is in the box, the > mib module should be done fairly soon after the functionality is > available, and if there is an RFC-level standard, that's good. The > tweaking that occurs between PS and DS and between DS and FS makes > little difference to an equipment vendor (except as non-marketable > maintenance work). >=20 > MIB modules become important to vendor-neutral software developers > when enough equipment vendors support the MIB module to make it > worthwhile directly supporting it, and there is customer demand for > consistent management of the functionality. Most vendor-neutral > software vendors use table-driven or model-driven designs that largely > hide whether the implementation is the industry standard MIB module or > a proprietary MIB module with similar capabilites. The status of a MIB > module standard is largely irrelevant; the customer demand exists or > it doesn't. >=20 > So, we are now faced with a decision to publish the SMIv2 version of > RFC1493 **with no semantic changes** or to publish an updated MIB > module that reflects the current underlying IEEE standard better, by > supporting 32-bit PathCost rather than only the 16-bit PathCost. >=20 > How many people on this list actually care whether the standard status > is at PS or DS or FS, and why? Will advancing the standards level have > an **actual** impact on whether the implementation is done by your > company? Would recycling the MIB module at PS have a negative effect > on your company and its revenue stream? Would the benefit of having a > MIB module that is more current with IEEE standards offset any > negatives of recycling at PS? >=20 > If you are not associated with a company, but rather a university or > an open-source product or whatever, will the status level have a real > impact on what you do? >=20 > Ultimately the question to be answered is: Should we diminish the > functionality in order to advance the document in the standards track, > or should we add the 32-bit functionality even if we have to recycle > at Proposed? >=20 > Thanks, > David Harrington > dbharrington@comcast.net > Bridge-mib co-chair > =20 >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] On=20 > > Behalf Of Juergen Schoenwaelder > > Sent: Tuesday, November 02, 2004 3:23 PM > > To: David B Harrington > > Cc: ietfdbh@comcast.net; 'Les Bell'; bridge-mib@ietf.org > > Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 > >=20 > > On Tue, Nov 02, 2004 at 02:47:11PM -0500, David B Harrington wrote: > > =20 > > > Can we resolve this (and any other issues) on the mailing=20 > > list before=20 > > > IETF61, please? > >=20 > > Will be hard, but we can try. > > =20 > > > These mib modules are already three years behind the=20 > > charter schedule. > >=20 > > Yes. But since the IETF meeting is next week, I would say=20 > > that this week does not cause any significant delay. > > =20 > > > We want to start the WG last call before IETF61, not wait=20 > > until IETF61=20 > > > to start discussing possible solutions. > >=20 > > Lets try to collect possible solutions: > >=20 > > a) We remove the 32-bit path cost, move the BRIDGE-MIB to Standard > and > > start a new MIB module which defines the new object. > >=20 > > a') We remove the 32-bit path cost, move the BRIDGE-MIB to=20 > > Standard and > > tell the IEEE or who cares that they have to address this issue. > >=20 > > b) We agree to change the range restriction by declaring that an > error > > or bug fix (even though it really is not, well yeah ...). We > don't > > introduce a new object, stepping of course formally on SMIv2 > rules. > >=20 > > c) We do what the document currently does (introducing a new object) >=20 > > and move the whole MIB module back to Proposed. > >=20 > > d) We do what the document currently does and move forward,=20 > > looking for=20 > > the IESG feedback. Note that RFC 2026 says that a Draft=20 > > standard "is=20 > > normally considered to be a final specification, and changes are=20 > > likely to be made only to solve specific problems encountered."=20 > > Perhaps this is a specific problem encountered... > >=20 > > e) We drop the whole document and just stick to RFC 1493. > >=20 > > Any options I did forget? > >=20 > > Any ideas how to select the winner? > >=20 > > /js > >=20 > > --=20 > > Juergen Schoenwaelder International=20 > University Bremen > > P.O. Box 750 561,=20 > > 28725 Bremen, Germany > >=20 >=20 >=20 >=20 > _______________________________________________ > Bridge-mib mailing list > Bridge-mib@ietf.org > https://www1.ietf.org/mailman/listinfo/bridge-mib >=20 _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Nov 4 12:42:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14968 for ; Thu, 4 Nov 2004 12:42:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPlsz-00029H-AD for bridge-mib-archive@ietf.org; Thu, 04 Nov 2004 12:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPlRZ-0005fW-DI; Thu, 04 Nov 2004 12:30:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPlH7-0002Lz-1m for bridge-mib@megatron.ietf.org; Thu, 04 Nov 2004 12:19:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12988 for ; Thu, 4 Nov 2004 12:19:50 -0500 (EST) Message-Id: <200411041719.MAA12988@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPlWf-0001XA-Dm for bridge-mib@ietf.org; Thu, 04 Nov 2004 12:35:58 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc11) with SMTP id <2004110417191901300c0vmfe>; Thu, 4 Nov 2004 17:19:20 +0000 From: "David B Harrington" To: "'Romascanu, Dan \(Dan\)'" , Subject: RE: [Bridge-mib] Consensus Call Date: Thu, 4 Nov 2004 12:19:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTBGdCFpISCcWJvQsifS9Kn3UEYBgBZV8EAAAJBINAAAoIWAA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Content-Transfer-Encoding: 7bit X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Content-Transfer-Encoding: 7bit Just to be clear, that was Juergen's mail, not Bert's. dbh > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Thursday, November 04, 2004 11:16 AM > To: dbharrington@comcast.net; bridge-mib@ietf.org > Subject: RE: [Bridge-mib] Consensus Call > > Speaking as a contributor - I always favored the approach > that we should rather update the standard and recycle at > Proposed, than progress MIB modules on the standard track, > while they are not exactly in synch with the IEEE standard. > This is the line they we also took in the Ethernet MIB WG. > > My employer is a mostly enterprise space vendor. I am not > official speaker for the company, but I could cautiously say > that my impression is that our customers do not care too much > about the IETF Standards Status. If a standard does its job > and ensures interoperability between vendors its fine with them. > > Only a small category of customers would look at the > standards status before entering it in an RFP. However, my > impression is that these customers will first include the > IEEE 802.1 standard, and only second the MIB standard. What > is the good of having a Full Standard with a MIB that is not > in synch with the IEEE specification? > > In conclusion I personally favor option c in Bert's mail. > > Regards, > > Dan > > > > > -----Original Message----- > > From: bridge-mib-bounces@ietf.org > > [mailto:bridge-mib-bounces@ietf.org]On Behalf Of David B Harrington > > Sent: 04 November, 2004 5:33 PM > > To: bridge-mib@ietf.org > > Subject: [Bridge-mib] Consensus Call > > > > > > OK, Let me start a discussion here. This is important for a > consensus > > check, so please read and respond. > > > > My experience has been working for an equipment vendor. I > have worked > > in both the embedded system space and the pure > vendor-neutral software > > solution space. Here is what I have learned from that experience. > > > > Mib module official status becomes important on the agent > side first; > > once a mib hits PS it's a valid target for inclusion in > project plans > > (for those products that include the managed functionality). While > > some mib modules get implemented from an I-D, the RFC publication > > finalizes the design and an RFC# is marketable. Advancement > to DS or > > FS makes little difference - if the functionality is in the > box, the > > mib module should be done fairly soon after the functionality is > > available, and if there is an RFC-level standard, that's good. The > > tweaking that occurs between PS and DS and between DS and FS makes > > little difference to an equipment vendor (except as non-marketable > > maintenance work). > > > > MIB modules become important to vendor-neutral software developers > > when enough equipment vendors support the MIB module to make it > > worthwhile directly supporting it, and there is customer demand for > > consistent management of the functionality. Most vendor-neutral > > software vendors use table-driven or model-driven designs > that largely > > hide whether the implementation is the industry standard > MIB module or > > a proprietary MIB module with similar capabilites. The > status of a MIB > > module standard is largely irrelevant; the customer demand > exists or > > it doesn't. > > > > So, we are now faced with a decision to publish the SMIv2 version of > > RFC1493 **with no semantic changes** or to publish an updated MIB > > module that reflects the current underlying IEEE standard > better, by > > supporting 32-bit PathCost rather than only the 16-bit PathCost. > > > > How many people on this list actually care whether the > standard status > > is at PS or DS or FS, and why? Will advancing the standards > level have > > an **actual** impact on whether the implementation is done by your > > company? Would recycling the MIB module at PS have a > negative effect > > on your company and its revenue stream? Would the benefit > of having a > > MIB module that is more current with IEEE standards offset any > > negatives of recycling at PS? > > > > If you are not associated with a company, but rather a > university or > > an open-source product or whatever, will the status level > have a real > > impact on what you do? > > > > Ultimately the question to be answered is: Should we diminish the > > functionality in order to advance the document in the > standards track, > > or should we add the 32-bit functionality even if we have > to recycle > > at Proposed? > > > > Thanks, > > David Harrington > > dbharrington@comcast.net > > Bridge-mib co-chair > > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] > On Behalf > > > Of Juergen Schoenwaelder > > > Sent: Tuesday, November 02, 2004 3:23 PM > > > To: David B Harrington > > > Cc: ietfdbh@comcast.net; 'Les Bell'; bridge-mib@ietf.org > > > Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 > > > > > > On Tue, Nov 02, 2004 at 02:47:11PM -0500, David B > Harrington wrote: > > > > > > > Can we resolve this (and any other issues) on the mailing > > > list before > > > > IETF61, please? > > > > > > Will be hard, but we can try. > > > > > > > These mib modules are already three years behind the > > > charter schedule. > > > > > > Yes. But since the IETF meeting is next week, I would say > that this > > > week does not cause any significant delay. > > > > > > > We want to start the WG last call before IETF61, not wait > > > until IETF61 > > > > to start discussing possible solutions. > > > > > > Lets try to collect possible solutions: > > > > > > a) We remove the 32-bit path cost, move the BRIDGE-MIB to Standard > > and > > > start a new MIB module which defines the new object. > > > > > > a') We remove the 32-bit path cost, move the BRIDGE-MIB > to Standard > > > and > > > tell the IEEE or who cares that they have to address > this issue. > > > > > > b) We agree to change the range restriction by declaring that an > > error > > > or bug fix (even though it really is not, well yeah ...). We > > don't > > > introduce a new object, stepping of course formally on SMIv2 > > rules. > > > > > > c) We do what the document currently does (introducing a > new object) > > > > > and move the whole MIB module back to Proposed. > > > > > > d) We do what the document currently does and move > forward, looking > > > for > > > the IESG feedback. Note that RFC 2026 says that a > Draft standard > > > "is > > > normally considered to be a final specification, and > changes are > > > likely to be made only to solve specific problems > encountered." > > > Perhaps this is a specific problem encountered... > > > > > > e) We drop the whole document and just stick to RFC 1493. > > > > > > Any options I did forget? > > > > > > Any ideas how to select the winner? > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder International > > University Bremen > > > P.O. Box 750 561, > > > 28725 Bremen, Germany > > > > > > > > > > > _______________________________________________ > > Bridge-mib mailing list > > Bridge-mib@ietf.org > > https://www1.ietf.org/mailman/listinfo/bridge-mib > > > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Nov 4 12:48:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15638 for ; Thu, 4 Nov 2004 12:48:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPlxw-0002Nz-Ft for bridge-mib-archive@ietf.org; Thu, 04 Nov 2004 13:04:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPlcD-0007T1-Vv; Thu, 04 Nov 2004 12:41:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPlRR-0005WV-BR for bridge-mib@megatron.ietf.org; Thu, 04 Nov 2004 12:30:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14053 for ; Thu, 4 Nov 2004 12:30:30 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPlgz-0001r3-KD for bridge-mib@ietf.org; Thu, 04 Nov 2004 12:46:39 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iA4HMMbh016320 for ; Thu, 4 Nov 2004 12:22:22 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iA4HKnbh014853 for ; Thu, 4 Nov 2004 12:21:29 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Bridge-mib] Consensus Call Date: Thu, 4 Nov 2004 19:28:22 +0200 Message-ID: Thread-Topic: [Bridge-mib] Consensus Call Thread-Index: AcTBGdCFpISCcWJvQsifS9Kn3UEYBgBZV8EAAAJBINAAAoIWAAAAUoWw From: "Romascanu, Dan \(Dan\)" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Ooops, my apologies.=20 Regards, Dan > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net] > Sent: 04 November, 2004 7:19 PM > To: Romascanu, Dan (Dan); bridge-mib@ietf.org > Subject: RE: [Bridge-mib] Consensus Call >=20 >=20 > Just to be clear, that was Juergen's mail, not Bert's. >=20 > dbh >=20 >=20 _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Nov 4 13:03:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16637 for ; Thu, 4 Nov 2004 13:03:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPmCU-0002f5-PC for bridge-mib-archive@ietf.org; Thu, 04 Nov 2004 13:19:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPlhl-0000Iq-QY; Thu, 04 Nov 2004 12:47:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPlRr-0005n8-V3 for bridge-mib@megatron.ietf.org; Thu, 04 Nov 2004 12:31:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14125 for ; Thu, 4 Nov 2004 12:30:57 -0500 (EST) Message-Id: <200411041730.MAA14125@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPlhQ-0001qq-9M for bridge-mib@ietf.org; Thu, 04 Nov 2004 12:47:05 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc11) with SMTP id <2004110417302701300bqf3ke>; Thu, 4 Nov 2004 17:30:27 +0000 From: "David B Harrington" To: Date: Thu, 4 Nov 2004 12:30:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTCk/ccn+sw5cWoTIO7OCdqCKVjbA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: STDS-802-1-L@LISTSERV.IEEE.ORG Subject: [Bridge-mib] Last Call: draft-ietf-bridge-bridgemib-smiv2-07.txt X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Hi, This starts the WG last call for the update to RFC1493. The document is available at ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-bridge-br idgemib-smiv2-07.txt The WG last call will end November 23. This date has been chosen to ensure that 1) IETF61 attendees have time to perform reviews, and 2) attendees of the IEEE meeting the following week have time to perform reviews. Please post your comments to bridge-mib@ietf.org Two points: 1) there have been two different -07- revisions published; please ensure that you review the one dated October 25, 2004. 2) I just started a discussion of advancement versus adding PathCost32; the current -07- draft will require recycling at PS; any discussion about recycling at PS will be included in the WG last call comments. Thanks, David Harrington dbharrington@comcast.net Bridge-mib co-chair _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Nov 4 17:00:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11051 for ; Thu, 4 Nov 2004 17:00:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPpuI-0008Te-GA for bridge-mib-archive@ietf.org; Thu, 04 Nov 2004 17:16:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPpNW-00038s-8Y; Thu, 04 Nov 2004 16:42:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPpFH-0000Ps-99 for bridge-mib@megatron.ietf.org; Thu, 04 Nov 2004 16:34:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08408 for ; Thu, 4 Nov 2004 16:34:13 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPpUs-0007in-GH for bridge-mib@ietf.org; Thu, 04 Nov 2004 16:50:23 -0500 Received: from tom3 (1Cust43.tnt30.lnd3.gbr.da.uu.net [62.188.122.43]) by blaster.systems.pipex.net (Postfix) with SMTP id 8C424E0000DE; Thu, 4 Nov 2004 21:33:38 +0000 (GMT) Message-ID: <044401c4c2b5$cd82ff80$0301a8c0@tom3> From: "Tom Petch" To: , Subject: Re: [Bridge-mib] Consensus Call Date: Thu, 4 Nov 2004 21:30:59 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit David I think you pose the wrong question. For me, the issue is more about how long do we go on doing this for with what end in view? I prefer option a' where we arrive at FS because I think anything else is, at least technically, an unstable state within the IETF. I do not believe that most MIB users/implementors comprehend the difference between the various ,S that the IETF has defined. And while it is technically satisfying to get 32 bit path cost right, this is just the current of what could be a never ending list of changes coming up in the future and we already decided that the future of this work belongs with IEEE not IETF. Tom Petch -----Original Message----- From: David B Harrington To: bridge-mib@ietf.org Date: 04 November 2004 15:48 Subject: [Bridge-mib] Consensus Call >OK, Let me start a discussion here. This is important for a consensus >check, so please read and respond. > > >Ultimately the question to be answered is: Should we diminish the >functionality in order to advance the document in the standards track, >or should we add the 32-bit functionality even if we have to recycle >at Proposed? > >Thanks, >David Harrington >dbharrington@comcast.net >Bridge-mib co-chair > > >> -----Original Message----- >> From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] On >> Behalf Of Juergen Schoenwaelder >> Sent: Tuesday, November 02, 2004 3:23 PM >> To: David B Harrington >> Cc: ietfdbh@comcast.net; 'Les Bell'; bridge-mib@ietf.org >> Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 >> >> On Tue, Nov 02, 2004 at 02:47:11PM -0500, David B Harrington wrote: >> >> Lets try to collect possible solutions: >> >> a) We remove the 32-bit path cost, move the BRIDGE-MIB to Standard >and >> start a new MIB module which defines the new object. >> >> a') We remove the 32-bit path cost, move the BRIDGE-MIB to >> Standard and >> tell the IEEE or who cares that they have to address this issue. >> >> b) We agree to change the range restriction by declaring that an >error >> or bug fix (even though it really is not, well yeah ...). We >don't >> introduce a new object, stepping of course formally on SMIv2 >rules. >> >> c) We do what the document currently does (introducing a new object) > >> and move the whole MIB module back to Proposed. >> >> d) We do what the document currently does and move forward, >> looking for >> the IESG feedback. Note that RFC 2026 says that a Draft >> standard "is >> normally considered to be a final specification, and changes are >> likely to be made only to solve specific problems encountered." >> Perhaps this is a specific problem encountered... >> >> e) We drop the whole document and just stick to RFC 1493. >> >> Any ideas how to select the winner? Rough consensus? >> >> Juergen Schoenwaelder International University Bremen >> P.O. Box 750 561, >> 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Nov 4 17:50:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18031 for ; Thu, 4 Nov 2004 17:50:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPqgd-0001nW-DA for bridge-mib-archive@ietf.org; Thu, 04 Nov 2004 18:06:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPqDQ-0005J6-45; Thu, 04 Nov 2004 17:36:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPq39-0001Z8-U9 for bridge-mib@megatron.ietf.org; Thu, 04 Nov 2004 17:25:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14231 for ; Thu, 4 Nov 2004 17:25:45 -0500 (EST) Message-Id: <200411042225.RAA14231@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPqId-0000ov-MD for bridge-mib@ietf.org; Thu, 04 Nov 2004 17:41:55 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <2004110422250701400sdt9te>; Thu, 4 Nov 2004 22:25:07 +0000 From: "David B Harrington" To: "'Tom Petch'" , Subject: RE: [Bridge-mib] Consensus Call Date: Thu, 4 Nov 2004 17:25:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTCtfPlWi4GJdfvTEKNJPC3JEWYuQAAHbpA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <044401c4c2b5$cd82ff80$0301a8c0@tom3> X-Spam-Score: 0.1 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: 7bit X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: 7bit Hi Tom, My goal, to make it clear, is to get the documents finished. I don't want to have to re-edit the documents to remove the PathCost32 because that will take another four to six months to a year at the glacial rate of this working group. I would like to simply last call the three documents as they currently stand and be done. The documents will be published as RFCs, which are by definition stable **documents** within the IETF, even though -- technically -- they are in an unstable **state**. The only difference is that, with PathCost32 present, we would need to submit the documents at Proposed rather than FS, and "most MIB users/implementors [do not] comprehend the difference between the various ,S that the IETF has defined." I see no benefit to be gained from advancing three-year-old mib modules in the standards track and then having the IEEE immediately start to write new documents to replace them. The PAR for an 802.1Q-REV has already been granted, and it is well understood in both the IEEE and the IETF that the Bridge MIB modules are out-of-date relative to 802.1D-2004 and needs to be updated. It may not have been obvious, but I posed the question relative only to this editing cycle - the last planned editing cycle for this document in the IETF. There would be no more additions to the three documents currently in last call. Any further work would be done in the IEEE as part of their next update. I was not suggesting that we reopen the document for even more additions now, or ever. I think I did pose the correct question though. Given that the compliance statement for RFC1493 is still valid, so you only need to do an upodate if you want the PathCost32 in your implementation, if we publish the documents with the PathCost32 in them, and therefore have to start the updated document at Proposed, will that impact your company's implementation schedule? If we re-edit the documents and then advance them to FS and DS, will that change your company's implementation schedule and generate addition revenue for your company? Or does the advancement only impact its "technical" status within the IETF, and not **really** impact users and implementors of the MIB module? I think we are in agreement that the advancement has only a technical impact within the IETF, not a practical impact to the industry. dbh > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Thursday, November 04, 2004 4:31 PM > To: dbharrington@comcast.net; bridge-mib@ietf.org > Subject: Re: [Bridge-mib] Consensus Call > > David > > I think you pose the wrong question. For me, the issue is > more about how long do we go on doing this for with what end in view? > > I prefer option a' where we arrive at FS because I think > anything else is, at least technically, an unstable state > within the IETF. I do not believe that most MIB > users/implementors comprehend the difference between the > various ,S that the IETF has defined. > > And while it is technically satisfying to get 32 bit path > cost right, this is just the current of what could be a never > ending list of changes coming up in the future and we already > decided that the future of this work belongs with IEEE not IETF. > > Tom Petch > > -----Original Message----- > From: David B Harrington > To: bridge-mib@ietf.org > Date: 04 November 2004 15:48 > Subject: [Bridge-mib] Consensus Call > > > >OK, Let me start a discussion here. This is important for a > consensus > >check, so please read and respond. > > > > > > >Ultimately the question to be answered is: Should we diminish the > >functionality in order to advance the document in the > standards track, > >or should we add the 32-bit functionality even if we have to > recycle at > >Proposed? > > > >Thanks, > >David Harrington > >dbharrington@comcast.net > >Bridge-mib co-chair > > > > > >> -----Original Message----- > >> From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] > On Behalf > >> Of Juergen Schoenwaelder > >> Sent: Tuesday, November 02, 2004 3:23 PM > >> To: David B Harrington > >> Cc: ietfdbh@comcast.net; 'Les Bell'; bridge-mib@ietf.org > >> Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 > >> > >> On Tue, Nov 02, 2004 at 02:47:11PM -0500, David B Harrington wrote: > >> > >> Lets try to collect possible solutions: > >> > >> a) We remove the 32-bit path cost, move the BRIDGE-MIB to Standard > >and > >> start a new MIB module which defines the new object. > >> > >> a') We remove the 32-bit path cost, move the BRIDGE-MIB to > Standard > >> and > >> tell the IEEE or who cares that they have to address this issue. > >> > >> b) We agree to change the range restriction by declaring that an > >error > >> or bug fix (even though it really is not, well yeah ...). We > >don't > >> introduce a new object, stepping of course formally on SMIv2 > >rules. > >> > >> c) We do what the document currently does (introducing a > new object) > > > >> and move the whole MIB module back to Proposed. > >> > >> d) We do what the document currently does and move > forward, looking > >> for > >> the IESG feedback. Note that RFC 2026 says that a Draft > standard > >> "is > >> normally considered to be a final specification, and changes are > >> likely to be made only to solve specific problems encountered." > >> Perhaps this is a specific problem encountered... > >> > >> e) We drop the whole document and just stick to RFC 1493. > >> > >> Any ideas how to select the winner? > > Rough consensus? > > >> > >> Juergen Schoenwaelder International University Bremen > >> P.O. Box 750 561, > >> 28725 Bremen, Germany > > > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Fri Nov 5 03:01:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14155 for ; Fri, 5 Nov 2004 03:01:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPzHU-0004GG-94 for bridge-mib-archive@ietf.org; Fri, 05 Nov 2004 03:17:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPz0f-0001oy-Ud; Fri, 05 Nov 2004 02:59:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPyzJ-0001Za-Vy for bridge-mib@megatron.ietf.org; Fri, 05 Nov 2004 02:58:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13924 for ; Fri, 5 Nov 2004 02:58:20 -0500 (EST) Received: from columba.eur.3com.com ([161.71.171.238]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPzEm-0004DH-9F for bridge-mib@ietf.org; Fri, 05 Nov 2004 03:14:35 -0500 Received: from toucana.eur.3com.com (eurelay.eur.3com.com [140.204.220.50]) by columba.eur.3com.com with ESMTP id iA57xVuQ025574 for ; Fri, 5 Nov 2004 07:59:32 GMT Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id iA582EAH007536 for ; Fri, 5 Nov 2004 08:02:15 GMT Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256F43.002BC571 ; Fri, 5 Nov 2004 07:58:05 +0000 X-Lotus-FromDomain: 3COM From: "Les Bell" To: bridge-mib@ietf.org Message-ID: <80256F43.002BC4E6.00@notesmta.eur.3com.com> Date: Fri, 5 Nov 2004 07:57:27 +0000 Subject: RE: [Bridge-mib] Consensus Call Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b I agree with Dan. Les... "Romascanu, Dan \(Dan\)" @ietf.org on 04/11/2004 16:15:56 Sent by: bridge-mib-bounces@ietf.org To: , cc: Subject: RE: [Bridge-mib] Consensus Call Speaking as a contributor - I always favored the approach that we should rather update the standard and recycle at Proposed, than progress MIB modules on the standard track, while they are not exactly in synch with the IEEE standard. This is the line they we also took in the Ethernet MIB WG. My employer is a mostly enterprise space vendor. I am not official speaker for the company, but I could cautiously say that my impression is that our customers do not care too much about the IETF Standards Status. If a standard does its job and ensures interoperability between vendors its fine with them. Only a small category of customers would look at the standards status before entering it in an RFP. However, my impression is that these customers will first include the IEEE 802.1 standard, and only second the MIB standard. What is the good of having a Full Standard with a MIB that is not in synch with the IEEE specification? In conclusion I personally favor option c in Bert's mail. Regards, Dan > -----Original Message----- > From: bridge-mib-bounces@ietf.org > [mailto:bridge-mib-bounces@ietf.org]On Behalf Of David B Harrington > Sent: 04 November, 2004 5:33 PM > To: bridge-mib@ietf.org > Subject: [Bridge-mib] Consensus Call > > > OK, Let me start a discussion here. This is important for a consensus > check, so please read and respond. > > My experience has been working for an equipment vendor. I have worked > in both the embedded system space and the pure vendor-neutral software > solution space. Here is what I have learned from that experience. > > Mib module official status becomes important on the agent side first; > once a mib hits PS it's a valid target for inclusion in project plans > (for those products that include the managed functionality). While > some mib modules get implemented from an I-D, the RFC publication > finalizes the design and an RFC# is marketable. Advancement to DS or > FS makes little difference - if the functionality is in the box, the > mib module should be done fairly soon after the functionality is > available, and if there is an RFC-level standard, that's good. The > tweaking that occurs between PS and DS and between DS and FS makes > little difference to an equipment vendor (except as non-marketable > maintenance work). > > MIB modules become important to vendor-neutral software developers > when enough equipment vendors support the MIB module to make it > worthwhile directly supporting it, and there is customer demand for > consistent management of the functionality. Most vendor-neutral > software vendors use table-driven or model-driven designs that largely > hide whether the implementation is the industry standard MIB module or > a proprietary MIB module with similar capabilites. The status of a MIB > module standard is largely irrelevant; the customer demand exists or > it doesn't. > > So, we are now faced with a decision to publish the SMIv2 version of > RFC1493 **with no semantic changes** or to publish an updated MIB > module that reflects the current underlying IEEE standard better, by > supporting 32-bit PathCost rather than only the 16-bit PathCost. > > How many people on this list actually care whether the standard status > is at PS or DS or FS, and why? Will advancing the standards level have > an **actual** impact on whether the implementation is done by your > company? Would recycling the MIB module at PS have a negative effect > on your company and its revenue stream? Would the benefit of having a > MIB module that is more current with IEEE standards offset any > negatives of recycling at PS? > > If you are not associated with a company, but rather a university or > an open-source product or whatever, will the status level have a real > impact on what you do? > > Ultimately the question to be answered is: Should we diminish the > functionality in order to advance the document in the standards track, > or should we add the 32-bit functionality even if we have to recycle > at Proposed? > > Thanks, > David Harrington > dbharrington@comcast.net > Bridge-mib co-chair > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] On > > Behalf Of Juergen Schoenwaelder > > Sent: Tuesday, November 02, 2004 3:23 PM > > To: David B Harrington > > Cc: ietfdbh@comcast.net; 'Les Bell'; bridge-mib@ietf.org > > Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 > > > > On Tue, Nov 02, 2004 at 02:47:11PM -0500, David B Harrington wrote: > > > > > Can we resolve this (and any other issues) on the mailing > > list before > > > IETF61, please? > > > > Will be hard, but we can try. > > > > > These mib modules are already three years behind the > > charter schedule. > > > > Yes. But since the IETF meeting is next week, I would say > > that this week does not cause any significant delay. > > > > > We want to start the WG last call before IETF61, not wait > > until IETF61 > > > to start discussing possible solutions. > > > > Lets try to collect possible solutions: > > > > a) We remove the 32-bit path cost, move the BRIDGE-MIB to Standard > and > > start a new MIB module which defines the new object. > > > > a') We remove the 32-bit path cost, move the BRIDGE-MIB to > > Standard and > > tell the IEEE or who cares that they have to address this issue. > > > > b) We agree to change the range restriction by declaring that an > error > > or bug fix (even though it really is not, well yeah ...). We > don't > > introduce a new object, stepping of course formally on SMIv2 > rules. > > > > c) We do what the document currently does (introducing a new object) > > > and move the whole MIB module back to Proposed. > > > > d) We do what the document currently does and move forward, > > looking for > > the IESG feedback. Note that RFC 2026 says that a Draft > > standard "is > > normally considered to be a final specification, and changes are > > likely to be made only to solve specific problems encountered." > > Perhaps this is a specific problem encountered... > > > > e) We drop the whole document and just stick to RFC 1493. > > > > Any options I did forget? > > > > Any ideas how to select the winner? > > > > /js > > > > -- > > Juergen Schoenwaelder International > University Bremen > > P.O. Box 750 561, > > 28725 Bremen, Germany > > > > > > _______________________________________________ > Bridge-mib mailing list > Bridge-mib@ietf.org > https://www1.ietf.org/mailman/listinfo/bridge-mib > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Fri Nov 5 15:52:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16361 for ; Fri, 5 Nov 2004 15:52:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQBKI-0003ww-70 for bridge-mib-archive@ietf.org; Fri, 05 Nov 2004 16:08:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQAtZ-0005LE-45; Fri, 05 Nov 2004 15:41:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQArr-0004SV-IO for bridge-mib@megatron.ietf.org; Fri, 05 Nov 2004 15:39:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15389 for ; Fri, 5 Nov 2004 15:39:29 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQB7e-0003Uw-Ub for bridge-mib@ietf.org; Fri, 05 Nov 2004 15:55:51 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id A42A53107; Fri, 5 Nov 2004 21:38:54 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 30220-04; Fri, 5 Nov 2004 21:38:53 +0100 (CET) Received: from james (I9f74.i.pppool.de [85.73.159.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 850743105; Fri, 5 Nov 2004 21:38:53 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CQArD-0000mP-Pw; Fri, 05 Nov 2004 21:38:51 +0100 Date: Fri, 5 Nov 2004 21:38:51 +0100 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Bridge-mib] Consensus Call Message-ID: <20041105203851.GA2995@james> Mail-Followup-To: David B Harrington , bridge-mib@ietf.org References: <20041102202312.GA2450@james> <200411041533.KAA01397@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411041533.KAA01397@ietf.org> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 On Thu, Nov 04, 2004 at 10:33:06AM -0500, David B Harrington wrote: > If you are not associated with a company, but rather a university or > an open-source product or whatever, will the status level have a real > impact on what you do? Most open source projects are driven by individual interests and in the bridge context, it is usually the MIBs that the vendors have implemented that count. (While there are open source briding implementations around, they usually do not come with an SNMP management interface since they run on general purpose boxes.) So standards status is largely irrelevant as far as I am concerned. Migration between versions is however an issues since we are like everybody else concerned about interoperability and we typically dislike to have complex code just because standards were never finished or made the coexistance rather complicated. In summary, I think open source coders look at these issues like probably most other management application writers, except that we have more freedom to ignore some proprietary solutions by just telling people why we do not support certain things. (You can't do that in a commercial setting I guess.) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Fri Nov 5 15:54:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16593 for ; Fri, 5 Nov 2004 15:54:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQBMB-00041E-Q5 for bridge-mib-archive@ietf.org; Fri, 05 Nov 2004 16:10:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQB5J-0003Qn-RB; Fri, 05 Nov 2004 15:53:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQAwc-00072w-OT for bridge-mib@megatron.ietf.org; Fri, 05 Nov 2004 15:44:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15707 for ; Fri, 5 Nov 2004 15:44:24 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQBCQ-0003b4-Mt for bridge-mib@ietf.org; Fri, 05 Nov 2004 16:00:47 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id C136230E3; Fri, 5 Nov 2004 21:43:55 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 30507-01; Fri, 5 Nov 2004 21:43:54 +0100 (CET) Received: from james (I9f74.i.pppool.de [85.73.159.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 9EA803105; Fri, 5 Nov 2004 21:43:54 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CQAw4-0000mW-Oq; Fri, 05 Nov 2004 21:43:52 +0100 Date: Fri, 5 Nov 2004 21:43:52 +0100 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Bridge-mib] Consensus Call Message-ID: <20041105204352.GB2995@james> Mail-Followup-To: David B Harrington , 'Tom Petch' , bridge-mib@ietf.org References: <044401c4c2b5$cd82ff80$0301a8c0@tom3> <200411042225.RAA14231@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411042225.RAA14231@ietf.org> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "'Tom Petch'" , bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Thu, Nov 04, 2004 at 05:25:02PM -0500, David B Harrington wrote: > My goal, to make it clear, is to get the documents finished. I don't > want to have to re-edit the documents to remove the PathCost32 because > that will take another four to six months to a year at the glacial > rate of this working group. I would like to simply last call the three > documents as they currently stand and be done. Any editing regarding the PathCost32 issue should be rather easy once we have formed an opinion. I now hold the editing token and I am fine to update the document on Friday or Saturday after the IETF if there is a final decision reached next week. From my point of view, all possible solutions (removing or keeping or changing) have more or less the same editing costs. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Fri Nov 5 16:19:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19160 for ; Fri, 5 Nov 2004 16:19:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQBUk-0004cj-1U for bridge-mib-archive@ietf.org; Fri, 05 Nov 2004 16:19:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQBQ1-0007FA-1z; Fri, 05 Nov 2004 16:14:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQBNp-0005oC-3M for bridge-mib@megatron.ietf.org; Fri, 05 Nov 2004 16:12:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18583 for ; Fri, 5 Nov 2004 16:12:30 -0500 (EST) Message-Id: <200411052112.QAA18583@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQBNo-0004Rg-G7 for bridge-mib@ietf.org; Fri, 05 Nov 2004 16:12:32 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc11) with SMTP id <2004110521120001300bpul8e>; Fri, 5 Nov 2004 21:12:01 +0000 From: "David B Harrington" To: Subject: RE: [Bridge-mib] Consensus Call Date: Fri, 5 Nov 2004 16:11:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTDeCscvnk8Je79RgSXIlmm7rEVxwAAz6yg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <20041105204352.GB2995@james> X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: "'Tom Petch'" , bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Note that the RSTP-MIB has dependencies on PathCost32. This makes editing just a touch more difficultt, but not seriously so. dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] On > Behalf Of Juergen Schoenwaelder > Sent: Friday, November 05, 2004 3:44 PM > To: David B Harrington > Cc: 'Tom Petch'; bridge-mib@ietf.org > Subject: Re: [Bridge-mib] Consensus Call > > On Thu, Nov 04, 2004 at 05:25:02PM -0500, David B Harrington wrote: > > > My goal, to make it clear, is to get the documents > finished. I don't > > want to have to re-edit the documents to remove the > PathCost32 because > > that will take another four to six months to a year at the glacial > > rate of this working group. I would like to simply last > call the three > > documents as they currently stand and be done. > > Any editing regarding the PathCost32 issue should be rather > easy once we have formed an opinion. I now hold the editing > token and I am fine to update the document on Friday or > Saturday after the IETF if there is a final decision reached > next week. From my point of view, all possible solutions > (removing or keeping or changing) have more or less the same > editing costs. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Wed Nov 10 08:08:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04358 for ; Wed, 10 Nov 2004 08:08:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRsE0-0001Rc-TE for bridge-mib-archive@ietf.org; Wed, 10 Nov 2004 08:09:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRsAA-000540-F9; Wed, 10 Nov 2004 08:05:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRs30-00048G-HT for bridge-mib@megatron.ietf.org; Wed, 10 Nov 2004 07:58:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02855 for ; Wed, 10 Nov 2004 07:58:01 -0500 (EST) Received: from apollo.nbase.co.il ([194.90.137.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRs3w-0000wA-7E for bridge-mib@ietf.org; Wed, 10 Nov 2004 07:59:02 -0500 Received: from Alexr ([194.90.136.135]) by apollo.nbase.co.il (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-44418U200L2S100) with SMTP id AAA2815; Wed, 10 Nov 2004 14:56:56 +0200 From: arozin@mrv.com (Alex Ruzin) To: "'Congdon, Paul T \(ProCurve\)'" , Date: Wed, 10 Nov 2004 14:57:33 +0200 Message-ID: <00e401c4c724$d92aafe0$87885ac2@Alexr> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <85ECA15B7BB46944BFD4C73AEA554824E8A5A3@cacexc07.americas.cpqcorp.net> X-Spam-Score: 1.1 (+) X-Scan-Signature: c2427de1554ed8e3804597b4bf60f110 Cc: bridge-mib@ietf.org Subject: [Bridge-mib] RE: [802.1] Alex Ruzin MSTP MIB Proposal - explanations X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arozin@mrv.com List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0827313004==" Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 2a25a3f15cd7c4f2ea7dd14d5f6b4bd1 This is a multi-part message in MIME format. --===============0827313004== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E5_01C4C735.9CB37FE0" This is a multi-part message in MIME format. ------=_NextPart_000_00E5_01C4C735.9CB37FE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit (Sorry for HTML, but I want you to see a nice diagram below). I dare to provide a number of explanations for ruzin-mstp-mib-00.txt from http://www.ieee802.org/1/files/public/docs2004/ruzin-mstp-mib-00.txt This MIB contains 6 parts: mstpTraps, mstpGen, mstpPortTable, mstpMapTable, mstpXstTable and mstpXstPortTable: 1. mstpTraps help to get information about changes in MSTP active topology asynchronous notifications. Conditions and parameters seem to be clear, while may be discussed. 2. mstpGen. This group is dedicated to manage Bridge Protocol Entity, described in 12.8.1.1 and 12.8.1.3. In a certain sense this group reflects CIST, but without objects, that may be managed in mstpXstTable, see below. 3. mstpPortTable allows to manage physical ports, as it is described in 1.8.2.1., 1.80.2.3., 1.8.2.5 and 12.8.2.7. In a certain sense this group reflects CIST ports, but without objects, that may be managed in mstpXstPortTable, see below. 4. mstpMapTable serves for MSTI List management. It allows to build/delete instances and to map FIDs/VIDs (12.12). Actually, this table reflects MST Configuration Table in format, that is defined in 13.7 item 4). It must be admitted that I "grabbed" the idea of ranges in this table from malhotra-mstpmib-01.txt 5. mstpXstTable reflects instances - both CIST and MSTIs (12.8.1.2 and 12.8.1.4). It contains objects, common for these both types of instances, for example, mstpXstBridgePriority. 6. mstpXstPortTable is dedicated to manage ports inside instances - both CIST and MSTIs (12.8.2.2., 12.8.2.4 and 12.8.2.6). It contains objects, describing port and common for these both types of instances, for example, mstpXstPortState or mstpXstPortPriority. Note, that this table has mstpXstPortInternalRootCost, while mstpPortAdminExternalPathCost belongs to mstpPortTable. Important, that the index mstpXstId in mstpXstTable and mstpXstPortXstId in mstpXstPortTable have type MstiOrCistInstanceIndex : "value of zero" corresponds to CIST. Now, I'd like to mention in passing objects, that are not defined in .1s Let us begin from less questionable. 1. mstpPortAutoEdge. It came from new .1d 917.13.3) and I don't expect many objections here :) 2. mstpXstPortRole. The exploitation of MSTP shows, that managers of complicated networks want to know reasons of ports states assignations. So, they concerned with ports roles. In my opinion, this object is important not only debug purposes. 3. The similar destination have so called BpduCounters. Let's say, when a port stops to be RootPort, a manager may see, that receive BpduCounters on this port do not rise. He may trace bridges and select a point of failure. And what is more, I'd define an object mstpXstPortRxMstBpduCounter to count MSTI Configuration Messages. Sure, all these counters are optional: if an agent cannot provide for them it must return zero. 4. mstpGenCapable. A manager has to know, what version of STP the bridge supplies. If it supplies a number of versions (see mstpGenForceVersion), the eldest one must be returned. 5. mstpGenForceVersion. If the bridge can supply a number of versions of STP (let's say, it has a number of corresponding engines) a manager may want to enable one of them (and of course to disable all others) he may use with this object. This object also show which engine is currently enabled. 6. The value forceNonStp(0) of object mstpGenForceVersion. I remember a few of dispute both in IETF and in IEEE : what is STP disabled into a bridge. I know and share a position of IEEE, that there may not be bridge with STP disabled, nevertheless... The term "Spanning Tree Protocol Emulation" here means, that a bridge is transparent for received BPDUs (does flooding: transmits from all ports, without tags and without VLAN participation) and processes Topology Change bit: does appropriate FDB flushing. 7. mstpPortAdminNonStp. Certain port may be configured as a port, that does not participate in any STP operations: a) it discards all BDPUs, b) does not send BPDUs and c) is always in forwarding state. This option may help to termination point of STP domain. 8. mstpXstMasterPort. Servers the same purposes as mstpXstPortRole and BpduCounters. On the other hand, is not less helpful than mstpXstRootPort; furthermore it may help to indicate fallacious instance mapping (when a manager expects bridges in the same region, this object must be zero). 9. Both mstpXstRootPort and mstpXstMasterPort have type PortIndexOrZero. Brief structure of the MIB (result of "snmptranslate -Tp"): +--mstp(XXX) | +--mstpTraps(0) | | | +--dos1sNewRootBridge(1) | +--dos1sNewRootPort(2) | +--dos1sTopologyChange(3) | +--mstpGen(10) | | | +-- -RW- INTEGER mstpGenBridgeMaxAge(2) | | Textual Convention: Timeout | | Range: 600..4000 | +-- -RW- INTEGER mstpGenBridgeHelloTime(3) | | Textual Convention: Timeout | | Range: 100..1000 | +-- -RW- INTEGER mstpGenBridgeForwardDelay(4) | | Textual Convention: Timeout | | Range: 400..3000 | +-- -R-- INTEGER mstpGenMaxAge(8) | | Textual Convention: Timeout | | Range: 600..4000 | +-- -R-- INTEGER mstpGenHelloTime(9) | | Textual Convention: Timeout | | Range: 100..1000 | +-- -R-- INTEGER mstpGenForwardDelay(10) | | Textual Convention: Timeout | | Range: 400..3000 | +-- -RW- Integer32 mstpGenMaxHops(14) | | Range: 4..30 | +-- -RW- INTEGER mstpGenHoldTime(15) | | Textual Convention: Timeout | | Range: 100..1000 | +-- -RW- INTEGER mstpGenMigrateTime(16) | | Textual Convention: Timeout | | Range: 100..1000 | +-- -RW- EnumVal mstpGenPathCostDefault(18) | | Values: pathCostDefault8021d1998(1), pathCostDefault8021t2001(2) | +-- -R-- EnumVal mstpGenCapable(19) | | Values: nonStp(0), dot1d1998(1), dot1w(2), dot1d2004(3), | | dot1s(4), dot1q(5), unknown(6) | +-- -RW- EnumVal mstpGenForceVersion(20) | | Values: forceNonStp(0), forceLegacyDot1d(1), | | forceDot1w(2), autoDot1s(3), unknown(4) | +-- -RW- String mstpGenCfgName(21) | | Textual Convention: DisplayString | | Size: 32 | +-- -RW- Integer32 mstpGenRevLevel(22) | +-- -R-- String mstpGenReginalRoot(26) | | Textual Convention: BridgeId | | Size: 8 | +-- -R-- Integer32 mstpGenExternalRootCost(27) | +--mstpPortTable(11) | | | +--mstpPortEntry(1) | | Index: mstpPortIndex | | | +-- -R-- Integer32 mstpPortIndex(1) | | Textual Convention: PortIndex | | Range: 1..2147483647 | +-- -RW- EnumVal mstpPortAdminMACEnable(2) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -R-- EnumVal mstpPortOperMACEnable(3) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -R-- TimeTicks mstpPortUpTime(4) | +-- -RW- Integer32 mstpPortAdminExternalPathCost(5) | | Range: 0..200000000 | +-- -R-- Integer32 mstpPortOperExternalPathCost(6) | +-- -RW- EnumVal mstpPortAdminEdge(7) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -R-- EnumVal mstpPortOperEdge(8) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -RW- EnumVal mstpPortAutoEdge(9) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -RW- EnumVal mstpPortAdminPointToPoint(10) | | Values: forceTrue(0), forceFalse(1), auto(2) | +-- -R-- EnumVal mstpPortOperPointToPoint(11) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -RW- INTEGER mstpPortHelloTime(12) | | Textual Convention: Timeout | | Range: 100..1000 | +-- -RW- EnumVal mstpPortAdminNonStp(13) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -RW- EnumVal mstpPortProtocolMigration(14) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -R-- Counter mstpPortRxTcnBpduCounter(15) | | Textual Convention: BpduCounter | +-- -R-- Counter mstpPortRxCfgBpduCounter(16) | +-- -R-- Counter mstpPortRxRstBpduCounter(17) | +-- -R-- Counter mstpPortRxMstBpduCounter(18) | +-- -R-- Counter mstpPortTxTcnBpduCounter(19) | +-- -R-- Counter mstpPortTxCfgBpduCounter(20) | +-- -R-- Counter mstpPortTxRstBpduCounter(21) | +-- -R-- Counter mstpPortTxMstBpduCounter(22) | +--mstpMapTable(12) | | | +--mstpMapEntry(1) | | Index: mstpMapMSTiID, mstpMapVlanRangeIndex | | | +-- ---- Integer32 mstpMapMSTiID(1) | | Textual Convention: MstiInstanceIndex | | Range: 1..64 | +-- ---- Integer32 mstpMapVlanRangeIndex(2) | | Range: 1..4094 | | | +--mstpMapVlanMin(3) | | | +--mstpMapVlanMax(4) | | | +-- CR-- EnumVal mstpMapRowStatus(9) | Textual Convention: RowStatus | Values: active(1), notInService(2), notReady(3), | createAndGo(4), createAndWait(5), destroy(6) | +--mstpXstTable(13) | | | +--mstpXstEntry(1) | | Index: mstpXstId | | | +-- ---- Integer32 mstpXstId(1) | | Textual Convention: MstiOrCistInstanceIndex | | Range: 0..64 | +-- -RW- Integer32 mstpXstBridgePriority(2) | | Range: 0..61440 | +-- -R-- String mstpXstBridgeId(3) | | Textual Convention: BridgeId | | Size: 8 | +-- -R-- String mstpXstDesignatedRoot(4) | | Textual Convention: BridgeId | | Size: 8 | +-- -R-- String mstpXstDesignatedBridge(5) | | Textual Convention: BridgeId | | Size: 8 | +-- -R-- Integer32 mstpXstInternalRootCost(6) | +-- -R-- Integer32 mstpXstRootPort(7) | | Textual Convention: PortIndexOrZero | | Range: 0..2147483647 | +-- -R-- Integer32 mstpXstMasterPort(8) | | Textual Convention: PortIndexOrZero | | Range: 0..2147483647 | +-- -R-- TimeTicks mstpXstTimeSinceTopologyChange(11) | +-- -R-- Counter mstpXstTopologyChangesCount(12) | +-- -R-- EnumVal mstpXstTopologyChangeFlag(13) | Textual Convention: TruthValue | Values: true(1), false(2) | +--mstpXstPortTable(14) | +--mstpXstPortEntry(1) | Index: mstpXstPortXstId, mstpXstPortIndex | +-- ---- Integer32 mstpXstPortXstId(1) | Textual Convention: MstiOrCistInstanceIndex | Range: 0..64 +-- -R-- Integer32 mstpXstPortIndex(2) | Textual Convention: PortIndex | Range: 1..2147483647 +-- -R-- EnumVal mstpXstPortState(3) | Values: disabled(1), discarding(1), learning(2), forwarding(3), unknown(4) +-- -R-- EnumVal mstpXstPortRole(4) | Values: disabled(1), alternate(2), backup(3), root(4), | designated(5), master(6), nonStp(7), unknown(8) +-- -R-- String mstpXstPortDesignatedRoot(6) | Textual Convention: BridgeId | Size: 8 +-- -R-- Integer32 mstpXstPortExternalRootCost(7) +-- -R-- String mstpXstPortRegionalBridge(8) | Textual Convention: BridgeId | Size: 8 +-- -R-- Integer32 mstpXstPortInternalRootCost(9) +-- -R-- String mstpXstPortDesignatedBridge(10) | Textual Convention: BridgeId | Size: 8 +-- -R-- String mstpXstPortDesignatedPort(14) | Textual Convention: PortId | Size: 2 +-- -RW- Integer32 mstpXstPortPriority(15) | Range: 0..255 +-- -RW- Integer32 mstpXstPortAdminInternalPathCost(16) | Range: 0..200000000 +-- -R-- Integer32 mstpXstPortOperInternalPathCost(17) On Wednesday, November 03, 2004 4:15 PM Congdon, Paul T (ProCurve) wrote: > I've uploaded Alex Ruzin's MSTP MIB. Note that this is slightly > different than the MIB that Alex cut-and-pasted to a previous email. > The document may be retrieved at: > > http://www.ieee802.org/1/files/public/docs2004/ruzin-mstp-mib-00.txt ------=_NextPart_000_00E5_01C4C735.9CB37FE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(Sorry for HTML, but I want you to see = a nice=20 diagram below).

I = dare to provide=20 a number of explanations for ruzin-mstp-mib-00.txt from http://www.ieee802.org/1/files/public/docs2004/ruzin-mstp-mib-00.txt=

This MIB contains 6 parts: mstpTraps, = mstpGen,=20 mstpPortTable,
mstpMapTable, mstpXstTable and mstpXstPortTable:


1. mstpTraps help to get information about changes in MSTP=20 active
    topology asynchronous notifications. = Conditions and=20 parameters seem to be
    clear, while may be = discussed.
2.=20 mstpGen. This group is dedicated to manage Bridge Protocol=20 Entity,
    described in 12.8.1.1 and 12.8.1.3. In a = certain=20 sense this group reflects
    CIST, but without = objects, that=20 may be managed in mstpXstTable, see below.
3. mstpPortTable allows to = manage=20 physical ports, as it is described in
    1.8.2.1., = 1.80.2.3.,=20 1.8.2.5 and 12.8.2.7. In a certain sense this group=20 reflects
    CIST ports, but without objects, that may = be=20 managed in mstpXstPortTable,
    see below.
4. = mstpMapTable=20 serves for MSTI List management. It allows to = build/delete
   =20 instances and to map FIDs/VIDs (12.12). Actually, this table reflects=20 MST
    Configuration Table in format, that is defined = in 13.7=20 item 4).
    It must be admitted that I "grabbed" the = idea of=20 ranges in this table
    from = malhotra-mstpmib-01.txt
5.=20 mstpXstTable reflects instances - both CIST and MSTIs (12.8.1.2 and=20 12.8.1.4).
    It contains objects, common for these = both=20 types of instances, for example,
   =20 mstpXstBridgePriority.
6. mstpXstPortTable is dedicated to manage = ports=20 inside instances - both CIST
    and MSTIs (12.8.2.2., = 12.8.2.4 and 12.8.2.6). It contains objects, = describing
   =20 port and common for these both types of instances, for=20 example,
    mstpXstPortState or mstpXstPortPriority. = Note,=20 that this table has
    mstpXstPortInternalRootCost, = while=20 mstpPortAdminExternalPathCost belongs
    to=20 mstpPortTable.

Important, that the index mstpXstId in = mstpXstTable and=20 mstpXstPortXstId in
mstpXstPortTable have type = MstiOrCistInstanceIndex :=20 "value of zero"
corresponds to CIST.

Now, I'd like to mention = in=20 passing objects, that are not defined in .1s
Let us begin from less=20 questionable.
1. mstpPortAutoEdge. It came from new .1d 917.13.3) and = I don't=20 expect
    many objections here :)
2. = mstpXstPortRole. The=20 exploitation of MSTP shows, that managers
    of = complicated=20 networks want to know reasons of ports states
   =20 assignations. So, they concerned with ports roles. In my opinion,=20 this
    object is important not only debug = purposes.
3.=20 The similar destination have so called BpduCounters. Let's say,=20 when
    a port stops to be RootPort, a manager may = see, that=20 receive BpduCounters
    on this port do not rise. He = may=20 trace bridges and select a point of
    failure. And = what is=20 more, I'd define an object = mstpXstPortRxMstBpduCounter
    to=20 count MSTI Configuration Messages. Sure, all these counters are=20 optional:
    if an agent cannot provide for them it = must=20 return zero.
4. mstpGenCapable. A manager has to know, what version = of STP=20 the bridge
    supplies. If it supplies a number of = versions=20 (see mstpGenForceVersion),
    the eldest one must be=20 returned.
5. mstpGenForceVersion. If the bridge can supply a number = of=20 versions of STP
    (let's say, it has a number of=20 corresponding engines) a manager may want
    to = enable one of=20 them (and of course to disable all others) he may use = with
   =20 this object. This object also show which engine is currently = enabled.
6. The=20 value forceNonStp(0) of object mstpGenForceVersion. I remember=20 a
    few of dispute both in IETF and in IEEE : what = is STP=20 disabled into a bridge.
    I know and share a = position of=20 IEEE, that there may not be bridge with STP
    = disabled,=20 nevertheless...
    The term "Spanning Tree Protocol=20 Emulation" here means, that a bridge is
    = transparent for=20 received BPDUs (does flooding: transmits from all ports,=20 without
    tags and without VLAN participation) and = processes=20 Topology Change bit:
    does appropriate FDB = flushing.
7.=20 mstpPortAdminNonStp. Certain port may be configured as a port, that does = not
    participate in any STP operations: a) it = discards all=20 BDPUs, b) does not send
    BPDUs and c) is always in=20 forwarding state. This option may help to = termination
   =20 point of STP domain.
8. mstpXstMasterPort. Servers the same purposes = as=20 mstpXstPortRole and
    BpduCounters. On the other = hand, is=20 not less helpful than mstpXstRootPort;
    furthermore = it may=20 help to indicate fallacious instance mapping (when = a
   =20 manager expects bridges in the same region, this object must be = zero).
9.=20 Both mstpXstRootPort and mstpXstMasterPort have type=20 PortIndexOrZero.


Brief structure of the MIB (result of "snmptranslate = -Tp"):
+--mstp(XXX)
  =20 |
   +--mstpTraps(0)
   |  = |
  =20 |  +--dos1sNewRootBridge(1)
   | =20 +--dos1sNewRootPort(2)
   | =20 +--dos1sTopologyChange(3)
   |
  =20 +--mstpGen(10)
   |  |
   |  +-- = -RW-=20 INTEGER   mstpGenBridgeMaxAge(2)
   | =20 |        Textual Convention:=20 Timeout
   |  = |       =20 Range: 600..4000
   |  +-- -RW- INTEGER  =20 mstpGenBridgeHelloTime(3)
   | =20 |        Textual Convention:=20 Timeout
   |  = |       =20 Range: 100..1000
   |  +-- -RW- INTEGER  =20 mstpGenBridgeForwardDelay(4)
   | =20 |        Textual Convention:=20 Timeout
   |  = |       =20 Range: 400..3000
   |  +-- -R-- INTEGER  =20 mstpGenMaxAge(8)
   | =20 |        Textual Convention:=20 Timeout
   |  = |       =20 Range: 600..4000
   |  +-- -R-- INTEGER  =20 mstpGenHelloTime(9)
   | =20 |        Textual Convention:=20 Timeout
   |  = |       =20 Range: 100..1000
   |  +-- -R-- INTEGER  =20 mstpGenForwardDelay(10)
   | =20 |        Textual Convention:=20 Timeout
   |  = |       =20 Range: 400..3000
   |  +-- -RW- Integer32=20 mstpGenMaxHops(14)
   | =20 |        Range: 4..30
   = | =20 +-- -RW- INTEGER   mstpGenHoldTime(15)
   |  = |        Textual Convention:=20 Timeout
   |  = |       =20 Range: 100..1000
   |  +-- -RW- INTEGER  =20 mstpGenMigrateTime(16)
   | =20 |        Textual Convention:=20 Timeout
   |  = |       =20 Range: 100..1000
   |  +-- -RW- EnumVal  =20 mstpGenPathCostDefault(18)
   | =20 |        Values: = pathCostDefault8021d1998(1),=20 pathCostDefault8021t2001(2)
   |  +-- -R-- = EnumVal  =20 mstpGenCapable(19)
   | =20 |        Values: nonStp(0), = dot1d1998(1),=20 dot1w(2), dot1d2004(3),
   | =20 |            =    =20 dot1s(4), dot1q(5), unknown(6)
   |  +-- -RW-=20 EnumVal   mstpGenForceVersion(20)
   | =20 |        Values: forceNonStp(0),=20 forceLegacyDot1d(1),
   | =20 |            =    =20 forceDot1w(2), autoDot1s(3), unknown(4)
   |  +-- -RW- = String    mstpGenCfgName(21)
   | =20 |        Textual Convention:=20 DisplayString
   | =20 |        Size: 32
   = |  +--=20 -RW- Integer32 mstpGenRevLevel(22)
   |  +-- -R--=20 String    mstpGenReginalRoot(26)
   | =20 |        Textual Convention:=20 BridgeId
   |  = |       =20 Size: 8
   |  +-- -R-- Integer32=20 mstpGenExternalRootCost(27)
   |
  =20 +--mstpPortTable(11)
   |  |
   | =20 +--mstpPortEntry(1)
   |     |  = Index:=20 mstpPortIndex
   |     = |
  =20 |     +-- -R-- Integer32 = mstpPortIndex(1)
  =20 |     |        = Textual=20 Convention: PortIndex
   |    =20 |        Range: = 1..2147483647
  =20 |     +-- -RW- EnumVal  =20 mstpPortAdminMACEnable(2)
   |    =20 |        Textual Convention:=20 TruthValue
   |    =20 |        Values: true(1),=20 false(2)
   |     +-- -R-- = EnumVal  =20 mstpPortOperMACEnable(3)
   |    =20 |        Textual Convention:=20 TruthValue
   |    =20 |        Values: true(1),=20 false(2)
   |     +-- -R-- TimeTicks=20 mstpPortUpTime(4)
   |     +-- -RW- = Integer32=20 mstpPortAdminExternalPathCost(5)
   = |    =20 |        Range: = 0..200000000
  =20 |     +-- -R-- Integer32=20 mstpPortOperExternalPathCost(6)
   = |     +--=20 -RW- EnumVal   mstpPortAdminEdge(7)
  =20 |     |        = Textual=20 Convention: TruthValue
   |    =20 |        Values: true(1),=20 false(2)
   |     +-- -R-- = EnumVal  =20 mstpPortOperEdge(8)
   |    =20 |        Textual Convention:=20 TruthValue
   |    =20 |        Values: true(1),=20 false(2)
   |     +-- -RW- = EnumVal  =20 mstpPortAutoEdge(9)
   |    =20 |        Textual Convention:=20 TruthValue
   |    =20 |        Values: true(1),=20 false(2)
   |     +-- -RW- = EnumVal  =20 mstpPortAdminPointToPoint(10)
   |    =20 |        Values: forceTrue(0), = forceFalse(1),=20 auto(2)
   |     +-- -R-- = EnumVal  =20 mstpPortOperPointToPoint(11)
   |    =20 |        Textual Convention:=20 TruthValue
   |    =20 |        Values: true(1),=20 false(2)
   |     +-- -RW- = INTEGER  =20 mstpPortHelloTime(12)
   |    =20 |        Textual Convention:=20 Timeout
   |    =20 |        Range: = 100..1000
  =20 |     +-- -RW- EnumVal  =20 mstpPortAdminNonStp(13)
   |    =20 |        Textual Convention:=20 TruthValue
   |    =20 |        Values: true(1),=20 false(2)
   |     +-- -RW- = EnumVal  =20 mstpPortProtocolMigration(14)
   |    =20 |        Textual Convention:=20 TruthValue
   |    =20 |        Values: true(1),=20 false(2)
   |     +-- -R-- = Counter  =20 mstpPortRxTcnBpduCounter(15)
   |    =20 |        Textual Convention:=20 BpduCounter
   |     +-- -R--=20 Counter   mstpPortRxCfgBpduCounter(16)
  =20 |     +-- -R-- Counter  =20 mstpPortRxRstBpduCounter(17)
   |     = +-- -R--=20 Counter   mstpPortRxMstBpduCounter(18)
  =20 |     +-- -R-- Counter  =20 mstpPortTxTcnBpduCounter(19)
   |     = +-- -R--=20 Counter   mstpPortTxCfgBpduCounter(20)
  =20 |     +-- -R-- Counter  =20 mstpPortTxRstBpduCounter(21)
   |     = +-- -R--=20 Counter   mstpPortTxMstBpduCounter(22)
  =20 |
   +--mstpMapTable(12)
   |  = |
  =20 |  +--mstpMapEntry(1)
   |     = | =20 Index: mstpMapMSTiID, mstpMapVlanRangeIndex
  =20 |     |
   |     = +-- ----=20 Integer32 mstpMapMSTiID(1)
   |    =20 |        Textual Convention:=20 MstiInstanceIndex
   |    =20 |        Range: 1..64
   = |     +-- ---- Integer32=20 mstpMapVlanRangeIndex(2)
   |    =20 |        Range: = 1..4094
  =20 |     |
   |    =20 +--mstpMapVlanMin(3)
   |     = |
  =20 |     +--mstpMapVlanMax(4)
  =20 |     |
   |     = +-- CR--=20 EnumVal   mstpMapRowStatus(9)
  =20 |            =  =20 Textual Convention: RowStatus
  =20 |            =  =20 Values: active(1), notInService(2), notReady(3),
  =20 |            =          =20 createAndGo(4), createAndWait(5), destroy(6)
   = |
  =20 +--mstpXstTable(13)
   |  |
   | =20 +--mstpXstEntry(1)
   |     |  = Index:=20 mstpXstId
   |     |
  =20 |     +-- ---- Integer32 = mstpXstId(1)
  =20 |     |        = Textual=20 Convention: MstiOrCistInstanceIndex
   = |    =20 |        Range: 0..64
   = |     +-- -RW- Integer32=20 mstpXstBridgePriority(2)
   |    =20 |        Range: = 0..61440
  =20 |     +-- -R-- String   =20 mstpXstBridgeId(3)
   |    =20 |        Textual Convention:=20 BridgeId
   |    =20 |        Size: 8
  =20 |     +-- -R-- String   =20 mstpXstDesignatedRoot(4)
   |    =20 |        Textual Convention:=20 BridgeId
   |    =20 |        Size: 8
  =20 |     +-- -R-- String   =20 mstpXstDesignatedBridge(5)
   |    =20 |        Textual Convention:=20 BridgeId
   |    =20 |        Size: 8
  =20 |     +-- -R-- Integer32=20 mstpXstInternalRootCost(6)
   |     +-- = -R--=20 Integer32 mstpXstRootPort(7)
   |    =20 |        Textual Convention:=20 PortIndexOrZero
   |    =20 |        Range: = 0..2147483647
  =20 |     +-- -R-- Integer32=20 mstpXstMasterPort(8)
   |    =20 |        Textual Convention:=20 PortIndexOrZero
   |    =20 |        Range: = 0..2147483647
  =20 |     +-- -R-- TimeTicks=20 mstpXstTimeSinceTopologyChange(11)
   = |     +--=20 -R-- Counter   mstpXstTopologyChangesCount(12)
   = |     +-- -R-- EnumVal  =20 mstpXstTopologyChangeFlag(13)
  =20 |            =  =20 Textual Convention: TruthValue
  =20 |            =  =20 Values: true(1), false(2)
   |
  =20 +--mstpXstPortTable(14)
     =20 |
     =20 +--mstpXstPortEntry(1)
        = ;=20 |  Index: mstpXstPortXstId,=20 mstpXstPortIndex
        =20 |
         +-- ---- Integer32 = mstpXstPortXstId(1)
        =20 |        Textual Convention:=20 MstiOrCistInstanceIndex
       &nbs= p;=20 |        Range:=20 0..64
         +-- -R-- = Integer32=20 mstpXstPortIndex(2)
        =20 |        Textual Convention:=20 PortIndex
        =20 |        Range:=20 1..2147483647
         +-- = -R--=20 EnumVal  =20 mstpXstPortState(3)
        =20 |        Values: disabled(1), = discarding(1),=20 learning(2), forwarding(3),=20 unknown(4)
         +-- -R--=20 EnumVal  =20 mstpXstPortRole(4)
        =20 |        Values: disabled(1), = alternate(2),=20 backup(3), root(4),
        =20 |            =    =20 designated(5), master(6), nonStp(7),=20 unknown(8)
         +-- -R--=20 String   =20 mstpXstPortDesignatedRoot(6)
       = ; =20 |        Textual Convention:=20 BridgeId
        =20 |        Size:=20 8
         +-- -R-- Integer32 = mstpXstPortExternalRootCost(7)
      &nb= sp; =20 +-- -R-- String   =20 mstpXstPortRegionalBridge(8)
       = ; =20 |        Textual Convention:=20 BridgeId
        =20 |        Size:=20 8
         +-- -R-- Integer32 = mstpXstPortInternalRootCost(9)
      &nb= sp; =20 +-- -R-- String   =20 mstpXstPortDesignatedBridge(10)
      &n= bsp; =20 |        Textual Convention:=20 BridgeId
        =20 |        Size:=20 8
         +-- -R--=20 String   =20 mstpXstPortDesignatedPort(14)
      &nbs= p; =20 |        Textual Convention:=20 PortId
        =20 |        Size:=20 2
         +-- -RW- Integer32 = mstpXstPortPriority(15)
       &nbs= p;=20 |        Range:=20 0..255
         +-- -RW- = Integer32=20 mstpXstPortAdminInternalPathCost(16)
     &nb= sp;  =20 |        Range:=20 0..200000000
         +-- = -R--=20 Integer32 mstpXstPortOperInternalPathCost(17)

On Wednesday,=20 November 03, 2004 4:15 PM  Congdon, Paul T (ProCurve)=20 wrote:
> I've uploaded Alex Ruzin's = MSTP=20 MIB.  Note that this is slightly
> different than the MIB = that Alex=20 cut-and-pasted to a previous email.
> The document may be = retrieved=20 at:
>
> http://www.ieee802.org/1/files/public/docs200= 4/ruzin-mstp-mib-00.txt

------=_NextPart_000_00E5_01C4C735.9CB37FE0-- --===============0827313004== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib --===============0827313004==-- From bridge-mib-bounces@ietf.org Wed Nov 10 15:13:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22229 for ; Wed, 10 Nov 2004 15:13:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRyrl-0003zn-PO for bridge-mib-archive@ietf.org; Wed, 10 Nov 2004 15:14:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRymV-000443-43; Wed, 10 Nov 2004 15:09:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRyau-0002NQ-3a for bridge-mib@megatron.ietf.org; Wed, 10 Nov 2004 14:57:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19623 for ; Wed, 10 Nov 2004 14:57:25 -0500 (EST) Message-Id: <200411101957.OAA19623@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRybu-0003Vb-OY for bridge-mib@ietf.org; Wed, 10 Nov 2004 14:58:31 -0500 Received: from djyxpy41 (unknown[130.129.132.118]) by comcast.net (sccrmhc11) with SMTP id <2004111019565501100mf70je>; Wed, 10 Nov 2004 19:56:55 +0000 From: "David B Harrington" To: , "'Congdon, Paul T \(ProCurve\)'" , Subject: RE: [Bridge-mib] RE: [802.1] Alex Ruzin MSTP MIB Proposal - explanations Date: Wed, 10 Nov 2004 14:56:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTHJlwJYuIVWAvDRaiLFjm97achRAANWgVQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <00e401c4c724$d92aafe0$87885ac2@Alexr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 715d0e6950aaebd45af78ef9318d0186 Content-Transfer-Encoding: 7bit Cc: bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 9178bae9f85419fdc08e9f2c86e345d0 Content-Transfer-Encoding: 7bit Hi Alex, Thanks for the explanation. As Bridge WG co-chair, I need to address the MSTP MIB work as we transition development of MIB modules for 802.1 technologies from IETF to IEEE. The MSTP-MIB is out of scope for the IETF BridgeMIB WG, so technical discussion of proposals should not be posted to the Bridge WG mailing list. The appropriate mailing list for MSTP-MIB discussion is STDS-802-1-L@listserv.ieee.org. To subscribe to the STDS-802-1-L list, go to http://www.ieee802.org/1/email-pages/ To see the general information about 802,1, including how they work and how to participate, go to http://www.ieee802.org/1/ Currently, the discussion on STDS-802-1-L is whether to develop a PAR for this work. In IETF terms, the IEEE discussion is whether to add the MSTP-MIB to their charter. They have a formal procedure that needs to be followed. If you have a document related to MSTP-MIB, you can have it posted to the documents folder via the 802.1 chair or vice-chair. I follow the STDS-802-1-L list, and will be happy to advise the Bridge WG that such documents have been posted. (feel free to "ping" me that such documents have been posted on the IEEE web site.) David Harrington dbharrington@comcast.net Bridge WG co-chair ________________________________ From: bridge-mib-bounces@ietf.org [mailto:bridge-mib-bounces@ietf.org] On Behalf Of Alex Ruzin Sent: Wednesday, November 10, 2004 7:58 AM To: 'Congdon, Paul T (ProCurve)'; STDS-802-1-L@listserv.ieee.org Cc: bridge-mib@ietf.org Subject: [Bridge-mib] RE: [802.1] Alex Ruzin MSTP MIB Proposal - explanations (Sorry for HTML, but I want you to see a nice diagram below). I dare to provide a number of explanations for ruzin-mstp-mib-00.txt from http://www.ieee802.org/1/files/public/docs2004/ruzin-mstp-mib-00.txt This MIB contains 6 parts: mstpTraps, mstpGen, mstpPortTable, mstpMapTable, mstpXstTable and mstpXstPortTable: 1. mstpTraps help to get information about changes in MSTP active topology asynchronous notifications. Conditions and parameters seem to be clear, while may be discussed. 2. mstpGen. This group is dedicated to manage Bridge Protocol Entity, described in 12.8.1.1 and 12.8.1.3. In a certain sense this group reflects CIST, but without objects, that may be managed in mstpXstTable, see below. 3. mstpPortTable allows to manage physical ports, as it is described in 1.8.2.1., 1.80.2.3., 1.8.2.5 and 12.8.2.7. In a certain sense this group reflects CIST ports, but without objects, that may be managed in mstpXstPortTable, see below. 4. mstpMapTable serves for MSTI List management. It allows to build/delete instances and to map FIDs/VIDs (12.12). Actually, this table reflects MST Configuration Table in format, that is defined in 13.7 item 4). It must be admitted that I "grabbed" the idea of ranges in this table from malhotra-mstpmib-01.txt 5. mstpXstTable reflects instances - both CIST and MSTIs (12.8.1.2 and 12.8.1.4). It contains objects, common for these both types of instances, for example, mstpXstBridgePriority. 6. mstpXstPortTable is dedicated to manage ports inside instances - both CIST and MSTIs (12.8.2.2., 12.8.2.4 and 12.8.2.6). It contains objects, describing port and common for these both types of instances, for example, mstpXstPortState or mstpXstPortPriority. Note, that this table has mstpXstPortInternalRootCost, while mstpPortAdminExternalPathCost belongs to mstpPortTable. Important, that the index mstpXstId in mstpXstTable and mstpXstPortXstId in mstpXstPortTable have type MstiOrCistInstanceIndex : "value of zero" corresponds to CIST. Now, I'd like to mention in passing objects, that are not defined in .1s Let us begin from less questionable. 1. mstpPortAutoEdge. It came from new .1d 917.13.3) and I don't expect many objections here :) 2. mstpXstPortRole. The exploitation of MSTP shows, that managers of complicated networks want to know reasons of ports states assignations. So, they concerned with ports roles. In my opinion, this object is important not only debug purposes. 3. The similar destination have so called BpduCounters. Let's say, when a port stops to be RootPort, a manager may see, that receive BpduCounters on this port do not rise. He may trace bridges and select a point of failure. And what is more, I'd define an object mstpXstPortRxMstBpduCounter to count MSTI Configuration Messages. Sure, all these counters are optional: if an agent cannot provide for them it must return zero. 4. mstpGenCapable. A manager has to know, what version of STP the bridge supplies. If it supplies a number of versions (see mstpGenForceVersion), the eldest one must be returned. 5. mstpGenForceVersion. If the bridge can supply a number of versions of STP (let's say, it has a number of corresponding engines) a manager may want to enable one of them (and of course to disable all others) he may use with this object. This object also show which engine is currently enabled. 6. The value forceNonStp(0) of object mstpGenForceVersion. I remember a few of dispute both in IETF and in IEEE : what is STP disabled into a bridge. I know and share a position of IEEE, that there may not be bridge with STP disabled, nevertheless... The term "Spanning Tree Protocol Emulation" here means, that a bridge is transparent for received BPDUs (does flooding: transmits from all ports, without tags and without VLAN participation) and processes Topology Change bit: does appropriate FDB flushing. 7. mstpPortAdminNonStp. Certain port may be configured as a port, that does not participate in any STP operations: a) it discards all BDPUs, b) does not send BPDUs and c) is always in forwarding state. This option may help to termination point of STP domain. 8. mstpXstMasterPort. Servers the same purposes as mstpXstPortRole and BpduCounters. On the other hand, is not less helpful than mstpXstRootPort; furthermore it may help to indicate fallacious instance mapping (when a manager expects bridges in the same region, this object must be zero). 9. Both mstpXstRootPort and mstpXstMasterPort have type PortIndexOrZero. Brief structure of the MIB (result of "snmptranslate -Tp"): +--mstp(XXX) | +--mstpTraps(0) | | | +--dos1sNewRootBridge(1) | +--dos1sNewRootPort(2) | +--dos1sTopologyChange(3) | +--mstpGen(10) | | | +-- -RW- INTEGER mstpGenBridgeMaxAge(2) | | Textual Convention: Timeout | | Range: 600..4000 | +-- -RW- INTEGER mstpGenBridgeHelloTime(3) | | Textual Convention: Timeout | | Range: 100..1000 | +-- -RW- INTEGER mstpGenBridgeForwardDelay(4) | | Textual Convention: Timeout | | Range: 400..3000 | +-- -R-- INTEGER mstpGenMaxAge(8) | | Textual Convention: Timeout | | Range: 600..4000 | +-- -R-- INTEGER mstpGenHelloTime(9) | | Textual Convention: Timeout | | Range: 100..1000 | +-- -R-- INTEGER mstpGenForwardDelay(10) | | Textual Convention: Timeout | | Range: 400..3000 | +-- -RW- Integer32 mstpGenMaxHops(14) | | Range: 4..30 | +-- -RW- INTEGER mstpGenHoldTime(15) | | Textual Convention: Timeout | | Range: 100..1000 | +-- -RW- INTEGER mstpGenMigrateTime(16) | | Textual Convention: Timeout | | Range: 100..1000 | +-- -RW- EnumVal mstpGenPathCostDefault(18) | | Values: pathCostDefault8021d1998(1), pathCostDefault8021t2001(2) | +-- -R-- EnumVal mstpGenCapable(19) | | Values: nonStp(0), dot1d1998(1), dot1w(2), dot1d2004(3), | | dot1s(4), dot1q(5), unknown(6) | +-- -RW- EnumVal mstpGenForceVersion(20) | | Values: forceNonStp(0), forceLegacyDot1d(1), | | forceDot1w(2), autoDot1s(3), unknown(4) | +-- -RW- String mstpGenCfgName(21) | | Textual Convention: DisplayString | | Size: 32 | +-- -RW- Integer32 mstpGenRevLevel(22) | +-- -R-- String mstpGenReginalRoot(26) | | Textual Convention: BridgeId | | Size: 8 | +-- -R-- Integer32 mstpGenExternalRootCost(27) | +--mstpPortTable(11) | | | +--mstpPortEntry(1) | | Index: mstpPortIndex | | | +-- -R-- Integer32 mstpPortIndex(1) | | Textual Convention: PortIndex | | Range: 1..2147483647 | +-- -RW- EnumVal mstpPortAdminMACEnable(2) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -R-- EnumVal mstpPortOperMACEnable(3) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -R-- TimeTicks mstpPortUpTime(4) | +-- -RW- Integer32 mstpPortAdminExternalPathCost(5) | | Range: 0..200000000 | +-- -R-- Integer32 mstpPortOperExternalPathCost(6) | +-- -RW- EnumVal mstpPortAdminEdge(7) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -R-- EnumVal mstpPortOperEdge(8) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -RW- EnumVal mstpPortAutoEdge(9) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -RW- EnumVal mstpPortAdminPointToPoint(10) | | Values: forceTrue(0), forceFalse(1), auto(2) | +-- -R-- EnumVal mstpPortOperPointToPoint(11) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -RW- INTEGER mstpPortHelloTime(12) | | Textual Convention: Timeout | | Range: 100..1000 | +-- -RW- EnumVal mstpPortAdminNonStp(13) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -RW- EnumVal mstpPortProtocolMigration(14) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -R-- Counter mstpPortRxTcnBpduCounter(15) | | Textual Convention: BpduCounter | +-- -R-- Counter mstpPortRxCfgBpduCounter(16) | +-- -R-- Counter mstpPortRxRstBpduCounter(17) | +-- -R-- Counter mstpPortRxMstBpduCounter(18) | +-- -R-- Counter mstpPortTxTcnBpduCounter(19) | +-- -R-- Counter mstpPortTxCfgBpduCounter(20) | +-- -R-- Counter mstpPortTxRstBpduCounter(21) | +-- -R-- Counter mstpPortTxMstBpduCounter(22) | +--mstpMapTable(12) | | | +--mstpMapEntry(1) | | Index: mstpMapMSTiID, mstpMapVlanRangeIndex | | | +-- ---- Integer32 mstpMapMSTiID(1) | | Textual Convention: MstiInstanceIndex | | Range: 1..64 | +-- ---- Integer32 mstpMapVlanRangeIndex(2) | | Range: 1..4094 | | | +--mstpMapVlanMin(3) | | | +--mstpMapVlanMax(4) | | | +-- CR-- EnumVal mstpMapRowStatus(9) | Textual Convention: RowStatus | Values: active(1), notInService(2), notReady(3), | createAndGo(4), createAndWait(5), destroy(6) | +--mstpXstTable(13) | | | +--mstpXstEntry(1) | | Index: mstpXstId | | | +-- ---- Integer32 mstpXstId(1) | | Textual Convention: MstiOrCistInstanceIndex | | Range: 0..64 | +-- -RW- Integer32 mstpXstBridgePriority(2) | | Range: 0..61440 | +-- -R-- String mstpXstBridgeId(3) | | Textual Convention: BridgeId | | Size: 8 | +-- -R-- String mstpXstDesignatedRoot(4) | | Textual Convention: BridgeId | | Size: 8 | +-- -R-- String mstpXstDesignatedBridge(5) | | Textual Convention: BridgeId | | Size: 8 | +-- -R-- Integer32 mstpXstInternalRootCost(6) | +-- -R-- Integer32 mstpXstRootPort(7) | | Textual Convention: PortIndexOrZero | | Range: 0..2147483647 | +-- -R-- Integer32 mstpXstMasterPort(8) | | Textual Convention: PortIndexOrZero | | Range: 0..2147483647 | +-- -R-- TimeTicks mstpXstTimeSinceTopologyChange(11) | +-- -R-- Counter mstpXstTopologyChangesCount(12) | +-- -R-- EnumVal mstpXstTopologyChangeFlag(13) | Textual Convention: TruthValue | Values: true(1), false(2) | +--mstpXstPortTable(14) | +--mstpXstPortEntry(1) | Index: mstpXstPortXstId, mstpXstPortIndex | +-- ---- Integer32 mstpXstPortXstId(1) | Textual Convention: MstiOrCistInstanceIndex | Range: 0..64 +-- -R-- Integer32 mstpXstPortIndex(2) | Textual Convention: PortIndex | Range: 1..2147483647 +-- -R-- EnumVal mstpXstPortState(3) | Values: disabled(1), discarding(1), learning(2), forwarding(3), unknown(4) +-- -R-- EnumVal mstpXstPortRole(4) | Values: disabled(1), alternate(2), backup(3), root(4), | designated(5), master(6), nonStp(7), unknown(8) +-- -R-- String mstpXstPortDesignatedRoot(6) | Textual Convention: BridgeId | Size: 8 +-- -R-- Integer32 mstpXstPortExternalRootCost(7) +-- -R-- String mstpXstPortRegionalBridge(8) | Textual Convention: BridgeId | Size: 8 +-- -R-- Integer32 mstpXstPortInternalRootCost(9) +-- -R-- String mstpXstPortDesignatedBridge(10) | Textual Convention: BridgeId | Size: 8 +-- -R-- String mstpXstPortDesignatedPort(14) | Textual Convention: PortId | Size: 2 +-- -RW- Integer32 mstpXstPortPriority(15) | Range: 0..255 +-- -RW- Integer32 mstpXstPortAdminInternalPathCost(16) | Range: 0..200000000 +-- -R-- Integer32 mstpXstPortOperInternalPathCost(17) On Wednesday, November 03, 2004 4:15 PM Congdon, Paul T (ProCurve) wrote: > I've uploaded Alex Ruzin's MSTP MIB. Note that this is slightly > different than the MIB that Alex cut-and-pasted to a previous email. > The document may be retrieved at: > > http://www.ieee802.org/1/files/public/docs2004/ruzin-mstp-mib-00.txt _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Nov 11 03:25:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12695 for ; Thu, 11 Nov 2004 03:25:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSAHU-0003mK-NJ for bridge-mib-archive@ietf.org; Thu, 11 Nov 2004 03:26:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSAF4-0000JM-29; Thu, 11 Nov 2004 03:23:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRsuh-0003kk-M3 for bridge-mib@megatron.ietf.org; Wed, 10 Nov 2004 08:53:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08504 for ; Wed, 10 Nov 2004 08:53:30 -0500 (EST) Received: from apollo.nbase.co.il ([194.90.137.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRsvf-0002Mi-DT for bridge-mib@ietf.org; Wed, 10 Nov 2004 08:54:32 -0500 Received: from Alexr ([194.90.136.135]) by apollo.nbase.co.il (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-44418U200L2S100) with SMTP id AAA2772; Wed, 10 Nov 2004 15:23:04 +0200 From: arozin@mrv.com (Alex Ruzin) To: Date: Wed, 10 Nov 2004 15:23:42 +0200 Message-ID: <00fb01c4c728$7ffaab10$87885ac2@Alexr> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.6 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-Mailman-Approved-At: Thu, 11 Nov 2004 03:23:40 -0500 Subject: [Bridge-mib] Re: [802.1] Alex Ruzin MSTP MIB Proposal - explanations X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arozin@mrv.com List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0114327431==" Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f This is a multi-part message in MIME format. --===============0114327431== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FC_01C4C739.43837B10" This is a multi-part message in MIME format. ------=_NextPart_000_00FC_01C4C739.43837B10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dan, It would be good if my propositions & comments may be considered "regardless of my presence in the meeting". I forward you a letter, that I got from Paul: On Wednesday, November 03, 2004 4:28 PM Congdon, Paul T (ProCurve) wrote: > Your welcome. > > I understand you will not be able to attend the 802.1 meeting. In the > future, to assure this is getting proper review and to obtain voting > rights within the working group, meeting attendance will be necessary. > For this meeting, if you can persuade someone who understands > the design and intricacies of your mib to present the ideas, we can get > agenda time for that person regardless of your presence... > > Paul Thanks, Alex Wednesday, November 10, 2004 3:03 PM you wrote: > Alex, > > Thanks for the contribution and the comments. It would be > good to prepare a short presentation for the IEEE 802.1 > meeting. As per the agenda the MIB discussion is the first > thing Monday morning at 9AM. > > Regards, > > Dan ------=_NextPart_000_00FC_01C4C739.43837B10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dan,
It would be good if my propositions & comments
may be=20 considered "regardless of my presence in
the meeting". I forward you = a=20 letter, that I got from
Paul:

On Wednesday, November 03, 2004 = 4:28 PM=20 Congdon, Paul T (ProCurve) wrote:
> Your=20 welcome.
>
> I understand you will not be able to attend the = 802.1=20 meeting.  In the
> future, to assure this is getting proper = review=20 and to obtain voting
> rights within the working group, meeting = attendance=20 will be necessary.
> For this meeting, if you can persuade someone = who=20 understands
> the design and intricacies of your mib to = present the=20 ideas, we can get
> agenda time for that person regardless of = your=20 presence...
>
> Paul

Thanks,=20 Alex

Wednesday, November 10, 2004 3:03 PM you = wrote:
> Alex,
>
> Thanks for the contribution = and the=20 comments. It would be
> good to prepare a short presentation for = the IEEE=20 802.1
> meeting. As per the agenda the MIB discussion is the = first
>=20 thing Monday morning at 9AM.
>
> Regards,
>
> = Dan=20

------=_NextPart_000_00FC_01C4C739.43837B10-- --===============0114327431== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib --===============0114327431==-- From bridge-mib-bounces@ietf.org Thu Nov 11 16:41:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01657 for ; Thu, 11 Nov 2004 16:41:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSMiV-00063V-Nk for bridge-mib-archive@ietf.org; Thu, 11 Nov 2004 16:42:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSMSe-0002ql-Ee; Thu, 11 Nov 2004 16:26:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSMHf-0004ts-DW for bridge-mib@megatron.ietf.org; Thu, 11 Nov 2004 16:15:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28873 for ; Thu, 11 Nov 2004 16:15:09 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSMIr-0005KW-Vf for bridge-mib@ietf.org; Thu, 11 Nov 2004 16:16:28 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id B33C331B6; Thu, 11 Nov 2004 22:14:32 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31981-05; Thu, 11 Nov 2004 22:14:31 +0100 (CET) Received: from james (unknown [130.129.133.233]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id A8FA7313A; Thu, 11 Nov 2004 22:14:31 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CSMH1-00011I-AF; Thu, 11 Nov 2004 22:14:31 +0100 Date: Thu, 11 Nov 2004 22:14:31 +0100 From: Juergen Schoenwaelder To: Les Bell Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 Message-ID: <20041111211431.GA3911@james> Mail-Followup-To: Les Bell , bridge-mib@ietf.org References: <80256F40.003616A1.00@notesmta.eur.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80256F40.003616A1.00@notesmta.eur.3com.com> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Tue, Nov 02, 2004 at 09:50:14AM +0000, Les Bell wrote: > > Use of the 32-bit path cost was defined in both 802.1w (RSTP) and 802.1t. > 802.1t was a collection of enhacements to Bridges, including those that support > legacy STP. So the 32-bit path costs do not just apply to RSTP. > > I think you are right that dot1dStpPortPathCost32 should be conditionally > mandatory, but for any Spanning Tree implementation that supports 32-bit path > costs, not just for RSTP. OK, I have created another group and this makes the support for dot1dStpPortPathCost32 conditionally mandatory. > Implementations that support 32-bit path costs should not use the 16-bit path > cost object, dot1dStpPortPathCost, but I am not sure what is the best way to > deal with this. Are we allowed to allocate a special value to indicate it is > not in use? I think it would be safer to return an SNMP error indicating the > old object is not supported. dot1dStpPortPathCost is Integer32 (1..65535). Is there a value (e.g., 65535) which can be picked for this purpose? What do implementation do? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Nov 11 16:42:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01762 for ; Thu, 11 Nov 2004 16:42:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSMj4-00065I-8w for bridge-mib-archive@ietf.org; Thu, 11 Nov 2004 16:43:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSMSf-0002sD-LJ; Thu, 11 Nov 2004 16:26:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSMJf-0005wk-1p for bridge-mib@megatron.ietf.org; Thu, 11 Nov 2004 16:17:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28996 for ; Thu, 11 Nov 2004 16:17:13 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSMKs-0005NR-Sw for bridge-mib@ietf.org; Thu, 11 Nov 2004 16:18:32 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id F3B5B313A for ; Thu, 11 Nov 2004 22:16:42 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 32048-05; Thu, 11 Nov 2004 22:16:42 +0100 (CET) Received: from james (unknown [130.129.133.233]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id C1C1931BB; Thu, 11 Nov 2004 22:16:41 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CSMJ7-00011P-MY; Thu, 11 Nov 2004 22:16:41 +0100 Date: Thu, 11 Nov 2004 22:16:41 +0100 From: Juergen Schoenwaelder To: bridge-mib@ietf.org Message-ID: <20041111211641.GB3911@james> Mail-Followup-To: bridge-mib@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Bridge-mib] unit of dot1dTpPortMaxInfo X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c What is the unit of dot1dTpPortMaxInfo? I guess it is bytes, but the document does not really say so (and the bridges I looked at return values that are, well, somewhat surprising). Is it safe to add UNITS "bytes" here? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib