From vau7kgwytab1w@hotmail.com Thu Nov 1 00:01:44 2001 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11363 for ; Thu, 1 Nov 2001 00:01:43 -0500 (EST) From: vau7kgwytab1w@hotmail.com Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fA14Z2M29839; Wed, 31 Oct 2001 20:35:03 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id fA14bCf15824; Wed, 31 Oct 2001 20:37:12 -0800 (PST) Received: from web.genesis21.co.kr ([211.58.254.63]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id fA14atK22322; Wed, 31 Oct 2001 20:36:55 -0800 (PST) Received: from 63.232.114.193 (0-1pool114-193.nas1.austin1.tx.us.da.qwest.net [63.232.114.193]) by web.genesis21.co.kr (8.10.2/8.11.1) with SMTP id fA14JPR23733; Thu, 1 Nov 2001 13:19:25 +0900 Message-Id: <200111010419.fA14JPR23733@web.genesis21.co.kr> To: Subject: Have Hair Loss? We Can Help You!..Read on.. Date: Sat, 03 Nov 2001 12:06:19 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Errors-To: ckydwtyc4td@mail-online.dk X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-Transfer-Encoding: quoted-printable Receive 10
 

Hair Loss Got You Down?
 Would You Like to do Something About It?

 
$50 SAVINGS on Initial Order

(Mentio= n product code 15 to save $50 on initial order)=

Patente= d Hair Accelerator products are an all natural scientifically p= roven way to stop hair loss and grow new hair!

  Hair Accelerator products are the first drug= -free "total attack" program that aggressively combats hair loss= internally and externally.  Our hair loss products have been c= linically tested at Hospitals and Universities throughout the Worl= d.

 

Also Re= ceive our FREE Online Guide to Hair Loss!

Start feeling confident again! Take the first step now!<= br>
We Can Help You!

Click Here Fo= r Details

  
 

=

This email was sent to you because your email is part of a targeted opt-i= n list.  If you do not wish to receive further mailings, please c= lick below and enter your email at the bottom of the page.  You may = then rest-assured that you will never receive another email from us again= .  UNSUBSCRIBE ME PLEASE #022481
From daemon@optimus.ietf.org Mon Nov 5 09:23:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19770 for ; Mon, 5 Nov 2001 09:23:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA10850 for bridge-archive@odin.ietf.org; Mon, 5 Nov 2001 09:23:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10815; Mon, 5 Nov 2001 09:21:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06694 for ; Mon, 5 Nov 2001 07:14:17 -0500 (EST) Received: from MAILGW ([194.90.137.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12168 for ; Mon, 5 Nov 2001 07:14:02 -0500 (EST) Received: from apollo.nbase.co.il ([194.90.137.2]) by MAILGW (MailGuardian SMTP Relay 1.2.1) with SMTP ID Mail1004969408983--84; Mon, 5 Nov 2001 16:10:08 +0200 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 AAA69; Mon, 5 Nov 2001 14:01:07 +0200 Reply-To: From: alexr@nbase.co.il (Alex Ruzin) To: Cc: , Date: Mon, 5 Nov 2001 14:00:40 +0200 Message-ID: <002d01c165f1$7d9e88f0$87885ac2@Alexr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_002E_01C16602.412758F0" 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 V5.50.4133.2400 Importance: Normal Subject: [Bridge-mib] (no subject) Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C16602.412758F0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit Dear Ladies & Gentlemen, First let me introduce myself. I am responsible for SNMP and, occasionally, for Spanning Tree in my company. I had implemented Spanning Tree 802.1d and a Bridge MIB RFC1493. Now I've finished the first step of implementation of Rapid Spanning Tree 802.1w (it is under alpha testing now). This implementation, among other, supports a possibility to create one STP instance per VLAN (I know, it is not 802.1s compatible, it will be a next step). In a parallel way I am designing our private MIB for SNMP support for these features. In this message I am attaching it: may be ( and I will consider it as a great honor for myself) some ideas from it will be useful for you in your work under draft-ietf-bridge-rstpmib-00.txt Would you like to send your comments and remarks, I'll accept them with great gratitude. The attached files are: RSTP.mib - the MIB draft rstp.txt the brief structure of MIB, as it is presented by snmptranslate utility of NET-SNMP. Now please allow me to make some comments. . 1. For many reasons it is convenient to have a possibility to configure an device for operation after nearest reset. For STP this possibility has a special importance, while a non-atomic setting of parameters may follow drastic and unwanted changes in the network. So, the configuration that will be applied after nearest reset we call 'NVRAM-configuration'. The configuration of the *operating now* device is called 'RUN configuration'. For this concept reflection we use an TEXTUAL-CONVENTION named "StorageType". All writeble tables are indexed with an object of this type. Sure, the alternative is to organize two separate tables: one for run and one for NVRAM. I have to point, that our old MIBs have been organized in such way. 2. For the same reason all objects are separated onto writeble and readable-only tables. Sure (and it is a purpose), the latter type of tables are not indexed with object of StorageType type. More of that, we consider such division as a method to make a MIB more understandable by network managers. 3. We inserted in the MIB so called rstpMSTiCfgTable as a preparation for MSTP support. Now it allows us to support RSTP instances per VLAN. 4. In RFC1493 the dot1dTpFdbTable is indexed only by dot1dTpFdbAddress. It doesn't allow to support 802.1q tagged properties of the Bridge may be I missed the new bridge MIB editions) . Our rstpMacTable is indexed by both rstpMacAddr and rstpMacVid (the latter one may be equal to 0 in the untagged case) Thank you for your tolerance & patience. I look forward to working with you in the cooperation, while as far as I see private MIBs design is the evil, and we have to avoid it as strong as possible. Best regards, Alex Rozin ============ Optical Access Ltd. P.O. Box 114 Yokneam 20692, ISRAEL Home : http://www.opticalaccess.com ------=_NextPart_000_002E_01C16602.412758F0 Content-Type: application/octet-stream; name="RSTP.mib" Content-Disposition: attachment; filename="RSTP.mib" Content-Transfer-Encoding: quoted-printable RSTP-MIB DEFINITIONS ::=3D BEGIN -- draft ! IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, TimeTicks FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, DisplayString, TruthValue FROM SNMPv2-TC mib-2, ifIndex FROM RFC1213-MIB InterfaceIndex, InterfaceIndexOrZero FROM IF-MIB; -- ************************************************************ -- NBase Object Identifier Definition -- ************************************************************ oaccess OBJECT IDENTIFIER ::=3D { enterprises 6926 } oaManagement OBJECT IDENTIFIER ::=3D { oaccess 1 } oaBridge OBJECT IDENTIFIER ::=3D { oaManagement 39} rstp MODULE-IDENTITY LAST-UPDATED "200107130000Z" ORGANIZATION "Optical Access Ltd." CONTACT-INFO "Alex Rozin Optical Access Email: ARozin@opticalaccess.com" DESCRIPTION "The MIB module for managing Rapid Spanning Protocol and algorith. It is dedicated to reflect 802.1w, 802.1s and = 802.t"=20 ::=3D { oaBridge 2 } MacAddress ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "A 6 octet address 'canonical' order." REFERENCE "EEE 802.1a." SYNTAX OCTET STRING (SIZE (6)) PortId ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "A 2 octet address 'canonical' order." REFERENCE "EEE 802.1w, 17.4.1." SYNTAX OCTET STRING (SIZE (2)) VlanID ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Unique identificator of the active VLAN. Value '0' means 'untagged' mode. Value '1' means 'default' VLAN, i.e. ports, that do not participate in any VLAN." REFERENCE "IEEE 802.1Q." SYNTAX INTEGER (0..4095) BridgeId ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Protocol to uniquely identify a bridge. Its first two octets (in network byte order) contain a priority value and its last 6 octets contain the MAC address used to refer to a bridge in a unique fashion (typically, the numerically smallest MAC address of all ports on the bridge)." REFERENCE "IEEE 802.1w Clause 17.2." SYNTAX OCTET STRING (SIZE (8)) Timeout ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "A STP timer in units of 1/100 seconds To convert a Timeout value into a value in units of 1/256 seconds, the following algorithm should be used: =20 b =3D floor( (n * 256) / 100) =20 where: floor =3D quotient [ignore remainder] n is the value in 1/100 second units b is the value in 1/256 second units =20 To convert the value from 1/256 second units back to 1/100 seconds, the following algorithm should be used: =20 n =3D ceiling( (b * 100) / 256) =20 where: ceiling =3D quotient [if remainder is 0], or quotient + 1 [if remainder is non-zero] n is the value in 1/100 second units b is the value in 1/256 second units =20 Note: it is important that the arithmetic operations are done in the order specified (i.e., multiply first, divide second)." SYNTAX INTEGER StorageType ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "For many reasons it is convinient to have a possibility to configure STP for operation after nearest reset. This configuration we call 'NVRAM-configuration'. The configuration of the operating now device is called 'RUN configuration'. For 'SET' operations only the value all(6) is allowed - it means both NVRAM and RUN" SYNTAX INTEGER { run (2), nvram (4), all (6) } -- RSTP General Variables -- These parameters apply globally to the Bridge's RSTP = functionality. rstpGenCfgTable OBJECT-TYPE SYNTAX SEQUENCE OF RstpGenCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "." ::=3D { rstp 1 } rstpGenCfgEntry OBJECT-TYPE SYNTAX RstpGenCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "." INDEX { rstpGenCfgStorage } ::=3D { rstpGenCfgTable 1 } RstpGenCfgEntry ::=3D SEQUENCE { rstpGenCfgStorage StorageType, rstpGenCfgMode INTEGER } rstpGenCfgStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-only STATUS current DESCRIPTION "Index of rstpGenCfgTable." ::=3D { rstpGenCfgEntry 1 } rstpGenCfgMode OBJECT-TYPE SYNTAX INTEGER { nonStp (1), slowGlobal (2), slowPerVlan (3), rapidGlobal (4), rapidPerVlan (5), rapidMStp (6) -- 802.1s compatible } MAX-ACCESS read-write STATUS current DESCRIPTION "The STP/RSTP bridge mode." ::=3D { rstpGenCfgEntry 2 } rstpMSTiCfgTable OBJECT-TYPE SYNTAX SEQUENCE OF RstpMSTiCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "See IEEE 802.1s, 3.34, 13.7. MST Configuration table (VID=3D>MSTID translation): allocates each and every possible VLAN to CST or a specific MSTI. If the bridge is SST one this table contains one entry active = for rstpMSTiCfgStorage=3D'run(2)' and one active entry for rstpMSTiCfgStorage=3D'run(2)'. These two entries has both rstpMSTiCfgMSTiID & rstpMSTiCfgVlanId. (Alex: to discuss on = DR)" ::=3D { rstp 5 } rstpMSTiCfgEntry OBJECT-TYPE SYNTAX RstpMSTiCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "." INDEX { rstpMSTiCfgStorage, rstpMSTiCfgMSTiID, rstpMSTiCfgVlanId = } ::=3D { rstpMSTiCfgTable 1 } RstpMSTiCfgEntry ::=3D SEQUENCE { rstpMSTiCfgStorage StorageType, rstpMSTiCfgMSTiID VlanID, rstpMSTiCfgVlanId VlanID, rstpMSTiCfgRowStatus RowStatus } rstpMSTiCfgStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpMSTiCfgEntry 1 } rstpMSTiCfgMSTiID OBJECT-TYPE SYNTAX VlanID MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpMSTiCfgEntry 2 } rstpMSTiCfgVlanId OBJECT-TYPE SYNTAX VlanID MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpMSTiCfgEntry 3 } rstpMSTiCfgRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-write STATUS current DESCRIPTION "." ::=3D { rstpMSTiCfgEntry 6 } rstpBridgeCfgTable OBJECT-TYPE SYNTAX SEQUENCE OF RstpBridgeCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "." ::=3D { rstp 6 } rstpBridgeCfgEntry OBJECT-TYPE SYNTAX RstpBridgeCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "." INDEX { rstpBridgeCfgStorage, rstpMSTiCfgMSTiID } ::=3D { rstpBridgeCfgTable 1 } RstpBridgeCfgEntry ::=3D SEQUENCE { rstpBridgeCfgStorage StorageType, rstpBridgeCfgName DisplayString, rstpBridgeCfgPriority INTEGER, rstpBridgeCfgMaxAge Timeout, rstpBridgeCfgHelloTime Timeout, rstpBridgeCfgForwardDelay Timeout, rstpBridgeCfgForceVersion INTEGER, rstpBridgeCfgStatus RowStatus } rstpBridgeCfgStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpBridgeCfgEntry 3 } rstpBridgeCfgName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..24)) MAX-ACCESS read-write STATUS current DESCRIPTION "." ::=3D { rstpBridgeCfgEntry 5 } rstpBridgeCfgPriority OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "Bridge priority, 802.1w, 17.2 d)." DEFVAL { 32768 } ::=3D { rstpBridgeCfgEntry 6 } rstpBridgeCfgMaxAge OBJECT-TYPE SYNTAX Timeout (600..4000) MAX-ACCESS read-write STATUS current DESCRIPTION "." =20 DEFVAL { 2000 }=20 ::=3D { rstpBridgeCfgEntry 10 } rstpBridgeCfgHelloTime OBJECT-TYPE SYNTAX Timeout (100..1000) MAX-ACCESS read-write STATUS current DESCRIPTION "." DEFVAL { 200 } ::=3D { rstpBridgeCfgEntry 11 } rstpBridgeCfgForwardDelay OBJECT-TYPE SYNTAX Timeout (400..3000) MAX-ACCESS read-write STATUS current DESCRIPTION "." DEFVAL { 1500 } ::=3D { rstpBridgeCfgEntry 12 } rstpBridgeCfgForceVersion OBJECT-TYPE SYNTAX INTEGER=20 { slow (1), rapid (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "." DEFVAL { rapid } ::=3D { rstpBridgeCfgEntry 13 } rstpBridgeCfgStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-write STATUS current DESCRIPTION "." ::=3D { rstpBridgeCfgEntry 20 } rstpOperBridgeTable OBJECT-TYPE SYNTAX SEQUENCE OF RstpOperBridgeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "." ::=3D { rstp 7 } rstpOperBridgeEntry OBJECT-TYPE SYNTAX RstpOperBridgeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "." INDEX { rstpMSTiCfgMSTiID } ::=3D { rstpOperBridgeTable 1 } RstpOperBridgeEntry ::=3D SEQUENCE { rstpOperBridgeId BridgeId, rstpOperBridgeDesignatedRoot BridgeId, rstpOperBridgeRootCost INTEGER, rstpOperBridgeRootPort InterfaceIndexOrZero, rstpOperBridgeMaxAge Timeout, rstpOperBridgeHelloTime Timeout, rstpOperBridgeForwardDelay Timeout, rstpOperBridgeTopChanges INTEGER, rstpOperBridgeTimeSinceTopologyChange TimeTicks } rstpOperBridgeId OBJECT-TYPE SYNTAX BridgeId MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpOperBridgeEntry 3 } rstpOperBridgeDesignatedRoot OBJECT-TYPE SYNTAX BridgeId MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpOperBridgeEntry 4 } rstpOperBridgeRootCost OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpOperBridgeEntry 5 } rstpOperBridgeRootPort OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpOperBridgeEntry 6 } rstpOperBridgeMaxAge OBJECT-TYPE SYNTAX Timeout MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpOperBridgeEntry 10 } rstpOperBridgeHelloTime OBJECT-TYPE SYNTAX Timeout MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpOperBridgeEntry 12 } rstpOperBridgeForwardDelay OBJECT-TYPE SYNTAX Timeout MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpOperBridgeEntry 13 } rstpOperBridgeTopChanges OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpOperBridgeEntry 13 } rstpOperBridgeTimeSinceTopologyChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpOperBridgeEntry 13 } rstpPortCfgTable OBJECT-TYPE SYNTAX SEQUENCE OF RstpPortCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "." ::=3D { rstp 8 } rstpPortCfgEntry OBJECT-TYPE SYNTAX RstpPortCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "." INDEX { rstpPortCfgStorage, rstpMSTiCfgMSTiID, rstpPortCfgIndex = } ::=3D { rstpPortCfgTable 1 } RstpPortCfgEntry ::=3D SEQUENCE { rstpPortCfgStorage StorageType, rstpPortCfgIndex InterfaceIndex, rstpPortCfgPriority INTEGER, rstpPortCfgAdminPathCost INTEGER, rstpPortCfgAgminPointToPoint INTEGER, rstpPortCfgAdminEdge TruthValue, rstpPortCfgAdminForceVersion TruthValue } rstpPortCfgStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpPortCfgEntry 3 } rstpPortCfgIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpPortCfgEntry 5 } rstpPortCfgPriority OBJECT-TYPE SYNTAX INTEGER (0..240) MAX-ACCESS read-write STATUS current DESCRIPTION "In steps of 16." DEFVAL { 128 } ::=3D { rstpPortCfgEntry 10 } rstpPortCfgAdminPathCost OBJECT-TYPE SYNTAX INTEGER (0..200000000) MAX-ACCESS read-write STATUS current DESCRIPTION "The value '0' means autonegotiation, depending on port = speed, as it is described in 802.1w, Clause 17.28.2, Table 17-7." DEFVAL { 0 } ::=3D { rstpPortCfgEntry 11 } rstpPortCfgAgminPointToPoint OBJECT-TYPE SYNTAX INTEGER { no (0), yes (1), auto (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "." ::=3D { rstpPortCfgEntry 12 } rstpPortCfgAdminEdge OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "." ::=3D { rstpPortCfgEntry 13 } rstpPortCfgAdminForceVersion OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "802.1w 14.8.2.4: The mcheck variable (17.18.10) for the specified Port is set to the value TRUE if the value of the forceVersion variable (17.16.1) is greater than or equal = to 2." ::=3D { rstpPortCfgEntry 14 } rstpPortOperTable OBJECT-TYPE SYNTAX SEQUENCE OF RstpPortOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "." ::=3D { rstp 9 } rstpPortOperEntry OBJECT-TYPE SYNTAX RstpPortOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "." INDEX { rstpMSTiCfgMSTiID, rstpPortOperIndex } ::=3D { rstpPortOperTable 1 } RstpPortOperEntry ::=3D SEQUENCE { rstpPortOperIndex InterfaceIndex, rstpPortOperRole INTEGER, rstpPortOperState INTEGER, rstpPortOperPathCost INTEGER, rstpPortOperDesignatedRoot BridgeId, rstpPortOperDesignatedCost INTEGER, rstpPortOperDesignatedBridge BridgeId, rstpPortOperDesignatedPort PortId, rstpPortOperPointToPoint TruthValue, rstpPortOperEdge TruthValue, rstpPortOperSlowNeighbor TruthValue, rstpPortOperRxBpduRstp Counter32, rstpPortOperRxBpduConfig Counter32, rstpPortOperRxBpduTcn Counter32 } rstpPortOperIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpPortOperEntry 5 } rstpPortOperRole OBJECT-TYPE SYNTAX INTEGER { disabled (1), alternate (2), backup (3), designated (4), root (5) } MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpPortOperEntry 8 } rstpPortOperState OBJECT-TYPE SYNTAX INTEGER { disabled (1), blocking (2), listening (3), -- for 802.d compatibility learning (4), forwarding (5), broken (6) } MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpPortOperEntry 9 } rstpPortOperPathCost OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpPortOperEntry 10 } rstpPortOperDesignatedRoot OBJECT-TYPE SYNTAX BridgeId MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpPortOperEntry 11 } rstpPortOperDesignatedCost OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpPortOperEntry 12 } rstpPortOperDesignatedBridge OBJECT-TYPE SYNTAX BridgeId MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpPortOperEntry 13 } rstpPortOperDesignatedPort OBJECT-TYPE SYNTAX PortId MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpPortOperEntry 16 } rstpPortOperPointToPoint OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpPortOperEntry 17 } rstpPortOperEdge OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpPortOperEntry 18 } rstpPortOperSlowNeighbor OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpPortOperEntry 19 } rstpPortOperRxBpduRstp OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpPortOperEntry 24 } rstpPortOperRxBpduConfig OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpPortOperEntry 25 } rstpPortOperRxBpduTcn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "." ::=3D { rstpPortOperEntry 25 } -- Table -- ************************************************************* -- MAC Address Table of the Device. -- ************************************************************* rstpMac OBJECT IDENTIFIER ::=3D { rstp 12 } rstpMacInfo OBJECT IDENTIFIER ::=3D { rstpMac 1 } rstpMacInfoNumber OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Current number of entries in the learniong table." ::=3D { rstpMacInfo 1 } rstpMacInfoMaxNumbr OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Maximum number of entries in the learniong table." ::=3D { rstpMacInfo 2 } rstpMacInfoClear OBJECT-TYPE SYNTAX INTEGER { clear (2) } ACCESS write-only STATUS mandatory DESCRIPTION "GET always returns 'none (1)'. SET 'clear(2)' couses LT erasing. GET always returns 'none = (1)'. WARNING: erasing LT on some kind of agents may couse = disconnection for short period of time." ::=3D { rstpMacInfo 5 } rstpMacTable OBJECT-TYPE SYNTAX SEQUENCE OF RstpMacEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table that contains Learning Table with fields that does not exsist in dot1dTpFdbTable." ::=3D { rstpMac 2 } rstpMacEntry OBJECT-TYPE SYNTAX RstpMacEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about a specific MAC address in the rstpMacTable." INDEX { rstpMacAddr, rstpMacVid} ::=3D { rstpMacTable 1 } RstpMacEntry ::=3D SEQUENCE { rstpMacAddr MacAddress, rstpMacVid VlanID, rstpMacVidx VlanID, rstpMacGetViewIndex INTEGER, rstpMacPort InterfaceIndexOrZero, rstpMacMode INTEGER, rstpMacTagged TruthValue, rstpMacPriority INTEGER, rstpMacFlags INTEGER, rstpMacStatus INTEGER } rstpMacAddr OBJECT-TYPE SYNTAX MacAddress ACCESS read-only STATUS mandatory DESCRIPTION "MAC address for which the bridge has forwarding and/or filtering information." ::=3D { rstpMacEntry 1 } rstpMacVid OBJECT-TYPE SYNTAX VlanID ACCESS read-only STATUS mandatory DESCRIPTION "Tag of the entry: the address 'Address recognition' is concatenation of rstpMac and rstpMacVid. When ISVP is not implemented or ISVL mode is disabled, this field in SET/NEXT operations may have any value, GET operation should return 0." ::=3D { rstpMacEntry 2 } rstpMacVidx OBJECT-TYPE SYNTAX VlanID ACCESS read-write STATUS mandatory DESCRIPTION "Outbound VLAN tag: if frame 'Address recognition' was resolved with this entry, the forwarding will be maked according the VLAN with this tag. When ISVP is not implemented or ISVL mode is disabled, this field in SET operations may have any value, GET operation should return 0." ::=3D { rstpMacEntry 6 } rstpMacGetViewIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Sequantial index of the entry." ::=3D { rstpMacEntry 8 } rstpMacPort OBJECT-TYPE SYNTAX InterfaceIndexOrZero ACCESS read-write STATUS mandatory DESCRIPTION "Port of the entry. '0' value indicates that the port number has not been learned but that the bridge does have some forwarding/filtering information about this address. Another words, the frame will be forwarding 'to the CPU only' and the bridge will sovle, what it must be done with this frame." ::=3D { rstpMacEntry 9 } rstpMacMode OBJECT-TYPE SYNTAX INTEGER { dynamic (1), static (2) } ACCESS read-write STATUS mandatory DESCRIPTION "Status of the entry: Only 'dynamic(1) entries are aged." ::=3D { rstpMacEntry 20 } rstpMacTagged OBJECT-TYPE SYNTAX TruthValue ACCESS read-write STATUS mandatory DESCRIPTION "'Tagged' state of the entry. When ISVP is not implemented or ISVL mode is disabled, this field in SET operations may have any value, GET operation should return 0." ::=3D { rstpMacEntry 21 } rstpMacPriority OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "Controls the priority level of this entry" ::=3D { rstpMacEntry 22 } rstpMacFlags OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "Specific flags for MAC entry: 0x0001 - Router Entry" ::=3D { rstpMacEntry 23 } rstpMacStatus OBJECT-TYPE SYNTAX INTEGER { valid (1), invalid (2) } ACCESS read-write STATUS mandatory DESCRIPTION "State of the entry: Only 'valid(1)' entries participate in the forwarding/filtering process. The new entry is created when PDU with rstpMacStatus=3Dvalid(1), rstpMac, rstpMacVid and optionally rstpMacPort (default '0'), rstpMacVidx (default rstpMacVid) and rstpMacMode comes. If {rstpMac,rstpMacVid} exists, the bridge replaces it. The old entry is deleted when PDU with rstpMacStatus=3Dinvalid(2), rstpMac, rstpMacVid comes. The old entry is modified when PDU with rstpMac, rstpMacVid and new value of fields rstpMacPort and/or rstpMacVidx and/or rstpMacMode comes." ::=3D { rstpMacEntry 30 } -- There will be traps END ------=_NextPart_000_002E_01C16602.412758F0 Content-Type: text/plain; name="rstp.txt" Content-Disposition: attachment; filename="rstp.txt" Content-Transfer-Encoding: quoted-printable +--oaBridge(39) | +--rstp(2) | +--rstpGenCfgTable(1) | | | +--rstpGenCfgEntry(1) | + INDEX(0) 'rstpGenCfgStorage' | | | +-- -R-- EnumVal rstpGenCfgStorage(1) | | Textual Convention: StorageType | | Values: run(2), nvram(4), all(6) | +-- -RW- EnumVal rstpGenCfgMode(2) | Values: nonStp(1), slowGlobal(2), | slowPerVlan(3), rapidGlobal(4), | rapidPerVlan(5), rapidMStp(6) | +--rstpMSTiCfgTable(5) | | | +--rstpMSTiCfgEntry(1) | + INDEX(0) 'rstpMSTiCfgStorage' | + INDEX(0) 'rstpMSTiCfgMSTiID' | + INDEX(0) 'rstpMSTiCfgVlanId' | | | +-- -R-- EnumVal rstpMSTiCfgStorage(1) | | Textual Convention: StorageType | | Values: run(2), nvram(4), all(6) | +-- -R-- Integer rstpMSTiCfgMSTiID(2) | | Textual Convention: VlanID | | Range: 0..4095 | +-- -R-- Integer rstpMSTiCfgVlanId(3) | | Textual Convention: VlanID | | Range: 0..4095 | +-- -RW- EnumVal rstpMSTiCfgRowStatus(6) | Textual Convention: RowStatus | Values: active(1), notInService(2), | notReady(3), createAndGo(4), | createAndWait(5), destroy(6) | +--rstpBridgeCfgTable(6) | | | +--rstpBridgeCfgEntry(1) | + INDEX(0) 'rstpBridgeCfgStorage' | + INDEX(0) 'rstpMSTiCfgMSTiID' | | | +-- -R-- EnumVal rstpBridgeCfgStorage(3) | | Textual Convention: StorageType | | Values: run(2), nvram(4), all(6) | +-- -RW- String rstpBridgeCfgName(5) | | Textual Convention: DisplayString | | Size: 0..24 | +-- -RW- Integer rstpBridgeCfgPriority(6) | | Range: 0..65535 | +-- -RW- Integer rstpBridgeCfgMaxAge(10) | | Textual Convention: Timeout | | Range: 600..4000 | +-- -RW- Integer rstpBridgeCfgHelloTime(11) | | Textual Convention: Timeout | | Range: 100..1000 | +-- -RW- Integer rstpBridgeCfgForwardDelay(12) | | Textual Convention: Timeout | | Range: 400..3000 | +-- -RW- EnumVal rstpBridgeCfgForceVersion(13) | | Values: slow(1), rapid(2) | +-- -RW- EnumVal rstpBridgeCfgStatus(20) | Textual Convention: RowStatus | Values: active(1), notInService(2), | notReady(3), createAndGo(4), | createAndWait(5), destroy(6) | +--rstpOperBridgeTable(7) | | | +--rstpOperBridgeEntry(1) | + INDEX(0) 'rstpMSTiCfgMSTiID' | | | +-- -R-- String rstpOperBridgeId(3) | | Textual Convention: BridgeId | | Size: 8 | +-- -R-- String rstpOperBridgeDesignatedRoot(4) | | Textual Convention: BridgeId | | Size: 8 | +-- -R-- Integer rstpOperBridgeRootCost(5) | +-- -R-- Integer rstpOperBridgeRootPort(6) | | Textual Convention: InterfaceIndexOrZero | | Range: 0..2147483647 | +-- -R-- Integer rstpOperBridgeMaxAge(10) | | Textual Convention: Timeout | +-- -R-- Integer rstpOperBridgeHelloTime(12) | | Textual Convention: Timeout | +-- -R-- Integer rstpOperBridgeForwardDelay(13) | | Textual Convention: Timeout | +-- -R-- Integer rstpOperBridgeTopChanges(13) | +-- -R-- TimeTicks rstpOperBridgeTimeSinceTopologyChange(13) | +--rstpPortCfgTable(8) | | | +--rstpPortCfgEntry(1) | + INDEX(0) 'rstpPortCfgStorage' | + INDEX(0) 'rstpMSTiCfgMSTiID' | + INDEX(0) 'rstpPortCfgIndex' | | | +-- -R-- EnumVal rstpPortCfgStorage(3) | | Textual Convention: StorageType | | Values: run(2), nvram(4), all(6) | +-- -R-- Integer rstpPortCfgIndex(5) | | Textual Convention: InterfaceIndex | | Range: 1..2147483647 | +-- -RW- Integer rstpPortCfgPriority(10) | | Range: 0..240 | +-- -RW- Integer rstpPortCfgAdminPathCost(11) | | Range: 0..200000000 | +-- -RW- EnumVal rstpPortCfgAgminPointToPoint(12) | | Values: no(0), yes(1), auto(2) | +-- -RW- EnumVal rstpPortCfgAdminEdge(13) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -RW- EnumVal rstpPortCfgAdminForceVersion(14) | Textual Convention: TruthValue | Values: true(1), false(2) | +--rstpPortOperTable(9) | | | +--rstpPortOperEntry(1) | + INDEX(0) 'rstpMSTiCfgMSTiID' | + INDEX(0) 'rstpPortOperIndex' | | | +-- -R-- Integer rstpPortOperIndex(5) | | Textual Convention: InterfaceIndex | | Range: 1..2147483647 | +-- -R-- EnumVal rstpPortOperRole(8) | | Values: disabled(1), alternate(2), | | backup(3), designated(4), root(5) | +-- -R-- EnumVal rstpPortOperState(9) | | Values: disabled(1), blocking(2), | | listening(3), learning(4), forwarding(5), = broken(6) | +-- -R-- Integer rstpPortOperPathCost(10) | +-- -R-- String rstpPortOperDesignatedRoot(11) | | Textual Convention: BridgeId | | Size: 8 | +-- -R-- Integer rstpPortOperDesignatedCost(12) | +-- -R-- String rstpPortOperDesignatedBridge(13) | | Textual Convention: BridgeId | | Size: 8 | +-- -R-- String rstpPortOperDesignatedPort(16) | | Textual Convention: PortId | | Size: 2 | +-- -R-- EnumVal rstpPortOperPointToPoint(17) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -R-- EnumVal rstpPortOperEdge(18) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -R-- EnumVal rstpPortOperSlowNeighbor(19) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -R-- Counter rstpPortOperRxBpduRstp(24) | +-- -R-- Counter rstpPortOperRxBpduConfig(25) | +-- -R-- Counter rstpPortOperRxBpduTcn(25) | +--rstpMac(12) | +--rstpMacInfo(1) | | | +-- -R-- Integer rstpMacInfoNumber(1) | +-- -R-- Integer rstpMacInfoMaxNumbr(2) | +-- --W- EnumVal rstpMacInfoClear(5) | Values: clear(2) | +--rstpMacTable(2) | +--rstpMacEntry(1) + INDEX(0) 'rstpMacAddr' + INDEX(0) 'rstpMacVid' | +-- -R-- String rstpMacAddr(1) | Textual Convention: MacAddress | Size: 6 +-- -R-- Integer rstpMacVid(2) | Textual Convention: VlanID | Range: 0..4095 +-- -RW- Integer rstpMacVidx(6) | Textual Convention: VlanID | Range: 0..4095 +-- -R-- Integer rstpMacGetViewIndex(8) +-- -RW- Integer rstpMacPort(9) | Textual Convention: InterfaceIndexOrZero | Range: 0..2147483647 +-- -RW- EnumVal rstpMacMode(20) | Values: dynamic(1), static(2) +-- -RW- EnumVal rstpMacTagged(21) | Textual Convention: TruthValue | Values: true(1), false(2) +-- -RW- Integer rstpMacPriority(22) +-- -RW- Integer rstpMacFlags(23) +-- -RW- EnumVal rstpMacStatus(30) Values: valid(1), invalid(2) ------=_NextPart_000_002E_01C16602.412758F0-- _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From daemon@optimus.ietf.org Tue Nov 13 17:09:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18899 for ; Tue, 13 Nov 2001 17:09:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA27785 for bridge-archive@odin.ietf.org; Tue, 13 Nov 2001 17:09:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27774; Tue, 13 Nov 2001 17:09:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27743 for ; Tue, 13 Nov 2001 17:09:43 -0500 (EST) Received: from columba.eur.3com.com (columba.EUR.3Com.COM [161.71.169.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18894 for ; Tue, 13 Nov 2001 17:09:38 -0500 (EST) Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.eur.3com.com with ESMTP id fADMBcp11835; Tue, 13 Nov 2001 22:11:38 GMT Received: from notesmta.eur.3com.com (eurmta2.EUR.3Com.COM [140.204.220.207]) by toucana.eur.3com.com with SMTP id fADM94902521; Tue, 13 Nov 2001 22:09:05 GMT Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256B03.00799D58 ; Tue, 13 Nov 2001 22:08:21 +0000 X-Lotus-FromDomain: 3COM From: "Les Bell" To: Arozin@Opticalaccess.com cc: Bridge-mib@ietf.org, Les_Bell@3com.com, vngai@enterasys.com Message-ID: <80256B03.00799CEE.00@notesmta.eur.3com.com> Date: Tue, 13 Nov 2001 18:46:00 +0000 Subject: Re: [Bridge-mib] (no subject) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org Hi Alex, I am not keen on the use of an extra index level to allow the concept of applying a change in the MIB immediately, or deferring it until after the next system reset. I know that my own implementation does not require this sort of behaviour, and I expect many other vendors implementations would not require this either. I also suspect the customers would not expect to have to reset their Bridges in order to apply a change to their Bridge parameters. I am not yet sure that it is safe to assume we can provide 802.1s Multiple Spanning Tree support by the simple use of an index with the MST Context Identifier to which the configuration is associated. I do not think it would make sense, for example, to define different values for ForwardDelay, ForceVersion, etc., in different MST contexts (the current IEEE 802.1s Draft 10 and Draft 10.1 do not allow this). Similarly, many of the per port parameters (rstpPortOperPointToPoint, rstpPortOperEdge, rstpPortOperSlowNeighbor, rstpPortOperRxBpduRstp, rstpPortOperRxBpduConfig, rstpPortOperRxBpduTcn) will apply to all MST contexts, and should not be indexed by the MSTi. Your MIB includes some objects that are not in IEEE 802.1w clause 14.8 (rstpPortOperRole, rstpPortOperSlowNeighbor, rstpPortOperRxBpduRstp, rstpPortOperRxBpduConfig, rstpPortOperRxBpduTcn). Are these really necessary? Are they useful? RFC 2674 already includes VLAN aware versions of the FDB tables and other VLAN related information. Taking the above points into consideration, I believe it leaves us with what is already in draft-ietf-bridge-rstpmib-00.txt, without the StorageType and MSTi indexes. Is this not sufficient? Les... alexr@nbase.co.il (Alex Ruzin)@ietf.org on 05/11/2001 12:00:40 Please respond to Sent by: bridge-mib-admin@ietf.org To: cc: , Subject: [Bridge-mib] (no subject) Dear Ladies & Gentlemen, First let me introduce myself. I am responsible for SNMP and, occasionally, for Spanning Tree in my company. I had implemented Spanning Tree 802.1d and a Bridge MIB RFC1493. Now I've finished the first step of implementation of Rapid Spanning Tree 802.1w (it is under alpha testing now). This implementation, among other, supports a possibility to create one STP instance per VLAN (I know, it is not 802.1s compatible, it will be a next step). In a parallel way I am designing our private MIB for SNMP support for these features. In this message I am attaching it: may be ( and I will consider it as a great honor for myself) some ideas from it will be useful for you in your work under draft-ietf-bridge-rstpmib-00.txt Would you like to send your comments and remarks, I'll accept them with great gratitude. The attached files are: RSTP.mib - the MIB draft rstp.txt the brief structure of MIB, as it is presented by snmptranslate utility of NET-SNMP. Now please allow me to make some comments. . 1. For many reasons it is convenient to have a possibility to configure an device for operation after nearest reset. For STP this possibility has a special importance, while a non-atomic setting of parameters may follow drastic and unwanted changes in the network. So, the configuration that will be applied after nearest reset we call 'NVRAM-configuration'. The configuration of the *operating now* device is called 'RUN configuration'. For this concept reflection we use an TEXTUAL-CONVENTION named "StorageType". All writeble tables are indexed with an object of this type. Sure, the alternative is to organize two separate tables: one for run and one for NVRAM. I have to point, that our old MIBs have been organized in such way. 2. For the same reason all objects are separated onto writeble and readable-only tables. Sure (and it is a purpose), the latter type of tables are not indexed with object of StorageType type. More of that, we consider such division as a method to make a MIB more understandable by network managers. 3. We inserted in the MIB so called rstpMSTiCfgTable as a preparation for MSTP support. Now it allows us to support RSTP instances per VLAN. 4. In RFC1493 the dot1dTpFdbTable is indexed only by dot1dTpFdbAddress. It doesn't allow to support 802.1q tagged properties of the Bridge may be I missed the new bridge MIB editions) . Our rstpMacTable is indexed by both rstpMacAddr and rstpMacVid (the latter one may be equal to 0 in the untagged case) Thank you for your tolerance & patience. I look forward to working with you in the cooperation, while as far as I see private MIBs design is the evil, and we have to avoid it as strong as possible. Best regards, Alex Rozin ============ Optical Access Ltd. P.O. Box 114 Yokneam 20692, ISRAEL Home : http://www.opticalaccess.com - RSTP.mib - rstp.txt _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From daemon@optimus.ietf.org Tue Nov 13 17:46:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20162 for ; Tue, 13 Nov 2001 17:46:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA28632 for bridge-archive@odin.ietf.org; Tue, 13 Nov 2001 17:46:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28618; Tue, 13 Nov 2001 17:46:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28590 for ; Tue, 13 Nov 2001 17:46:29 -0500 (EST) Received: from windlord.worldwidepackets.com (mail.worldwidepackets.com [12.46.89.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20157 for ; Tue, 13 Nov 2001 17:46:21 -0500 (EST) Received: by worldwidepackets.com with Internet Mail Service (5.5.2653.19) id <4PQV6YHL>; Tue, 13 Nov 2001 14:46:23 -0800 Message-ID: From: Rohit Rohit To: "'Les Bell'" , Arozin@Opticalaccess.com Cc: Bridge-mib@ietf.org, Les_Bell@3com.com, vngai@enterasys.com Subject: FW: [Bridge-mib] Outstanding RSTP-MIB issues Date: Tue, 13 Nov 2001 14:46:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org Hi Less, I didn't get the reply for this mail earlier. Trying it again. Thanks Rohit -----Original Message----- From: Rohit Rohit Sent: Tuesday, October 09, 2001 9:33 AM To: 'Les Bell'; bridge-mib@ietf.org Subject: RE: [Bridge-mib] Outstanding RSTP-MIB issues Hi, I am not sure whether the presentation discussed the dot1dStpHoldTime issue for RSTP or not. We have holdCount for the rstp and which is not same as dot1dStpHoldTime for stp. So are we going to have a new object for the rstpHoldCount ? If yes, then what should be the value of dot1dStpHoldTime for the rstp bridges. Thanks Rohit -----Original Message----- From: Les Bell [mailto:Les_Bell@eur.3com.com] Sent: Tuesday, October 09, 2001 6:29 AM To: bridge-mib@ietf.org Subject: [Bridge-mib] Outstanding RSTP-MIB issues Here is a summary of the outstanding issues on the RSTP-MIB, U-BRIDGE-MIB and V-BRIDGE-MIB in draft-ietf-bridge-rstpmib-00.txt I would like to solicit more input from people to try and close these issues and get an updated draft out before the December IETF. (1) Some missing items were identified (see the presentation). STATUS: Should add these to the new draft mib. COMMENTS: No comments from the mailing list. PROPOSED ACTION: Add the missing items. (2) The U-BRIDGE-MIB and V-BRIDGE-MIB should probably be done as updates to RFC 2674. STATUS: No feedback received yet. COMMENTS: No comments from the mailing list. PROPOSED ACTION: Requires further input from the mailing list. Les... _______________________________________________ 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 daemon@optimus.ietf.org Wed Nov 14 01:55:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06090 for ; Wed, 14 Nov 2001 01:55:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA14858 for bridge-archive@odin.ietf.org; Wed, 14 Nov 2001 01:55:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA14843; Wed, 14 Nov 2001 01:54:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA14814 for ; Wed, 14 Nov 2001 01:54:32 -0500 (EST) Received: from MAILGW ([194.90.137.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05980 for ; Wed, 14 Nov 2001 01:54:28 -0500 (EST) Received: from apollo.nbase.co.il ([194.90.137.2]) by MAILGW (MailGuardian SMTP Relay 1.2.1) with SMTP ID Mail1005727981527-98; Wed, 14 Nov 2001 10:53:01 +0200 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 AAA389; Wed, 14 Nov 2001 08:55:15 +0200 Reply-To: From: alexr@nbase.co.il (Alex Ruzin) To: "'Les Bell'" Cc: , Subject: RE: [Bridge-mib] Private RSTP MIB Date: Wed, 14 Nov 2001 08:54:28 +0200 Message-ID: <001d01c16cd9$34e37730$87885ac2@Alexr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <80256B03.00799CEE.00@notesmta.eur.3com.com> Content-Transfer-Encoding: 7bit Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org Content-Transfer-Encoding: 7bit On Tuesday, November 13, 2001 8:46 PM Les Bell wrote: [snip] > Taking the above points into consideration, I believe it > leaves us with what is > already in draft-ietf-bridge-rstpmib-00.txt, without the > Storage Type and MSTi > indexes. Is this not sufficient? Yes, thank you for the analysis, and I agree with all these points. Only one point: it seems to me, that the objects rstpPortOperRole, rstpPortOperSlowNeighbor, rstpPortOperRxBpduRstp, rstpPortOperRxBpduConfig, rstpPortOperRxBpduTcn may be really useful. for a manager and may be inserted in clause 14.8 or 802.1w Best regards, Alex Rozin _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From daemon@optimus.ietf.org Wed Nov 14 09:32:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24522 for ; Wed, 14 Nov 2001 09:32:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA25321 for bridge-archive@odin.ietf.org; Wed, 14 Nov 2001 09:32:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25310; Wed, 14 Nov 2001 09:32:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25277 for ; Wed, 14 Nov 2001 09:32:35 -0500 (EST) Received: from MAILGW ([194.90.137.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24516 for ; Wed, 14 Nov 2001 09:32:29 -0500 (EST) Received: from apollo.nbase.co.il ([194.90.137.2]) by MAILGW (MailGuardian SMTP Relay 1.2.1) with SMTP ID Mail1005755464054-84; Wed, 14 Nov 2001 18:31:04 +0200 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 AAA385; Wed, 14 Nov 2001 16:33:18 +0200 Reply-To: From: alexr@nbase.co.il (Alex Ruzin) To: , , Date: Wed, 14 Nov 2001 16:32:30 +0200 Message-ID: <002201c16d19$31cb1f90$87885ac2@Alexr> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] RE: Open Source 802.1w Library & Simulator Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org Content-Transfer-Encoding: 7bit The new release of has been committed today. (see https://sourceforge.net/projects/rstplib/) The changes are: - All per Port variables have been moved from the State Machines into the Port instance (it made the state machines much more clear) - In libcli.a instead of stupid fgets() function we use now readline (thanks to Michael Roshavsky) - 'mcheck' support - 'nonStp' support (I know, that it is out the standard, but it seems to be useful (see a discussion on http://www1.ietf.org/mail-archive/working-groups/bridge/current/msg00038.htm l) and our customers demand it - The function rolesel.c has been drastically fixed, IMHO closer to the standard - Nicer output You are welcome to download & enjoy Rest regards, Alex _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From daemon@optimus.ietf.org Wed Nov 14 12:14:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04611 for ; Wed, 14 Nov 2001 12:14:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA02751 for bridge-archive@odin.ietf.org; Wed, 14 Nov 2001 12:14:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02570; Wed, 14 Nov 2001 12:10:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02538 for ; Wed, 14 Nov 2001 12:10:33 -0500 (EST) Received: from columba.eur.3com.com (columba.EUR.3Com.COM [161.71.169.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04419 for ; Wed, 14 Nov 2001 12:10:28 -0500 (EST) Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.eur.3com.com with ESMTP id fAEHBjn04289; Wed, 14 Nov 2001 17:11:45 GMT Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id fAEH9A925060; Wed, 14 Nov 2001 17:09:10 GMT Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256B04.005EF9C8 ; Wed, 14 Nov 2001 17:17:23 +0000 X-Lotus-FromDomain: 3COM From: "Les Bell" To: Rohit Rohit cc: Arozin@Opticalaccess.com, Bridge-mib@ietf.org, vngai@enterasys.com Message-ID: <80256B04.005E30C9.00@notesmta.eur.3com.com> Date: Tue, 13 Nov 2001 23:31:00 +0000 Subject: Re: FW: [Bridge-mib] Outstanding RSTP-MIB issues Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org Sorry, I forgot to respond to this email previously. The TxHoldCount is not configurable according to 802.1w, so I did not think it was necessary to include it in the MIB. Table 8-3 and Table 17-5 of 802.1w do not indicate a valid range for the TxHoldCount value, just defining the default value of 3. 802.1w 14.8.1.2 Set Bridge Protocol parameters does not include TxHoldCount in the list of input parameters. I shall raise this issue on the IEEE 802.1 WG email list, to see if we can get their views on whether this was the intention, or if TxHoldCount should really be configurable. Les... Rohit Rohit on 13/11/2001 22:46:18 Sent by: Rohit Rohit To: "'Les Bell'" , Arozin@Opticalaccess.com cc: Bridge-mib@ietf.org, Les_Bell@3com.com, vngai@enterasys.com Subject: FW: [Bridge-mib] Outstanding RSTP-MIB issues Hi Less, I didn't get the reply for this mail earlier. Trying it again. Thanks Rohit -----Original Message----- From: Rohit Rohit Sent: Tuesday, October 09, 2001 9:33 AM To: 'Les Bell'; bridge-mib@ietf.org Subject: RE: [Bridge-mib] Outstanding RSTP-MIB issues Hi, I am not sure whether the presentation discussed the dot1dStpHoldTime issue for RSTP or not. We have holdCount for the rstp and which is not same as dot1dStpHoldTime for stp. So are we going to have a new object for the rstpHoldCount ? If yes, then what should be the value of dot1dStpHoldTime for the rstp bridges. Thanks Rohit -----Original Message----- From: Les Bell [mailto:Les_Bell@eur.3com.com] Sent: Tuesday, October 09, 2001 6:29 AM To: bridge-mib@ietf.org Subject: [Bridge-mib] Outstanding RSTP-MIB issues Here is a summary of the outstanding issues on the RSTP-MIB, U-BRIDGE-MIB and V-BRIDGE-MIB in draft-ietf-bridge-rstpmib-00.txt I would like to solicit more input from people to try and close these issues and get an updated draft out before the December IETF. (1) Some missing items were identified (see the presentation). STATUS: Should add these to the new draft mib. COMMENTS: No comments from the mailing list. PROPOSED ACTION: Add the missing items. (2) The U-BRIDGE-MIB and V-BRIDGE-MIB should probably be done as updates to RFC 2674. STATUS: No feedback received yet. COMMENTS: No comments from the mailing list. PROPOSED ACTION: Requires further input from the mailing list. Les... _______________________________________________ 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 daemon@ns.ietf.org Wed Nov 14 19:49:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22852 for ; Wed, 14 Nov 2001 19:49:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA17502 for bridge-archive@odin.ietf.org; Wed, 14 Nov 2001 19:49:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17489; Wed, 14 Nov 2001 19:49:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17458 for ; Wed, 14 Nov 2001 19:49:47 -0500 (EST) Received: from columba.eur.3com.com (columba.EUR.3Com.COM [161.71.169.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22847 for ; Wed, 14 Nov 2001 19:49:42 -0500 (EST) Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.eur.3com.com with ESMTP id fAF0pen03723; Thu, 15 Nov 2001 00:51:40 GMT Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id fAF0n6924384; Thu, 15 Nov 2001 00:49:07 GMT Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256B05.00054A8A ; Thu, 15 Nov 2001 00:57:47 +0000 X-Lotus-FromDomain: 3COM From: "Les Bell" To: Rohit Rohit cc: Arozin@Opticalaccess.com, Bridge-mib@ietf.org, vngai@enterasys.com Message-ID: <80256B05.000548BD.00@notesmta.eur.3com.com> Date: Wed, 14 Nov 2001 23:45:47 +0000 Subject: Re: FW: [Bridge-mib] Outstanding RSTP-MIB issues Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org This was discussed at the IEEE 802.1 WG meeting today. It was agreed that the TxHoldCount value should be configurable, with a range of 1 - 10. This correction will be added to IEEE 802.1y, the maintenance document for IEEE 802.1D/w issues. Therefore, we should add this as a new item to the RSTP MIB. Les... __________________________________ Sorry, I forgot to respond to this email previously. The TxHoldCount is not configurable according to 802.1w, so I did not think it was necessary to include it in the MIB. Table 8-3 and Table 17-5 of 802.1w do not indicate a valid range for the TxHoldCount value, just defining the default value of 3. 802.1w 14.8.1.2 Set Bridge Protocol parameters does not include TxHoldCount in the list of input parameters. I shall raise this issue on the IEEE 802.1 WG email list, to see if we can get their views on whether this was the intention, or if TxHoldCount should really be configurable. Les... Rohit Rohit on 13/11/2001 22:46:18 Sent by: Rohit Rohit To: "'Les Bell'" , Arozin@Opticalaccess.com cc: Bridge-mib@ietf.org, Les_Bell@3com.com, vngai@enterasys.com Subject: FW: [Bridge-mib] Outstanding RSTP-MIB issues Hi Less, I didn't get the reply for this mail earlier. Trying it again. Thanks Rohit -----Original Message----- From: Rohit Rohit Sent: Tuesday, October 09, 2001 9:33 AM To: 'Les Bell'; bridge-mib@ietf.org Subject: RE: [Bridge-mib] Outstanding RSTP-MIB issues Hi, I am not sure whether the presentation discussed the dot1dStpHoldTime issue for RSTP or not. We have holdCount for the rstp and which is not same as dot1dStpHoldTime for stp. So are we going to have a new object for the rstpHoldCount ? If yes, then what should be the value of dot1dStpHoldTime for the rstp bridges. Thanks Rohit -----Original Message----- From: Les Bell [mailto:Les_Bell@eur.3com.com] Sent: Tuesday, October 09, 2001 6:29 AM To: bridge-mib@ietf.org Subject: [Bridge-mib] Outstanding RSTP-MIB issues Here is a summary of the outstanding issues on the RSTP-MIB, U-BRIDGE-MIB and V-BRIDGE-MIB in draft-ietf-bridge-rstpmib-00.txt I would like to solicit more input from people to try and close these issues and get an updated draft out before the December IETF. (1) Some missing items were identified (see the presentation). STATUS: Should add these to the new draft mib. COMMENTS: No comments from the mailing list. PROPOSED ACTION: Add the missing items. (2) The U-BRIDGE-MIB and V-BRIDGE-MIB should probably be done as updates to RFC 2674. STATUS: No feedback received yet. COMMENTS: No comments from the mailing list. PROPOSED ACTION: Requires further input from the mailing list. Les... _______________________________________________ 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 daemon@ns.ietf.org Thu Nov 15 12:48:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07425 for ; Thu, 15 Nov 2001 12:48:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29080 for bridge-archive@odin.ietf.org; Thu, 15 Nov 2001 12:48:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29069; Thu, 15 Nov 2001 12:48:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29038 for ; Thu, 15 Nov 2001 12:48:31 -0500 (EST) Received: from windlord.worldwidepackets.com (mail.worldwidepackets.com [12.46.89.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07400 for ; Thu, 15 Nov 2001 12:48:28 -0500 (EST) Received: by worldwidepackets.com with Internet Mail Service (5.5.2653.19) id <4PQV670C>; Thu, 15 Nov 2001 09:48:29 -0800 Message-ID: From: Rohit Rohit To: "'Les Bell'" , Rohit Rohit Cc: Arozin@Opticalaccess.com, Bridge-mib@ietf.org, vngai@enterasys.com Subject: RE: FW: [Bridge-mib] Outstanding RSTP-MIB issues Date: Thu, 15 Nov 2001 09:48:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org Hi Les, Thanks for your reply. IMHO we have two options 1) add the new object and say that dot1dStpHoldTime doesn't make sense for the RSTP. 2) For RSTP dot1dStpHoldTime should be treated as TxHoldCount with a different range. I prefer to go with the second option. Thanks Rohit -----Original Message----- From: Les Bell [mailto:Les_Bell@eur.3com.com] Sent: Wednesday, November 14, 2001 3:46 PM To: Rohit Rohit Cc: Arozin@Opticalaccess.com; Bridge-mib@ietf.org; vngai@enterasys.com Subject: Re: FW: [Bridge-mib] Outstanding RSTP-MIB issues This was discussed at the IEEE 802.1 WG meeting today. It was agreed that the TxHoldCount value should be configurable, with a range of 1 - 10. This correction will be added to IEEE 802.1y, the maintenance document for IEEE 802.1D/w issues. Therefore, we should add this as a new item to the RSTP MIB. Les... __________________________________ Sorry, I forgot to respond to this email previously. The TxHoldCount is not configurable according to 802.1w, so I did not think it was necessary to include it in the MIB. Table 8-3 and Table 17-5 of 802.1w do not indicate a valid range for the TxHoldCount value, just defining the default value of 3. 802.1w 14.8.1.2 Set Bridge Protocol parameters does not include TxHoldCount in the list of input parameters. I shall raise this issue on the IEEE 802.1 WG email list, to see if we can get their views on whether this was the intention, or if TxHoldCount should really be configurable. Les... Rohit Rohit on 13/11/2001 22:46:18 Sent by: Rohit Rohit To: "'Les Bell'" , Arozin@Opticalaccess.com cc: Bridge-mib@ietf.org, Les_Bell@3com.com, vngai@enterasys.com Subject: FW: [Bridge-mib] Outstanding RSTP-MIB issues Hi Less, I didn't get the reply for this mail earlier. Trying it again. Thanks Rohit -----Original Message----- From: Rohit Rohit Sent: Tuesday, October 09, 2001 9:33 AM To: 'Les Bell'; bridge-mib@ietf.org Subject: RE: [Bridge-mib] Outstanding RSTP-MIB issues Hi, I am not sure whether the presentation discussed the dot1dStpHoldTime issue for RSTP or not. We have holdCount for the rstp and which is not same as dot1dStpHoldTime for stp. So are we going to have a new object for the rstpHoldCount ? If yes, then what should be the value of dot1dStpHoldTime for the rstp bridges. Thanks Rohit -----Original Message----- From: Les Bell [mailto:Les_Bell@eur.3com.com] Sent: Tuesday, October 09, 2001 6:29 AM To: bridge-mib@ietf.org Subject: [Bridge-mib] Outstanding RSTP-MIB issues Here is a summary of the outstanding issues on the RSTP-MIB, U-BRIDGE-MIB and V-BRIDGE-MIB in draft-ietf-bridge-rstpmib-00.txt I would like to solicit more input from people to try and close these issues and get an updated draft out before the December IETF. (1) Some missing items were identified (see the presentation). STATUS: Should add these to the new draft mib. COMMENTS: No comments from the mailing list. PROPOSED ACTION: Add the missing items. (2) The U-BRIDGE-MIB and V-BRIDGE-MIB should probably be done as updates to RFC 2674. STATUS: No feedback received yet. COMMENTS: No comments from the mailing list. PROPOSED ACTION: Requires further input from the mailing list. Les... _______________________________________________ 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 financialsuccess1@mediaone.net Fri Nov 16 02:53:33 2001 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23905 for ; Fri, 16 Nov 2001 02:53:33 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fAG7FZH23646 for ; Thu, 15 Nov 2001 23:15:35 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id fAG7FZr07714 for ; Thu, 15 Nov 2001 23:15:35 -0800 (PST) Received: from ntserver.oknp.com ([210.219.225.130]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id fAG7GMl01881 for ; Thu, 15 Nov 2001 23:16:22 -0800 (PST) Received: from html (unverified [65.138.115.141]) by ntserver.oknp.com (Rockliffe SMTPRA 4.5.6) with SMTP id ; Fri, 16 Nov 2001 16:18:41 +0900 Message-ID: From: bridge-of-dreams@hotmail.com Reply-To: financialsuccess1@mediaone.net To: bridge-of-dreams@hotmail.com Subject: GUARANTEED ways to have a better HOLIDAY SEASON!! Time:11:15:25 PM Date: Wed, 14 Nov 2001 23:15:25 Mime-Version: 1.0 Content-Type: text/html; charset="DEFAULT_CHARSET" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Dear bridge1983
Visit the only website with  tools proven and guaranteed to help you profit, make money and
give you the advantage in any economic time! Click Here

Featuring:
Credit repair
New Credit Files
Grants and Free Money
Business Opportunities
No money down Real Estate
 
From daemon@ns.ietf.org Tue Nov 20 09:08:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09516 for ; Tue, 20 Nov 2001 09:08:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA18371 for bridge-archive@odin.ietf.org; Tue, 20 Nov 2001 09:08:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18360; Tue, 20 Nov 2001 09:08:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18329 for ; Tue, 20 Nov 2001 09:08:15 -0500 (EST) Received: from apollo.nbase.co.il (apollo.nbase.co.il [194.90.137.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09499 for ; Tue, 20 Nov 2001 09:08:11 -0500 (EST) 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 AAA393; Tue, 20 Nov 2001 16:08:59 +0200 Reply-To: From: alexr@nbase.co.il (Alex Ruzin) To: , , Date: Tue, 20 Nov 2001 16:09:00 +0200 Message-ID: <000d01c171cc$e7f0a760$87885ac2@Alexr> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] Question: indirect link fail in 802.1w Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org Content-Transfer-Encoding: 7bit Question: indirect link fail in 802.1w Initial configuration:3 Bridges (A, B, C) are connected as a triangle. Let's say, Bridge A is a Root Bridge and has 2 designated ports A1 and A2. Bridge B has root port B1 (connected with port A1) and designated port B2, connected with port C2. Bridge C has root port C1 (connected with port A2) and Alternate port C2 (connected with port B2). Now the link between B1 and A1 fails :( Bridge B immediately detects the failure and assumes it is Root Bridge ( while it doesn't have any Alternate port) and starts to advertise via port B2 its own Priority Vector. The problem is on the Bridge C. It receives on Alternate port C2 SuperiorDesignate Msg BPDU. It is because 17.19.8:"Designated Bridge and Designated Port components of the received message priority vector are the same as those of the port priority vector and the message priority vector as a whole or any of the received timer parameter values (msgTimes -see 17.18.12) differ from those already held in port-Times (17.18.18). As a result port C2 goes to have Backup role. Then, switch B continues to send its BPDU, but for C these BPDU are "Inferior" or, in terms of PIM, the function rcbBpdu returns OtherMsg. This messages are discarded by PIM and there are 3 such messages (6 seconds !). Only after that the rcvdInfoWhile timer expires, port C2 is aged, becomes Designated, makes 'handshake' with port B2 (which becomes Root for the bridge B), and everything is OK. During about 6 seconds LAN, connected to C was disconnected from LAN, connected to B ! (Yes, I know, that in legacy STP such situation causes a delay 50 seconds: MaxAge + 2 * ForwardDelay). IMHO, there may take place an optimization, The idea: don't discard BPDU when 'OtherMsg', but to start some "upstream' handshake (in addition to RSTP 'downstream' handshake for rapid transition Designating port to Forwarding state). Such 'upstream' handshake may be started, when SuperiorDesignate message was recognized by another Times and message Priority Vector is worse than a stored one. This idea is similar to "Spanning-Tree Protocol's Backbone Fast Feature" of CISCO (see http://www.cisco.com/warp/public/473/18.html) What do you think about it ? Does this idea break the concept of 802.1w ? Is it in the plans of the society ? What if I start to design such 'handshake' ? Best regards, Alex _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From daemon@optimus.ietf.org Tue Nov 20 22:30:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16340 for ; Tue, 20 Nov 2001 22:30:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA13829 for bridge-archive@odin.ietf.org; Tue, 20 Nov 2001 22:30:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13754; Tue, 20 Nov 2001 22:30:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10979 for ; Tue, 20 Nov 2001 20:11:03 -0500 (EST) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13378 for ; Tue, 20 Nov 2001 20:10:59 -0500 (EST) Received: from user-2ivfiiv.dialup.mindspring.com ([165.247.202.95] helo=MICKHOME) by smtp10.atl.mindspring.net with smtp (Exim 3.33 #1) id 166LuV-00044H-00; Tue, 20 Nov 2001 20:10:44 -0500 Reply-To: From: "Mick Seaman" To: , , , Date: Tue, 20 Nov 2001 17:13:33 -0800 Message-ID: <000401c17229$bd383e90$0100007f@corp.telseon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <000d01c171cc$e7f0a760$87885ac2@Alexr> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] RE: Question: indirect link fail in 802.1w Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org Content-Transfer-Encoding: 7bit Alex, I suggest you test this out using the RSTP Visio simulation. The only case in which any of these ports could be Backup is a deficiency in the spec or the interpretation of the spec, so extra protocol is not required. Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Alex Ruzin Sent: Tuesday, November 20, 2001 6:09 AM To: stds-802-1@ieee.org; rstplib-users@lists.sourceforge.net; bridge-mib@ietf.org Subject: Question: indirect link fail in 802.1w Question: indirect link fail in 802.1w Initial configuration:3 Bridges (A, B, C) are connected as a triangle. Let's say, Bridge A is a Root Bridge and has 2 designated ports A1 and A2. Bridge B has root port B1 (connected with port A1) and designated port B2, connected with port C2. Bridge C has root port C1 (connected with port A2) and Alternate port C2 (connected with port B2). Now the link between B1 and A1 fails :( Bridge B immediately detects the failure and assumes it is Root Bridge ( while it doesn't have any Alternate port) and starts to advertise via port B2 its own Priority Vector. The problem is on the Bridge C. It receives on Alternate port C2 SuperiorDesignate Msg BPDU. It is because 17.19.8:"Designated Bridge and Designated Port components of the received message priority vector are the same as those of the port priority vector and the message priority vector as a whole or any of the received timer parameter values (msgTimes -see 17.18.12) differ from those already held in port-Times (17.18.18). As a result port C2 goes to have Backup role. Then, switch B continues to send its BPDU, but for C these BPDU are "Inferior" or, in terms of PIM, the function rcbBpdu returns OtherMsg. This messages are discarded by PIM and there are 3 such messages (6 seconds !). Only after that the rcvdInfoWhile timer expires, port C2 is aged, becomes Designated, makes 'handshake' with port B2 (which becomes Root for the bridge B), and everything is OK. During about 6 seconds LAN, connected to C was disconnected from LAN, connected to B ! (Yes, I know, that in legacy STP such situation causes a delay 50 seconds: MaxAge + 2 * ForwardDelay). IMHO, there may take place an optimization, The idea: don't discard BPDU when 'OtherMsg', but to start some "upstream' handshake (in addition to RSTP 'downstream' handshake for rapid transition Designating port to Forwarding state). Such 'upstream' handshake may be started, when SuperiorDesignate message was recognized by another Times and message Priority Vector is worse than a stored one. This idea is similar to "Spanning-Tree Protocol's Backbone Fast Feature" of CISCO (see http://www.cisco.com/warp/public/473/18.html) What do you think about it ? Does this idea break the concept of 802.1w ? Is it in the plans of the society ? What if I start to design such 'handshake' ? Best regards, Alex _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From daemon@optimus.ietf.org Tue Nov 20 22:30:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16423 for ; Tue, 20 Nov 2001 22:30:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA13945 for bridge-archive@odin.ietf.org; Tue, 20 Nov 2001 22:30:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13922; Tue, 20 Nov 2001 22:30:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA12232 for ; Tue, 20 Nov 2001 21:03:27 -0500 (EST) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14390 for ; Tue, 20 Nov 2001 21:03:23 -0500 (EST) Received: from user-2ivfiiv.dialup.mindspring.com ([165.247.202.95] helo=MICKHOME) by smtp10.atl.mindspring.net with smtp (Exim 3.33 #1) id 166MjQ-0001ib-00; Tue, 20 Nov 2001 21:03:21 -0500 Reply-To: From: "Mick Seaman" To: "'Mick Seaman'" , , , , Date: Tue, 20 Nov 2001 18:06:10 -0800 Message-ID: <000501c17231$176a7020$0100007f@corp.telseon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] RE: Question: indirect link fail in 802.1w Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org Content-Transfer-Encoding: 7bit This certainly works (subject to accuracies of representation in the spec of what "this" is) without such a handshake (see you closing statement below), and as the handshake is critically timer dependent it is against the spirit of .1w. I was aware of the handshake mechanism well before deisgning .1w. Mick -----Original Message----- From: Mick Seaman [mailto:mick_seaman@ieee.org] Sent: Tuesday, November 20, 2001 5:14 PM To: 'Arozin@opticalaccess.com'; 'stds-802-1@ieee.org'; 'rstplib-users@lists.sourceforge.net'; 'bridge-mib@ietf.org' Subject: RE: Question: indirect link fail in 802.1w Alex, I suggest you test this out using the RSTP Visio simulation. The only case in which any of these ports could be Backup is a deficiency in the spec or the interpretation of the spec, so extra protocol is not required. Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Alex Ruzin Sent: Tuesday, November 20, 2001 6:09 AM To: stds-802-1@ieee.org; rstplib-users@lists.sourceforge.net; bridge-mib@ietf.org Subject: Question: indirect link fail in 802.1w Question: indirect link fail in 802.1w Initial configuration:3 Bridges (A, B, C) are connected as a triangle. Let's say, Bridge A is a Root Bridge and has 2 designated ports A1 and A2. Bridge B has root port B1 (connected with port A1) and designated port B2, connected with port C2. Bridge C has root port C1 (connected with port A2) and Alternate port C2 (connected with port B2). Now the link between B1 and A1 fails :( Bridge B immediately detects the failure and assumes it is Root Bridge ( while it doesn't have any Alternate port) and starts to advertise via port B2 its own Priority Vector. The problem is on the Bridge C. It receives on Alternate port C2 SuperiorDesignate Msg BPDU. It is because 17.19.8:"Designated Bridge and Designated Port components of the received message priority vector are the same as those of the port priority vector and the message priority vector as a whole or any of the received timer parameter values (msgTimes -see 17.18.12) differ from those already held in port-Times (17.18.18). As a result port C2 goes to have Backup role. Then, switch B continues to send its BPDU, but for C these BPDU are "Inferior" or, in terms of PIM, the function rcbBpdu returns OtherMsg. This messages are discarded by PIM and there are 3 such messages (6 seconds !). Only after that the rcvdInfoWhile timer expires, port C2 is aged, becomes Designated, makes 'handshake' with port B2 (which becomes Root for the bridge B), and everything is OK. During about 6 seconds LAN, connected to C was disconnected from LAN, connected to B ! (Yes, I know, that in legacy STP such situation causes a delay 50 seconds: MaxAge + 2 * ForwardDelay). IMHO, there may take place an optimization, The idea: don't discard BPDU when 'OtherMsg', but to start some "upstream' handshake (in addition to RSTP 'downstream' handshake for rapid transition Designating port to Forwarding state). Such 'upstream' handshake may be started, when SuperiorDesignate message was recognized by another Times and message Priority Vector is worse than a stored one. This idea is similar to "Spanning-Tree Protocol's Backbone Fast Feature" of CISCO (see http://www.cisco.com/warp/public/473/18.html) What do you think about it ? Does this idea break the concept of 802.1w ? Is it in the plans of the society ? What if I start to design such 'handshake' ? Best regards, Alex _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From daemon@optimus.ietf.org Wed Nov 21 01:19:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21007 for ; Wed, 21 Nov 2001 01:19:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA25382 for bridge-archive@odin.ietf.org; Wed, 21 Nov 2001 01:19:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25368; Wed, 21 Nov 2001 01:19:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25335 for ; Wed, 21 Nov 2001 01:19:35 -0500 (EST) Received: from apollo.nbase.co.il (apollo.nbase.co.il [194.90.137.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20986 for ; Wed, 21 Nov 2001 01:19:33 -0500 (EST) 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 AAA444; Wed, 21 Nov 2001 08:20:19 +0200 Reply-To: From: alexr@nbase.co.il (Alex Ruzin) To: , , , Date: Wed, 21 Nov 2001 08:20:30 +0200 Message-ID: <000401c17254$9ee80670$87885ac2@Alexr> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit 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 V5.50.4133.2400 Importance: Normal In-Reply-To: <000401c17229$bd383e90$0100007f@corp.telseon.com> Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] RE: Question: indirect link fail in 802.1w Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org Content-Transfer-Encoding: 7bit Mick, The problem is not in hop to the Backup role, but in "late" hop to Designated role: only when rcvdInfoWhile timer expires, while we discard information, that may help in it. I again ask to read http://www.cisco.com/warp/public/473/18.html, where the explanation (for 1d) is more detail and clear. Thanks for the cooperation, Alex > -----Original Message----- > From: Mick Seaman [mailto:mick_seaman@ieee.org] > Sent: Wednesday, November 21, 2001 3:14 AM > To: Arozin@opticalaccess.com; stds-802-1@ieee.org; > rstplib-users@lists.sourceforge.net; bridge-mib@ietf.org > Subject: RE: Question: indirect link fail in 802.1w > > > Alex, > > I suggest you test this out using the RSTP Visio simulation. > > The only case in which any of these ports could be Backup is > a deficiency in > the spec or the interpretation of the spec, so extra protocol is not > required. > > Mick > > -----Original Message----- > From: owner-stds-802-1@majordomo.ieee.org > [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Alex Ruzin > Sent: Tuesday, November 20, 2001 6:09 AM > To: stds-802-1@ieee.org; rstplib-users@lists.sourceforge.net; > bridge-mib@ietf.org > Subject: Question: indirect link fail in 802.1w > > > > > Question: indirect link fail in 802.1w > > Initial configuration:3 Bridges (A, B, C) are > connected as a triangle. > Let's say, Bridge A is a Root Bridge and has > 2 designated ports A1 and A2. > Bridge B has root port B1 (connected with port > A1) and designated port B2, connected with > port C2. Bridge C has root port C1 (connected > with port A2) and Alternate port C2 (connected > with port B2). > > Now the link between B1 and A1 fails :( > Bridge B immediately detects the failure and > assumes it is Root Bridge ( while it doesn't > have any Alternate port) and starts to advertise > via port B2 its own Priority Vector. > > The problem is on the Bridge C. It receives on > Alternate port C2 SuperiorDesignate Msg BPDU. > It is because 17.19.8:"Designated Bridge and > Designated Port components of the received message > priority vector are the same as those of the port > priority vector and the message priority vector as > a whole or any of the received timer parameter > values (msgTimes -see 17.18.12) differ from > those already held in port-Times (17.18.18). > > As a result port C2 goes to have Backup role. > > Then, switch B continues to send its BPDU, but > for C these BPDU are "Inferior" or, in terms of > PIM, the function rcbBpdu returns OtherMsg. This > messages are discarded by PIM and there are 3 > such messages (6 seconds !). > > Only after that the rcvdInfoWhile timer expires, > port C2 is aged, becomes Designated, makes > 'handshake' with port B2 (which becomes Root for > the bridge B), and everything is OK. > > During about 6 seconds LAN, connected to C was > disconnected from LAN, connected to B ! (Yes, I > know, that in legacy STP such situation causes > a delay 50 seconds: MaxAge + 2 * ForwardDelay). > > IMHO, there may take place an optimization, The > idea: don't discard BPDU when 'OtherMsg', but > to start some "upstream' handshake (in addition > to RSTP 'downstream' handshake for rapid > transition Designating port to Forwarding state). > Such 'upstream' handshake may be started, when > SuperiorDesignate message was recognized by > another Times and message Priority Vector is worse > than a stored one. > > This idea is similar to "Spanning-Tree Protocol's > Backbone Fast Feature" of CISCO > (see http://www.cisco.com/warp/public/473/18.html) > > What do you think about it ? Does this idea break > the concept of 802.1w ? Is it in the plans of the > society ? > What if I start to design such 'handshake' ? > > Best regards, Alex > > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From daemon@optimus.ietf.org Wed Nov 21 01:52:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25645 for ; Wed, 21 Nov 2001 01:52:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA26207 for bridge-archive@odin.ietf.org; Wed, 21 Nov 2001 01:52:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26196; Wed, 21 Nov 2001 01:52:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26161 for ; Wed, 21 Nov 2001 01:52:49 -0500 (EST) Received: from apollo.nbase.co.il (apollo.nbase.co.il [194.90.137.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25623 for ; Wed, 21 Nov 2001 01:52:48 -0500 (EST) 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 AAA462; Wed, 21 Nov 2001 08:53:33 +0200 Reply-To: From: alexr@nbase.co.il (Alex Ruzin) To: , , , Date: Wed, 21 Nov 2001 08:53:43 +0200 Message-ID: <000501c17259$435982c0$87885ac2@Alexr> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit 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 V5.50.4133.2400 Importance: Normal In-Reply-To: <000501c17231$176a7020$0100007f@corp.telseon.com> Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] RE: Question: 'upstream' handshake in 802.1w Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org Content-Transfer-Encoding: 7bit Mick, I don't understand you: what do you mean under "this certainly works". Yes, in .1w the topology becomes stable, fully and simply connected, but after only about 6 seconds. [Apropos, it seems to me, that the same problem is an explanation for case of http://www.ieee802.org/1/private/email/msg00348.html] My proposition is devoted to decrease this time. Why such handshake is critically timer dependent ? Why it is worse than the handshake, described in the second half of 17.19 and using variables like 'proposing', 'propose', 'sync', 'synced' and 'agreed' ? I propose *in addition* to introduce new and similar variables and to use new bits in the field "Flags" of RSTP BPDU. Your reply will be accepted with gratitude. With respect, Alex > -----Original Message----- > From: Mick Seaman [mailto:mick_seaman@ieee.org] > Sent: Wednesday, November 21, 2001 4:06 AM > To: 'Mick Seaman'; Arozin@opticalaccess.com; > stds-802-1@ieee.org; rstplib-users@lists.sourceforge.net; > bridge-mib@ietf.org > Subject: RE: Question: indirect link fail in 802.1w > > > > This certainly works (subject to accuracies of representation > in the spec of > what "this" is) without such a handshake (see you closing > statement below), > and as the handshake is critically timer dependent it is > against the spirit > of .1w. I was aware of the handshake mechanism well before > deisgning .1w. > > Mick > > -----Original Message----- > From: Mick Seaman [mailto:mick_seaman@ieee.org] > Sent: Tuesday, November 20, 2001 5:14 PM > To: 'Arozin@opticalaccess.com'; 'stds-802-1@ieee.org'; > 'rstplib-users@lists.sourceforge.net'; 'bridge-mib@ietf.org' > Subject: RE: Question: indirect link fail in 802.1w > > > Alex, > > I suggest you test this out using the RSTP Visio simulation. > > The only case in which any of these ports could be Backup is > a deficiency in > the spec or the interpretation of the spec, so extra protocol is not > required. > > Mick > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From daemon@optimus.ietf.org Wed Nov 21 04:04:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07578 for ; Wed, 21 Nov 2001 04:04:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA00120 for bridge-archive@odin.ietf.org; Wed, 21 Nov 2001 04:04:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00107; Wed, 21 Nov 2001 04:04:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00076 for ; Wed, 21 Nov 2001 04:04:09 -0500 (EST) Received: from apollo.nbase.co.il (apollo.nbase.co.il [194.90.137.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07573 for ; Wed, 21 Nov 2001 04:04:07 -0500 (EST) 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 AAA423; Wed, 21 Nov 2001 11:04:53 +0200 Reply-To: From: alexr@nbase.co.il (Alex Ruzin) To: , , , Date: Wed, 21 Nov 2001 11:05:03 +0200 Message-ID: <000c01c1726b$9c2f3090$87885ac2@Alexr> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit 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 V5.50.4133.2400 Importance: Normal In-Reply-To: <000c01c17260$179ce670$0100007f@corp.telseon.com> Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] RE: Question: indirect link fail in 802.1w Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org Content-Transfer-Encoding: 7bit Mick, [First of all, thank you for the quick reply]. Now, it seems to me, that my analysis is wrong "due" to my invalid spec. understanding and, hence, invalid implementation. So would you like to answer on follow questions: 1. Question about rcvBpdu and PIM. You wrote: Mick> This will cause C2 to accept the message (because B2 was Mick> Designated) and Mick> immediately override it (because C has information from C1-A1 Mick> that A is the Mick> Root), causing C2 to go from Alternate straight to Mick> Designated. As far as I see, C2 ignores this message: function rcvBpdu returns 'OtherMsg' because, as you correctly wrote, C has information from C1-A1 that A is the {better} Root). Now PIM simply jumps to CURRENT and updtRolesBridge() is not invoked. If it is correct, why C2 goes from Alternate straight to Designated ? If it is incorrect, where is my mistake ? 2. Question about SuperiorDesignatedMsg in rcvBpdu. Actually, In my implementation, rcvBpdu returns SuperiorDesignatedMsg, because 17.19.8: "Returns SuperiorDesignatedMsg if the received BPDU is an RSTP BPDU with a Designated Port Role, or a Config BPDU, and either the received message priority vector (see 17.4.2.2) is strictly better than the Port's port priority vector, or the Designated Bridge and Designated Port components of the received message priority vector are the same as those of the port priority vector and the message priority vector as a whole or any of the received timer parameter values (msgTimes - see 17.18.12) differ from those already held in portTmes (17.18.18)." In our case we have: a) it is 'RSTP BPDU with a Designated Port Role'; b) the same Designated Bridge and Designated Port; c) different msgTimes & portTimes. Where is my mistake here ? 3. Question about updtRolesBridge() I've received your message with extract from draft text that contributed to P802.1wD8 "RSTP Bug in updtBridgeRoles()". I would like to study it carefully; let me comment/ask about it later. For some [sad] reasons, I can't use your Visio Simulator. Instead it I use the simulator from http://sourceforge.net/projects/rstplib/ It has an advantage, that it is OpenSource one and I (as anyone) may freely trace and debug it :) But is has disadvantage, that it is based on my own implementation of 'rstplib', with my own bugs and flaws :( Again, thank you very much for the cooperation. With great respect Alex > -----Original Message----- > From: Mick Seaman [mailto:mick_seaman@ieee.org] > Sent: Wednesday, November 21, 2001 9:43 AM > To: Arozin@opticalaccess.com; stds-802-1@ieee.org; > rstplib-users@lists.sourceforge.net; bridge-mib@ietf.org > Subject: RE: Question: indirect link fail in 802.1w > > > > I've read "backbone fast" and it doesn't apeared to have > changed since I > read it several years ago. However that is not much to the point. > > > If C2 was not previously Designated it will receive a message > from the prior > Designated Bridge for the B2-C2 claiming worse information > for this link. > This will cause C2 to accept the message (because B2 was > Designated) and > immediately override it (because C has information from C1-A1 > that A is the > Root), causng C2 to go from Alternate straight to > Designated. Then C2 spits > out a message with a Designated port that is not yet > Forwarding, B gets this > and accepts A as the Root and replies, C on receiving the reply goes > Forwarding. > > > Time to recover = > > Time for B to notice link down + > Time for B to formulate and transmit message to C + > Time for C to receive message from B + > Time for C to formulate and send message to B + > Time for B to receive mesage from C + > Time for B to formulate and transmit message to C + > Time for C to receive message from B + > Time for C to change Port State to Forwarding > > Theoretical limit around about 4 * link/speed of light > (includes original > link failure) , practical limit set by process scheduling in B and C, > between 4 and 8 scheduling times depending on the software > architecture, but > most importantly timer independent recovery. > > What we need to diagnose is why you believe C goes to Backup > not Designated. > I think this may be because of an ommission we have recognized in > upftBridgeRoles() where an entire case was missed in the > editing - where > infoIs == Received but the designated priority is better than the port > priority. In that case selectedRole should be set to > DesignatedPort and > updtInfo SET. > > Unfortunately the authors of implementations to date were > just too familiar > with what should happen in such a case, and the simulation used the > pseudo-code used to derive the English in the standard - but > without the > case ommission. > > I recommend the use of the simulation to test out these and > similar cases. > > Mick > > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From daemon@optimus.ietf.org Wed Nov 21 04:16:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07793 for ; Wed, 21 Nov 2001 04:16:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA00296 for bridge-archive@odin.ietf.org; Wed, 21 Nov 2001 04:16:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00284; Wed, 21 Nov 2001 04:16:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00242 for ; Wed, 21 Nov 2001 04:16:01 -0500 (EST) Received: from apollo.nbase.co.il (apollo.nbase.co.il [194.90.137.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07789 for ; Wed, 21 Nov 2001 04:15:58 -0500 (EST) 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 AAA404; Wed, 21 Nov 2001 11:16:45 +0200 Reply-To: From: alexr@nbase.co.il (Alex Ruzin) To: , , , Date: Wed, 21 Nov 2001 11:16:55 +0200 Message-ID: <000d01c1726d$449260d0$87885ac2@Alexr> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit 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 V5.50.4133.2400 Importance: Normal In-Reply-To: <001101c17261$aac7cea0$0100007f@corp.telseon.com> Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] RE: 802.1w and timer dependencies Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org Content-Transfer-Encoding: 7bit On Sent: Wednesday, November 21, 2001 9:54 AM Mick Seaman wrote: Mick > Re: your question on why the .1w handshake is better than Mick > the handshake in Mick > backbone fast. I didn't ask it at all (oh, my poor English !) ! I propose to extend this (finest and rapidest !) handshake of .1w in 'upstream' direction. I would like to use the same spirit, logic, speed and timers independence as .1w handshake ! Nevertheless, it look after Mick's postings, that we needn't do it, because there is no the problem with "indirect link fail" in 802.1w. Let us return to this discussion after this question resolving. Best wishes, Alex > -----Original Message----- > From: Mick Seaman [mailto:mick_seaman@ieee.org] > Sent: Wednesday, November 21, 2001 9:54 AM > To: Arozin@opticalaccess.com; stds-802-1@ieee.org; > rstplib-users@lists.sourceforge.net; bridge-mib@ietf.org > Subject: 802.1w and timer dependencies > > > > Alex, > > Re: your question on why the .1w handshake is better than > the handshake in > backbone fast. > > In .1w timers are only used to recover from lost mesages on > point to point > links to bridges/bridge ports that are functioning, in other > words the speed > of recovery does not depend on the timers (except in cases > where the maximum > message transmit limit kicks in). In back bone fast there are > messages to > test if a bridge is "still there", which means that some (not all) > recoveries have to wait a time for non-response before taking > appropriate > action. This introduces a timer which in its normal case of > operation can be > "tweaked" to improve user performance - which opens the door > to overzealous > tweakers. > > All timers are evil, but some are more evil than others. > > Mick > > -----Original Message----- > From: Alex Ruzin [mailto:alexr@nbase.co.il] > Sent: Tuesday, November 20, 2001 10:54 PM > To: mick_seaman@ieee.org; stds-802-1@ieee.org; > rstplib-users@lists.sourceforge.net; bridge-mib@ietf.org > Subject: RE: Question: 'upstream' handshake in 802.1w > > > Mick, > > I don't understand you: what do you mean under "this certainly > works". Yes, in .1w the topology becomes stable, fully and > simply connected, > but after only about 6 seconds. > > [Apropos, it seems to me, that the same problem is an explanation > for case of http://www.ieee802.org/1/private/email/msg00348.html] > > My proposition is devoted to decrease this time. > > Why such handshake is critically timer dependent ? Why it is worse > than the handshake, described in the second half of 17.19 and > using variables like 'proposing', 'propose', 'sync', 'synced' > and 'agreed' ? > > I propose *in addition* to introduce new and similar variables and to > use new bits in the field "Flags" of RSTP BPDU. > > Your reply will be accepted with gratitude. > > With respect, Alex > > > -----Original Message----- > > From: Mick Seaman [mailto:mick_seaman@ieee.org] > > Sent: Wednesday, November 21, 2001 4:06 AM > > To: 'Mick Seaman'; Arozin@opticalaccess.com; > > stds-802-1@ieee.org; rstplib-users@lists.sourceforge.net; > > bridge-mib@ietf.org > > Subject: RE: Question: indirect link fail in 802.1w > > > > > > > > This certainly works (subject to accuracies of representation > > in the spec of > > what "this" is) without such a handshake (see you closing > > statement below), > > and as the handshake is critically timer dependent it is > > against the spirit > > of .1w. I was aware of the handshake mechanism well before > > deisgning .1w. > > > > Mick > > > > -----Original Message----- > > From: Mick Seaman [mailto:mick_seaman@ieee.org] > > Sent: Tuesday, November 20, 2001 5:14 PM > > To: 'Arozin@opticalaccess.com'; 'stds-802-1@ieee.org'; > > 'rstplib-users@lists.sourceforge.net'; 'bridge-mib@ietf.org' > > Subject: RE: Question: indirect link fail in 802.1w > > > > > > Alex, > > > > I suggest you test this out using the RSTP Visio simulation. > > > > The only case in which any of these ports could be Backup is > > a deficiency in > > the spec or the interpretation of the spec, so extra protocol is not > > required. > > > > Mick > > > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From daemon@optimus.ietf.org Wed Nov 21 09:01:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14784 for ; Wed, 21 Nov 2001 09:01:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA07584 for bridge-archive@odin.ietf.org; Wed, 21 Nov 2001 09:01:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07573; Wed, 21 Nov 2001 09:01:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA28120 for ; Wed, 21 Nov 2001 02:39:54 -0500 (EST) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06587 for ; Wed, 21 Nov 2001 02:39:53 -0500 (EST) Received: from user-2ivfiiv.dialup.mindspring.com ([165.247.202.95] helo=MICKHOME) by smtp10.atl.mindspring.net with smtp (Exim 3.33 #1) id 166Rz1-00018I-00; Wed, 21 Nov 2001 02:39:48 -0500 Reply-To: From: "Mick Seaman" To: , , , Date: Tue, 20 Nov 2001 23:42:37 -0800 Message-ID: <000c01c17260$179ce670$0100007f@corp.telseon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <000401c17254$9ee80670$87885ac2@Alexr> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] RE: Question: indirect link fail in 802.1w Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org Content-Transfer-Encoding: 7bit I've read "backbone fast" and it doesn't apeared to have changed since I read it several years ago. However that is not much to the point. If C2 was not previously Designated it will receive a message from the prior Designated Bridge for the B2-C2 claiming worse information for this link. This will cause C2 to accept the message (because B2 was Designated) and immediately override it (because C has information from C1-A1 that A is the Root), causng C2 to go from Alternate straight to Designated. Then C2 spits out a message with a Designated port that is not yet Forwarding, B gets this and accepts A as the Root and replies, C on receiving the reply goes Forwarding. Time to recover = Time for B to notice link down + Time for B to formulate and transmit message to C + Time for C to receive message from B + Time for C to formulate and send message to B + Time for B to receive mesage from C + Time for B to formulate and transmit message to C + Time for C to receive message from B + Time for C to change Port State to Forwarding Theoretical limit around about 4 * link/speed of light (includes original link failure) , practical limit set by process scheduling in B and C, between 4 and 8 scheduling times depending on the software architecture, but most importantly timer independent recovery. What we need to diagnose is why you believe C goes to Backup not Designated. I think this may be because of an ommission we have recognized in upftBridgeRoles() where an entire case was missed in the editing - where infoIs == Received but the designated priority is better than the port priority. In that case selectedRole should be set to DesignatedPort and updtInfo SET. Unfortunately the authors of implementations to date were just too familiar with what should happen in such a case, and the simulation used the pseudo-code used to derive the English in the standard - but without the case ommission. I recommend the use of the simulation to test out these and similar cases. Mick -----Original Message----- From: Alex Ruzin [mailto:alexr@nbase.co.il] Sent: Tuesday, November 20, 2001 10:21 PM To: mick_seaman@ieee.org; stds-802-1@ieee.org; rstplib-users@lists.sourceforge.net; bridge-mib@ietf.org Subject: RE: Question: indirect link fail in 802.1w Mick, The problem is not in hop to the Backup role, but in "late" hop to Designated role: only when rcvdInfoWhile timer expires, while we discard information, that may help in it. I again ask to read http://www.cisco.com/warp/public/473/18.html, where the explanation (for 1d) is more detail and clear. Thanks for the cooperation, Alex > -----Original Message----- > From: Mick Seaman [mailto:mick_seaman@ieee.org] > Sent: Wednesday, November 21, 2001 3:14 AM > To: Arozin@opticalaccess.com; stds-802-1@ieee.org; > rstplib-users@lists.sourceforge.net; bridge-mib@ietf.org > Subject: RE: Question: indirect link fail in 802.1w > > > Alex, > > I suggest you test this out using the RSTP Visio simulation. > > The only case in which any of these ports could be Backup is > a deficiency in > the spec or the interpretation of the spec, so extra protocol is not > required. > > Mick > > -----Original Message----- > From: owner-stds-802-1@majordomo.ieee.org > [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Alex Ruzin > Sent: Tuesday, November 20, 2001 6:09 AM > To: stds-802-1@ieee.org; rstplib-users@lists.sourceforge.net; > bridge-mib@ietf.org > Subject: Question: indirect link fail in 802.1w > > > > > Question: indirect link fail in 802.1w > > Initial configuration:3 Bridges (A, B, C) are > connected as a triangle. > Let's say, Bridge A is a Root Bridge and has > 2 designated ports A1 and A2. > Bridge B has root port B1 (connected with port > A1) and designated port B2, connected with > port C2. Bridge C has root port C1 (connected > with port A2) and Alternate port C2 (connected > with port B2). > > Now the link between B1 and A1 fails :( > Bridge B immediately detects the failure and > assumes it is Root Bridge ( while it doesn't > have any Alternate port) and starts to advertise > via port B2 its own Priority Vector. > > The problem is on the Bridge C. It receives on > Alternate port C2 SuperiorDesignate Msg BPDU. > It is because 17.19.8:"Designated Bridge and > Designated Port components of the received message > priority vector are the same as those of the port > priority vector and the message priority vector as > a whole or any of the received timer parameter > values (msgTimes -see 17.18.12) differ from > those already held in port-Times (17.18.18). > > As a result port C2 goes to have Backup role. > > Then, switch B continues to send its BPDU, but > for C these BPDU are "Inferior" or, in terms of > PIM, the function rcbBpdu returns OtherMsg. This > messages are discarded by PIM and there are 3 > such messages (6 seconds !). > > Only after that the rcvdInfoWhile timer expires, > port C2 is aged, becomes Designated, makes > 'handshake' with port B2 (which becomes Root for > the bridge B), and everything is OK. > > During about 6 seconds LAN, connected to C was > disconnected from LAN, connected to B ! (Yes, I > know, that in legacy STP such situation causes > a delay 50 seconds: MaxAge + 2 * ForwardDelay). > > IMHO, there may take place an optimization, The > idea: don't discard BPDU when 'OtherMsg', but > to start some "upstream' handshake (in addition > to RSTP 'downstream' handshake for rapid > transition Designating port to Forwarding state). > Such 'upstream' handshake may be started, when > SuperiorDesignate message was recognized by > another Times and message Priority Vector is worse > than a stored one. > > This idea is similar to "Spanning-Tree Protocol's > Backbone Fast Feature" of CISCO > (see http://www.cisco.com/warp/public/473/18.html) > > What do you think about it ? Does this idea break > the concept of 802.1w ? Is it in the plans of the > society ? > What if I start to design such 'handshake' ? > > Best regards, Alex > > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From daemon@optimus.ietf.org Wed Nov 21 09:01:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14801 for ; Wed, 21 Nov 2001 09:01:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA07636 for bridge-archive@odin.ietf.org; Wed, 21 Nov 2001 09:01:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07622; Wed, 21 Nov 2001 09:01:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA28293 for ; Wed, 21 Nov 2001 02:51:09 -0500 (EST) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06738 for ; Wed, 21 Nov 2001 02:51:08 -0500 (EST) Received: from user-2ivfiiv.dialup.mindspring.com ([165.247.202.95] helo=MICKHOME) by smtp10.atl.mindspring.net with smtp (Exim 3.33 #1) id 166S9v-0005Gd-00; Wed, 21 Nov 2001 02:51:04 -0500 Reply-To: From: "Mick Seaman" To: , , , Date: Tue, 20 Nov 2001 23:53:53 -0800 Message-ID: <001101c17261$aac7cea0$0100007f@corp.telseon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <000501c17259$435982c0$87885ac2@Alexr> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] 802.1w and timer dependencies Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org Content-Transfer-Encoding: 7bit Alex, Re: your question on why the .1w handshake is better than the handshake in backbone fast. In .1w timers are only used to recover from lost mesages on point to point links to bridges/bridge ports that are functioning, in other words the speed of recovery does not depend on the timers (except in cases where the maximum message transmit limit kicks in). In back bone fast there are messages to test if a bridge is "still there", which means that some (not all) recoveries have to wait a time for non-response before taking appropriate action. This introduces a timer which in its normal case of operation can be "tweaked" to improve user performance - which opens the door to overzealous tweakers. All timers are evil, but some are more evil than others. Mick -----Original Message----- From: Alex Ruzin [mailto:alexr@nbase.co.il] Sent: Tuesday, November 20, 2001 10:54 PM To: mick_seaman@ieee.org; stds-802-1@ieee.org; rstplib-users@lists.sourceforge.net; bridge-mib@ietf.org Subject: RE: Question: 'upstream' handshake in 802.1w Mick, I don't understand you: what do you mean under "this certainly works". Yes, in .1w the topology becomes stable, fully and simply connected, but after only about 6 seconds. [Apropos, it seems to me, that the same problem is an explanation for case of http://www.ieee802.org/1/private/email/msg00348.html] My proposition is devoted to decrease this time. Why such handshake is critically timer dependent ? Why it is worse than the handshake, described in the second half of 17.19 and using variables like 'proposing', 'propose', 'sync', 'synced' and 'agreed' ? I propose *in addition* to introduce new and similar variables and to use new bits in the field "Flags" of RSTP BPDU. Your reply will be accepted with gratitude. With respect, Alex > -----Original Message----- > From: Mick Seaman [mailto:mick_seaman@ieee.org] > Sent: Wednesday, November 21, 2001 4:06 AM > To: 'Mick Seaman'; Arozin@opticalaccess.com; > stds-802-1@ieee.org; rstplib-users@lists.sourceforge.net; > bridge-mib@ietf.org > Subject: RE: Question: indirect link fail in 802.1w > > > > This certainly works (subject to accuracies of representation > in the spec of > what "this" is) without such a handshake (see you closing > statement below), > and as the handshake is critically timer dependent it is > against the spirit > of .1w. I was aware of the handshake mechanism well before > deisgning .1w. > > Mick > > -----Original Message----- > From: Mick Seaman [mailto:mick_seaman@ieee.org] > Sent: Tuesday, November 20, 2001 5:14 PM > To: 'Arozin@opticalaccess.com'; 'stds-802-1@ieee.org'; > 'rstplib-users@lists.sourceforge.net'; 'bridge-mib@ietf.org' > Subject: RE: Question: indirect link fail in 802.1w > > > Alex, > > I suggest you test this out using the RSTP Visio simulation. > > The only case in which any of these ports could be Backup is > a deficiency in > the spec or the interpretation of the spec, so extra protocol is not > required. > > Mick > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From daemon@optimus.ietf.org Wed Nov 21 10:15:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18959 for ; Wed, 21 Nov 2001 10:15:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA09214 for bridge-archive@odin.ietf.org; Wed, 21 Nov 2001 10:15:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09189; Wed, 21 Nov 2001 10:15:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09156 for ; Wed, 21 Nov 2001 10:15:27 -0500 (EST) Received: from ctron-dnm.ctron.com (firewall-user@ctron-dnm.enterasys.com [12.25.1.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18938 for ; Wed, 21 Nov 2001 10:15:26 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id KAA09244 for ; Wed, 21 Nov 2001 10:24:00 -0500 (EST) Received: from cnc-exc2(134.141.77.103) by ctron-dnm.ctron.com via smap (4.1) id xma009188; Wed, 21 Nov 01 10:23:18 -0500 Received: by cnc-exc2.enterasys.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Nov 2001 10:14:21 -0500 Message-ID: <59358A738F45D51186A30008C74CE25062A696@slc-exc1.ctron.com> From: "Norseth, KC" To: "'bridge-mib@ietf.org'" Date: Wed, 21 Nov 2001 10:14:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1729F.302A4E50" Subject: [Bridge-mib] draft-ietf-bridge-bridgemib-smiv2-01.txt Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1729F.302A4E50 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1729F.302A4E50" ------_=_NextPart_001_01C1729F.302A4E50 Content-Type: text/plain Folks, I have submitted the update the the draft-ietf-bridge-bridgemib-smiv2-01.txt to the IETF. While waiting for it to officially be posted, I have posted it on my website for review. It is at: http://norseth.org/ietf/bridgemib/draft-ietf-bridge-bridgemib-smiv2-01.txt I apologize if I have missed anything that should have been added from the last couple of months discussion, I came into the editing of the document late in the game and could have missed something when reviewing the emails from the last few months. If I did, we can fix that. K.C. Norseth Firmware Engineering - Routing Enterasys Networks Phone: 801.887.9823 FAX: 801.972.5789 Email: knorseth@enterasys.com www: http://www.enterasys.com <> ------_=_NextPart_001_01C1729F.302A4E50 Content-Type: text/html Content-Transfer-Encoding: quoted-printable draft-ietf-bridge-bridgemib-smiv2-01.txt

Folks,

I have submitted the update the the = draft-ietf-bridge-bridgemib-smiv2-01.txt to the IETF.  While = waiting for it to officially be posted, I have posted it on my website = for review.  It is at:

 http://norseth.org/ietf/bridgemib/draft-ietf-bridge-br= idgemib-smiv2-01.txt

I apologize if I have missed anything that should = have been added from the last couple of months discussion, I came into = the editing of the document late in the game and could have missed = something when reviewing the emails from the last few months.  If = I did, we can fix that.


K.C. Norseth
Firmware Engineering -  Routing
Enterasys Networks
   Phone: 801.887.9823
   FAX:    801.972.5789 =
   Email:   = knorseth@enterasys.com
   www:    http://www.enterasys.com
 

<<Norseth, = KC.vcf>> =20 ------_=_NextPart_001_01C1729F.302A4E50-- ------_=_NextPart_000_01C1729F.302A4E50 Content-Type: application/octet-stream; name="Norseth, KC.vcf" Content-Disposition: attachment; filename="Norseth, KC.vcf" BEGIN:VCARD VERSION:2.1 N:Norseth;KC FN:Norseth, KC ORG:Cabletron Systems, Inc.;5167 TEL;WORK;VOICE:53823 ADR;WORK:;Salt Lake City;2835 South Decker Lake Drive;Salt Lake City;UT;84119;US LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Salt Lake City=0D=0A2835 South Decker Lake Drive=0D=0ASalt Lake City, UT 841= 19=0D=0AUS EMAIL;PREF;INTERNET:knorseth@cabletron.com REV:19991213T143559Z END:VCARD ------_=_NextPart_000_01C1729F.302A4E50-- _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From daemon@ns.ietf.org Wed Nov 21 11:00:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21482 for ; Wed, 21 Nov 2001 11:00:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10395 for bridge-archive@odin.ietf.org; Wed, 21 Nov 2001 11:00:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10248; Wed, 21 Nov 2001 11:00:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10204 for ; Wed, 21 Nov 2001 11:00:06 -0500 (EST) Received: from apollo.nbase.co.il (apollo.nbase.co.il [194.90.137.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21460 for ; Wed, 21 Nov 2001 11:00:01 -0500 (EST) 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 AAA416; Wed, 21 Nov 2001 18:00:44 +0200 Reply-To: From: alexr@nbase.co.il (Alex Ruzin) To: , , , Date: Wed, 21 Nov 2001 18:00:54 +0200 Message-ID: <003501c172a5$b43a3b50$87885ac2@Alexr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0036_01C172B6.77C30B50" 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 V5.50.4133.2400 Importance: Normal In-Reply-To: <000401c17229$bd383e90$0100007f@corp.telseon.com> Subject: [Bridge-mib] RE: [Rstplib-users] RE: Question: indirect link fail in 802.1w Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0036_01C172B6.77C30B50 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit Great & fine - it works ! The point was in Mick's important addition updtRolesBridge() : "... we are missing the case where infoIs == Received but the designated priority is better than the port priority. In that case selectedRole should be set to DesignatedPort and updtInfo SET..." Conclusions: 1. My function rcvBpdu works (and worked) fine, at least till now. It means, that in the relevant case it must recognize "SuperiorDesignateMsg". 2. The function updtRolesBridge has been drastically changed and I allow to myself to attach it (it may be useful to anyone). Anyway, this change I have committed in https://sourceforge.net/projects/rstplib/ 3. The reconfiguration is really rapid now. 4. Now I'm analyzing another problem, but it will be a new thread "Root port waits for 'slow' Designated Port in .1w " and I hope to get a similar help :) Again, thank to Mr. Mick Seaman very much ! I saw in 802.1y/D1 his proposition 'Z.11' is in state. If I may express my opinion - it should be accepted ASAP. With respect, Alex ------=_NextPart_000_0036_01C172B6.77C30B50 Content-Type: application/octet-stream; name="updtRolesBridge.c" Content-Disposition: attachment; filename="updtRolesBridge.c" Content-Transfer-Encoding: quoted-printable /* It is a part of Port Role Selection state machine */ static void /* sets selectedRole and traces this hop */ setRoleSelected (char* reason, STPM_T* stpm, PORT_T* port, PORT_ROLE_T newRole) { char* new_role_name; port->selectedRole =3D newRole; if (newRole =3D=3D port->role) return; switch (newRole) { case DisabledPort: new_role_name =3D "Disabled"; break; case AlternatePort:new_role_name =3D "Alternate";break; case BackupPort: new_role_name =3D "Backup"; break; case RootPort: new_role_name =3D "Root"; break; case DesignatedPort: new_role_name =3D "Designated"; break; default: stp_trace ("%s:%s-%s:port %s =3D> Unknown (%d ?)", SPRINT_TIME(0), reason, stpm->name, (int) port->port_name, newRole); return; } if (port->roletrns->debug) stp_trace ("%s:%s(%s-%s) =3D> %s", SPRINT_TIME(0), reason, stpm->name, (int) port->port_name, new_role_name); } static void /* computes Bridge Root Priority Vector */ updtRootPrio (STATE_MACH_T* this) { PRIO_VECTOR_T rootPathPrio; /* 17.4.2.2 */ register PORT_T *port; register STPM_T *stpm; register unsigned int dm; stpm =3D this->owner.stpm; for (port =3D stpm->ports; port; port =3D port->next) { if (Disabled =3D=3D port->infoIs) continue; if (Aged =3D=3D port->infoIs) continue; if (Mine =3D=3D port->infoIs) continue; STP_VECT_copy (&rootPathPrio, &port->portPrio); rootPathPrio.root_path_cost +=3D port->operPCost; if (STP_VECT_compare_vector (&rootPathPrio, &stpm->rootPrio) < 0) { STP_VECT_copy (&stpm->rootPrio, &rootPathPrio); STP_copy_times (&stpm->rootTimes, &port->portTimes); dm =3D (stpm->rootTimes.MaxAge + 8) / 16; if (!dm) dm =3D 1; stpm->rootTimes.MessageAge +=3D dm; } } } void /* 17.19.21 */ updtRolesBridge (STATE_MACH_T* this) { =20 register PORT_T* port; register STPM_T* stpm; PORT_ID old_root_port; /* for tracing of root port changing */ stpm =3D this->owner.stpm; /* actually, it is port0 */ old_root_port =3D stpm->rootPortId; STP_VECT_create (&stpm->rootPrio, &stpm->BrId, 0, &stpm->BrId, 0, 0); STP_copy_times (&stpm->rootTimes, &stpm->BrTimes); stpm->rootPortId =3D 0; updtRootPrio (this); for (port =3D stpm->ports; port; port =3D port->next) { STP_VECT_create (&port->designPrio, &stpm->rootPrio.root_bridge, stpm->rootPrio.root_path_cost, &stpm->BrId, port->port_id, port->port_id); STP_copy_times (&port->designTimes, &stpm->rootTimes); } stpm->rootPortId =3D stpm->rootPrio.bridge_port; if (old_root_port !=3D stpm->rootPortId) { if (! stpm->rootPortId) { stp_trace ("\n%s:brige %s became root", SPRINT_TIME(1), (int) stpm->name); } else { stp_trace ("\n%s:brige %s new root port: %s", SPRINT_TIME(1), (int) stpm->name, STP_stpm_get_port_name_by_id (stpm, stpm->rootPortId)); } } for (port =3D stpm->ports; port; port =3D port->next) { switch (port->infoIs) { case Disabled: setRoleSelected ("Dis", stpm, port, DisabledPort); break; case Aged: setRoleSelected ("Age", stpm, port, DesignatedPort); port->updtInfo =3D True; break; case Mine: setRoleSelected ("Mine", stpm, port, DesignatedPort); if (0 !=3D STP_VECT_compare_vector (&port->portPrio, &port->designPrio) || 0 !=3D STP_compare_times (&port->portTimes, &port->designTimes)) { port->updtInfo =3D True; } break; case Received: if (stpm->rootPortId =3D=3D port->port_id) { setRoleSelected ("Rec", stpm, port, RootPort); } else if (STP_VECT_compare_vector (&port->designPrio, = &port->portPrio) < 0) { /* Note: this important piece has been inserted after * discussion with Mick Sieman and reading 802.1y Z1 */ setRoleSelected ("Rec", stpm, port, DesignatedPort); port->updtInfo =3D True; break; } else { if (_is_backup_port (port, stpm)) { setRoleSelected ("rec", stpm, port, BackupPort); } else { setRoleSelected ("rec", stpm, port, AlternatePort); } } port->updtInfo =3D False; break; default: stp_trace ("undef infoIs=3D%d", (int) port->infoIs); break; } } } ------=_NextPart_000_0036_01C172B6.77C30B50-- _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From more93x@eudoramail.com Sun Nov 25 20:11:02 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26533 for ; Sun, 25 Nov 2001 20:11:01 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fAQ0ldl01239 for ; Sun, 25 Nov 2001 16:47:40 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id fAQ0lde14482 for ; Sun, 25 Nov 2001 16:47:39 -0800 (PST) Received: from localhost.localdomain (IDENT:root@[213.23.88.6]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id fAQ0lKH14083 for ; Sun, 25 Nov 2001 16:47:21 -0800 (PST) Received: from cfmkefjke89 (02-132.024.popsite.net [216.126.161.132]) by localhost.localdomain (8.9.3/8.8.7) with ESMTP id XAA13140; Sun, 25 Nov 2001 23:31:21 +0100 Message-Id: <200111252231.XAA13140@localhost.localdomain> From: "Robert Sacron" Subject: Jump in #553E To: game82s@localhost.localdomain X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Date: Sun, 25 Nov 2001 12:52:41 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FREE Computer With Merchant Account Setup

COMPLETE CREDIT CARD PROCESSING SYSTEMS FOR YOUR BUSINESS=2E INTERNE= T - HOME BASED - MAIL ORDER - PHONE ORDER

Do you accept credit cards? Your competition does!

 

Everyone Approved - Credit Problems OK!
Approval in less than 24 hours!
Increase your sales by 300%
Start Accepting Credit Cards on your website!
Free Information, No Risk, 100% confidential=2E
Your name and information will not be sold to third parties!
Home Businesses OK! Phone/Mail Order OK!
No Application Fee, No Setup Fee!
Close More Impulse Sales!

Everyone Approved!

Good Credit or Bad!  To= apply today, please fill out the express form below=2E It contains all the information we need to get your account approved=2E For a= rea's that do not apply to you please put "n/a" in the box=2E

Upon receipt, we'll fax you with all of the all Bank Card Application documents necessary to establish your Merchant Account=2E Once returned we= can have your account approved within 24 hours=2E
 

Service Industry Standard

US
Site Inspection $50 - $75 FREE
Shipping $50 - $75 FREE
Warranty $10 Per Month= FREE
Sales Receipts $10 - $50&nbs= p; FREE
Fraud Screening

$=2E50 - $1=2E00
Per Transaction

 FREE
Amex Set Up $50 - $75 FREE
24 Hour Help Line $10 Month FREE
Security Bond $5000- $10,00= 0
Or More		 NONE

This is a No Obligation Qualification Form and is your first step to accepting credit cards=2E By filling out this form you will= "not enter" in to any obligations o= r contracts with us=2E We will use it to determine the best p= rogram to offer you based on the information you provide=2E You will be c= ontacted by one of our representatives within 1-2 business days to go over = the rest of your account set up=2E

<= font color=3D"#cc0000">Note:  All Information Provided To Us Will Remain= 100% Confidential !! 

Apply Free With No Risk!

Pleas= e fill out the express application form completely=2E
Incomplete information m= ay prevent us from properly processing your application=2E
Your Full Emai= l Address:
be sure to use your full address (i= =2Ee=2E user@domain=2Ecom)
Your Name:
Business Name:=
Business Phone= Number:
Home Phone Num= ber:
Type of Busine= ss:
Retail Business
Mail Order Business
Internet Based Busines= s
Personal Credi= t Rating:
Excellent
Good
Fair
Poor
How Soon Would= You Like a Merchant Account?


Your info= rmation is confidential, it will not be sold or used for any other purpose,= and you are under no obligation=2E Your information will be used solely for the purpose of evaluating= your business or website for a merchant account so that you may begin acce= pting credit card payments=2E


List Removal/OPT-OUT Option
Click Herem ------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From daemon@optimus.ietf.org Tue Nov 27 05:51:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17951 for ; Tue, 27 Nov 2001 05:51:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA26475 for bridge-archive@odin.ietf.org; Tue, 27 Nov 2001 05:51:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26462; Tue, 27 Nov 2001 05:51:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26431 for ; Tue, 27 Nov 2001 05:51:10 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17917; Tue, 27 Nov 2001 05:51:07 -0500 (EST) Message-Id: <200111271051.FAA17917@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: bridge-mib@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 27 Nov 2001 05:51:06 -0500 Subject: [Bridge-mib] I-D ACTION:draft-ietf-bridge-rstpmib-01.txt Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bridge MIB Working Group of the IETF. Title : Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol and VLAN Classification Extensions Author(s) : E. Bell, V. Ngai Filename : draft-ietf-bridge-rstpmib-01.txt Pages : 29 Date : 26-Nov-01 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 three MIB modules for managing the new capabilities of MAC bridges defined by the IEEE P802.1t [802.1t], P802.1u [802.1u], P802.1v [802.1v] and P802.1w [802.1w] amendments to IEEE Std 802.1D-1998 for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing Rapid Spanning Tree Protocol, one for controlling Restricted VLAN Registration, and one for VLAN Classification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bridge-rstpmib-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bridge-rstpmib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bridge-rstpmib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011126101245.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bridge-rstpmib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bridge-rstpmib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011126101245.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From daemon@optimus.ietf.org Wed Nov 28 05:52:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28045 for ; Wed, 28 Nov 2001 05:52:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA18828 for bridge-archive@odin.ietf.org; Wed, 28 Nov 2001 05:53:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18817; Wed, 28 Nov 2001 05:52:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18784 for ; Wed, 28 Nov 2001 05:52:51 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28024; Wed, 28 Nov 2001 05:52:46 -0500 (EST) Message-Id: <200111281052.FAA28024@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: bridge-mib@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 28 Nov 2001 05:52:46 -0500 Subject: [Bridge-mib] I-D ACTION:draft-ietf-bridge-bridgemib-smiv2-01.txt Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bridge MIB Working Group of the IETF. Title : Definitions of Managed Objects for Bridges Author(s) : E. Bell et al. Filename : draft-ietf-bridge-bridgemib-smiv2-01.txt Pages : 35 Date : 27-Nov-01 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bridge-bridgemib-smiv2-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bridge-bridgemib-smiv2-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bridge-bridgemib-smiv2-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011127134246.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bridge-bridgemib-smiv2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bridge-bridgemib-smiv2-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011127134246.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From daemon@optimus.ietf.org Wed Nov 28 12:46:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24821 for ; Wed, 28 Nov 2001 12:46:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA03302 for bridge-archive@odin.ietf.org; Wed, 28 Nov 2001 12:46:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03288; Wed, 28 Nov 2001 12:45:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03257 for ; Wed, 28 Nov 2001 12:45:56 -0500 (EST) Received: from columba.eur.3com.com (columba.EUR.3Com.COM [161.71.169.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24806 for ; Wed, 28 Nov 2001 12:45:53 -0500 (EST) Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.eur.3com.com with ESMTP id fASHlpn16210; Wed, 28 Nov 2001 17:47:51 GMT Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id fASHjL922830; Wed, 28 Nov 2001 17:45:22 GMT Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256B12.00624EF8 ; Wed, 28 Nov 2001 17:53:47 +0000 X-Lotus-FromDomain: 3COM From: "Les Bell" To: Rohit Rohit cc: Arozin@Opticalaccess.com, Bridge-mib@ietf.org, vngai@enterasys.com Message-ID: <80256B04.00037592.00@notesmta.eur.3com.com> Date: Tue, 13 Nov 2001 23:31:00 +0000 Subject: Re: FW: [Bridge-mib] Outstanding RSTP-MIB issues Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org Sorry, I forgot to respond to this email previously. The TxHoldCount is not configurable according to 802.1w, so I did not think it was necessary to include it in the MIB. Table 8-3 and Table 17-5 of 802.1w do not indicate a valid range for the TxHoldCount value, just defining the default value of 3. 802.1w 14.8.1.2 Set Bridge Protocol parameters does not include TxHoldCount in the list of input parameters. I shall raise this issue on the IEEE 802.1 WG email list, to see if we can get their views on whether this was the intention, or if TxHoldCount should really be configurable. Les... Rohit Rohit on 13/11/2001 22:46:18 Sent by: Rohit Rohit To: "'Les Bell'" , Arozin@Opticalaccess.com cc: Bridge-mib@ietf.org, Les_Bell@3com.com, vngai@enterasys.com Subject: FW: [Bridge-mib] Outstanding RSTP-MIB issues Hi Less, I didn't get the reply for this mail earlier. Trying it again. Thanks Rohit -----Original Message----- From: Rohit Rohit Sent: Tuesday, October 09, 2001 9:33 AM To: 'Les Bell'; bridge-mib@ietf.org Subject: RE: [Bridge-mib] Outstanding RSTP-MIB issues Hi, I am not sure whether the presentation discussed the dot1dStpHoldTime issue for RSTP or not. We have holdCount for the rstp and which is not same as dot1dStpHoldTime for stp. So are we going to have a new object for the rstpHoldCount ? If yes, then what should be the value of dot1dStpHoldTime for the rstp bridges. Thanks Rohit -----Original Message----- From: Les Bell [mailto:Les_Bell@eur.3com.com] Sent: Tuesday, October 09, 2001 6:29 AM To: bridge-mib@ietf.org Subject: [Bridge-mib] Outstanding RSTP-MIB issues Here is a summary of the outstanding issues on the RSTP-MIB, U-BRIDGE-MIB and V-BRIDGE-MIB in draft-ietf-bridge-rstpmib-00.txt I would like to solicit more input from people to try and close these issues and get an updated draft out before the December IETF. (1) Some missing items were identified (see the presentation). STATUS: Should add these to the new draft mib. COMMENTS: No comments from the mailing list. PROPOSED ACTION: Add the missing items. (2) The U-BRIDGE-MIB and V-BRIDGE-MIB should probably be done as updates to RFC 2674. STATUS: No feedback received yet. COMMENTS: No comments from the mailing list. PROPOSED ACTION: Requires further input from the mailing list. Les... _______________________________________________ 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 daemon@optimus.ietf.org Wed Nov 28 13:46:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29443 for ; Wed, 28 Nov 2001 13:46:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA05083 for bridge-archive@odin.ietf.org; Wed, 28 Nov 2001 13:46:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05047; Wed, 28 Nov 2001 13:45:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05016 for ; Wed, 28 Nov 2001 13:45:51 -0500 (EST) Received: from foozball.iwl.com (foozball.iwl.com [199.184.128.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29384 for ; Wed, 28 Nov 2001 13:45:47 -0500 (EST) Received: from web110.iwl.com (web110.iwl.com [199.184.129.17]) by foozball.iwl.com (8.11.6/8.11.6) with SMTP id fASIjIa07875 for ; Wed, 28 Nov 2001 10:45:18 -0800 Received: from localhost (chrisw@localhost) by web110.iwl.com (8.11.6/8.11.6) with ESMTP id fASIjIY22746 for ; Wed, 28 Nov 2001 10:45:18 -0800 Date: Wed, 28 Nov 2001 10:45:18 -0800 (PST) From: Chris Wellens Reply-To: Chris Wellens To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Bridge-mib] Bridge MIB Test Summit Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org Bridge MIB Test Summit ---------------------- InterWorking Labs will host the Bridge MIB and Ethernet-Like Interface MIB Test Summit in January 28-30, 2002 at our offices in Scotts Valley, California. Purpose ------- Participants will be able to test their own products for: 1. Conformance to the Bridge MIB and/or Ethernet-Like MIB, and 2.Iinteroperability with other implementations. Participants will also identify and clarify areas of confusion in the RFCs where implementations differ, and this feedback with be given to the IETF. Fred Baker, former IETF Chair, will officiate. Test Coverage ------------- Test coverage will include the following RFCs: RFC2665 "Definitions of Managed Objects for the Ethernet-like Interface Types" RFC2233 "The Interfaces Group MIB using SMIv2 " RFC2674 "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions" RFC1493 "Definitions of Managed Objects for Bridges" Who is Invited -------------- Implementors, Developers, Q/A Engineers, and Testers who have implemented the Bridge MIB and/or the Ethernet-Like Interface MIB are invited to attend. What to Bring ------------- Attendees should bring a laptop computer with a 10/100 Ethernet card, and the product containing the SNMP agent with the Bridge MIB or Ethernet-like MIB. Test Network ------------ Design of the test network is underway and details will be available in December, 2001. InterWorking Labs will set up a test network and test station for each participating company. We will discuss results and findings each day. Everyone will be following a test plan. Confidentiality, Press ---------------------- All participants will be required to execute a Mutual Non-Disclosure Agreement insuring that they will not communicate information learned about other participants and their product implementations. This agreement may be found at http://www.iwl.com/Products/Legal in Acrobat format. No members of the press, sales, marketing, etc. will be allowed. Only individuals with specific development or testing responsibilities may participate. Proxy Network Software Engineers Available ------------------------------------------ If you would like to attend, but are prevented by travel restrictions and/or new security policies at your company, InterWorking Labs will find a local software engineer with a networking background who can participate on your behalf. Due to the downturn in the technology sector, many very capable and experienced network software engineers are between engagements, and will be happy to represent your product for the three day test summit. These engineers will be expected to communicate with you daily by phone or email, to send you bug reports, and keep you fully informed regarding developments with your product implementation. Bridge MIB Test Suite --------------------- Each participating vendor will receive a Beta copy of InterWorking Labs' new Bridge MIB Test Suite and Ethernet-Like MIB Test Suite for either Windows, Solaris, or Linux after the event. This will allow each participating company to continue regression testing in their own Q/A labs after the event for continuity. Chief Technical Officer of the Bridge MIB Test Summit ----------------------------------------------------- Fred Baker has worked in the telecommunications industry since 1978, building statistical multiplexors, terminal servers, bridges, and routers. At Cisco Systems, his primary interest areas include the improvement of Quality of Service for best effort and real time traffic, and the development of next generation routing and addressing for the Internet. In addition to product development, as a Cisco Fellow, he advises senior management of industry directions and appropriate corporate strategies. His principal standards contributions have been to the IETF, for which he served as IETF Chair in from March 1996 to March 2001. In that forum, he has contributed to Network Management, Routing, PPP and Frame Relay, the Integrated and Differentiated Services architectures, and the RSVP signaling protocol. He now serves on the IETF's Internet Architecture Board, and as a technical contributor. Price ----- Price for the Bridge MIB Test Summit is $2,995 per product and includes the test suite software, attendance by up to three engineers, connection for the test product, lunch each day, and a copy of the Bridge MIB Test Suite to use for regression testing in your lab. Companies who have more than one product, may register an additional product for $500. Payment must be received no later than January 19, 2002. Register -------- Call 800.459.9817 x10 or Email sales@iwl.com Where to Stay ------------- The Inn at Scotts Valley (a Hilton Hotel) 6001 La Madrona Drive Highway 17 at Mt. Hermon Road Scotts Valley, CA 95066 Directions at: http://www.theinnatscottsvalley.com/page5.html Toll Free: 888.445.3010 Local Phone: 831.440.1000 When making a reservation say that you are with the "Bridge MIB Test Summit" to get the special rate of $129.00 (regular rate is $189.00) Best Western Scotts Valley 6020 Scotts Valley Drive Scotts Valley, CA 95066 831-438-6666 Directions at: http://www.bestwestern.com/ Toll Free Phone: 1-800-780-1234 Local Phone: 831-438-6666 When making a reservation say that you are with the "Bridge MIB Test Summit" to get the special rate of $71.10 for King Room or $80.10 for Double Room (regular rate is $80-85) We look forward to seeing you there! _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib