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 <bridge-archive@odin.ietf.org>; 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: <bivkracrnse@hotmail.com>
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

<html>

<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dwindows-=
1252">
<title>Receive 10</title>
<style>
<!--
h1
	{margin-bottom:.0001pt;
	page-break-after:avoid;
	font-size:14.0pt;
	font-family:"Times New Roman";
	font-weight:bold; margin-left:0in; margin-right:0in; margin-top:0in}
-->
</style>
</head>

<body>

<table border=3D"0" cellspacing=3D"0" cellpadding=3D"0" width=3D"500" bgco=
lor=3D"#0033cc" style=3D"width:375.0pt;mso-cellspacing:0in;background:#003=
3CC;mso-padding-alt:
 1.5pt 1.5pt 1.5pt 1.5pt">
  <tr>
    <td style=3D"padding:1.5pt 1.5pt 1.5pt 1.5pt">
      <div align=3D"center">
        <table border=3D"0" cellspacing=3D"0" cellpadding=3D"0" width=3D"5=
00" bgcolor=3D"white" style=3D"width:375.0pt;mso-cellspacing:0in;backgroun=
d:white;mso-padding-alt:
   0in 0in 0in 0in">
          <tr>
            <td style=3D"background:#FFFFCC;padding:0in 0in 0in 0in">
              <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" styl=
e=3D"border-collapse: collapse" bordercolor=3D"#111111" width=3D"100%" id=3D=
"AutoNumber1">
                <tr>
                  <td width=3D"3%">&nbsp;</td>
                  <td width=3D"94%">
                  <p align=3D"center" style=3D"text-align: center"><b>
                  <span style=3D"font-size: 18.0pt; font-family: Arial; co=
lor: black">
                  Hair Loss Got You Down?</span></b><u><span style=3D"font=
-size: 10.0pt; font-family: Arial; color: black"><br>
                  </span></u><b><span style=3D"font-family: Arial; color: =
black">
                  Would You Like to do Something About It?</span></b><span=
 style=3D"font-size: 10.0pt; font-family: Arial; color: black"><br>
                  <![if !supportLineBreakNewLine]><br>
&nbsp;<![endif]></span><br>
                  <span style=3D"font-family: Arial; color: black; font-we=
ight: 700">
                  <a href=3D"http://www.hairrejuvenator.com"><font size=3D=
"5">$50 
                  SAVINGS on Initial Order</font></a></span></p>
                  <p align=3D"center" style=3D"text-align: center"><b>
                  <span style=3D"font-family: Arial; color: black">(Mentio=
n 
                  product code 15 to save $50 on initial order)</span></b>=
</p>
                  <p align=3D"center" style=3D"text-align: center"><b>
                  <span style=3D"font-family: Arial; color: black">Patente=
d Hair 
                  Accelerator products are an all natural scientifically p=
roven 
                  way to stop hair loss and grow new hair!</span></b><span=
 style=3D"font-family: Arial; color: black"><br>
                  <br>
                  &nbsp;&nbsp;Hair Accelerator products are the first drug=
-free &quot;total 
                  attack&quot; program that aggressively combats hair loss=
 internally 
                  and externally. &nbsp;Our hair loss products have been c=
linically 
                  tested at Hospitals and Universities throughout the Worl=
d. <br>
                  <![if !supportLineBreakNewLine]><br>
&nbsp;<![endif]></span></p>
                  <p align=3D"center" style=3D"text-align: center"><b>
                  <span style=3D"font-family: Arial; color: black">Also Re=
ceive 
                  our FREE Online Guide to Hair Loss!</span></b></p>
                  <p align=3D"center" style=3D"text-align: center"><b>
                  <span style=3D"font-size: 13.5pt; font-family: Arial; co=
lor: black">
                  Start feeling confident again! Take the first step now!<=
br>
                  <br>
                  We Can Help You!</span></b></p>
                  <p align=3D"center" style=3D"text-align: center"><font s=
ize=3D"5">
                  <b><span style=3D"font-family: Arial">
                  <a href=3D"http://www.hairrejuvenator.com">Click Here Fo=
r 
                  Details</a></span></b></font></td>
                  <td width=3D"3%">&nbsp;</td>
                </tr>
              </table>
            </td>
          </tr>
          <tr>
            <td style=3D"background:#FFFFCC;padding:0in 0in 0in 0in">
              &nbsp;</td>
          </tr>
        </table>
      </div>
      <p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">=
<o:p>
      </o:p>
      </p>
    </td>
  </tr>
  <tr>
    <td style=3D"padding:1.5pt 1.5pt 1.5pt 1.5pt">
      <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-b=
ottom-alt:auto"><span style=3D"font-size:8.0pt;mso-bidi-font-size:12.0pt;c=
olor:#FFFF99">This
      email was sent to you because your email is part of a targeted opt-i=
n
      list.&nbsp; If you do not wish to receive further mailings, please c=
lick
      below and enter your email at the bottom of the page.&nbsp; You may =
then
      rest-assured that you will never receive another email from us again=
.&nbsp;&nbsp;<a href=3D"http://www.removeyou.com/" onmouseover=3D"window.s=
tatus=3D'Remove me!';return true;"><span style=3D"color:
  #FFFF99">UNSUBSCRIBE ME PLEASE</span></a> #022481</span></p>
    </td>
  </tr>
</table>

</body>

</html>





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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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 <bridge-mib@ietf.org>; 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: <Arozin@Opticalaccess.com>
From: alexr@nbase.co.il (Alex Ruzin)
To: <Bridge-mib@ietf.org>
Cc: <Les_Bell@3Com.com>, <vngai@enterasys.com>
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:  <bridge-mib.ietf.org>
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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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 <Bridge-mib@ietf.org>; 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" <Les_Bell@eur.3com.com>
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:  <bridge-mib.ietf.org>
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 <Arozin@Opticalaccess.com>

Sent by:  bridge-mib-admin@ietf.org


To:   <Bridge-mib@ietf.org>
cc:   <Les_Bell@3com.com>, <vngai@enterasys.com>
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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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 <Bridge-mib@ietf.org>; 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: <A37DCFC18E67944ABE602BC3EDA71646C31A2F@worldwidepackets.com>
From: Rohit Rohit <Rohit.Rohit@worldwidepackets.com>
To: "'Les Bell'" <Les_Bell@eur.3com.com>, 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:  <bridge-mib.ietf.org>
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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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 <bridge-mib@ietf.org>; 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: <Arozin@Opticalaccess.com>
From: alexr@nbase.co.il (Alex Ruzin)
To: "'Les Bell'" <Les_Bell@eur.3com.com>
Cc: <Bridge-mib@ietf.org>, <vngai@enterasys.com>
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:  <bridge-mib.ietf.org>
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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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 <bridge-mib@ietf.org>; 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: <Arozin@Opticalaccess.com>
From: alexr@nbase.co.il (Alex Ruzin)
To: <stds-802-1@ieee.org>, <Bridge-mib@ietf.org>,
        <rstplib-users@lists.sourceforge.net>
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:  <bridge-mib.ietf.org>
X-BeenThere: bridge-mib@ietf.org
Content-Transfer-Encoding: 7bit

The new release of <subj> 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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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 <Bridge-mib@ietf.org>; 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" <Les_Bell@eur.3com.com>
To: Rohit Rohit <Rohit.Rohit@worldwidepackets.com>
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:  <bridge-mib.ietf.org>
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 <Rohit.Rohit@worldwidepackets.com> on 13/11/2001 22:46:18

Sent by:  Rohit Rohit <Rohit.Rohit@worldwidepackets.com>


To:   "'Les Bell'" <Les_Bell@eur.3com.com>, 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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@ns.ietf.org>; 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 <Bridge-mib@ietf.org>; 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" <Les_Bell@eur.3com.com>
To: Rohit Rohit <Rohit.Rohit@worldwidepackets.com>
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:  <bridge-mib.ietf.org>
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 <Rohit.Rohit@worldwidepackets.com> on 13/11/2001 22:46:18

Sent by:  Rohit Rohit <Rohit.Rohit@worldwidepackets.com>


To:   "'Les Bell'" <Les_Bell@eur.3com.com>, 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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@ns.ietf.org>; 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 <Bridge-mib@ietf.org>; 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: <A37DCFC18E67944ABE602BC3EDA71646C31A37@worldwidepackets.com>
From: Rohit Rohit <Rohit.Rohit@worldwidepackets.com>
To: "'Les Bell'" <Les_Bell@eur.3com.com>,
        Rohit Rohit
	 <Rohit.Rohit@worldwidepackets.com>
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:  <bridge-mib.ietf.org>
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 <Rohit.Rohit@worldwidepackets.com> on 13/11/2001 22:46:18

Sent by:  Rohit Rohit <Rohit.Rohit@worldwidepackets.com>


To:   "'Les Bell'" <Les_Bell@eur.3com.com>, 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 <bridge-archive@lists.ietf.org>; 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 <bridge-mib@external.cisco.com>; 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 <bridge-mib@external.cisco.com>; 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 <bridge-mib@external.cisco.com>; 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 <B0000065583@ntserver.oknp.com>;
 Fri, 16 Nov 2001 16:18:41 +0900
Message-ID: <B0000065583@ntserver.oknp.com>
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4611.1300" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Visit the only website with&nbsp; tools proven and 
guaranteed to help you profit, make money and <BR>give you the advantage in any 
economic time! Click&nbsp;<A 
href="http://3468642680/~flot/jo/index.html">Here</A></FONT></DIV>
<P>
<DIV><FONT face=Arial size=2><B>Featuring:</B><BR>Credit repair <BR>New Credit 
Files<BR>Grants and Free Money<BR>Business Opportunities<BR>No money down Real 
Estate</FONT></DIV>
<DIV>&nbsp;</DIV>


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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@ns.ietf.org>; 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 <bridge-mib@ietf.org>; 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: <Arozin@Opticalaccess.com>
From: alexr@nbase.co.il (Alex Ruzin)
To: <stds-802-1@ieee.org>, <rstplib-users@lists.sourceforge.net>,
        <bridge-mib@ietf.org>
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:  <bridge-mib.ietf.org>
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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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 <bridge-mib@ietf.org>; 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: <mick_seaman@ieee.org>
From: "Mick Seaman" <mick_seaman@ieee.org>
To: <Arozin@opticalaccess.com>, <stds-802-1@ieee.org>,
        <rstplib-users@lists.sourceforge.net>, <bridge-mib@ietf.org>
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:  <bridge-mib.ietf.org>
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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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 <bridge-mib@ietf.org>; 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: <mick_seaman@ieee.org>
From: "Mick Seaman" <mick_seaman@ieee.org>
To: "'Mick Seaman'" <mick_seaman@ieee.org>, <Arozin@opticalaccess.com>,
        <stds-802-1@ieee.org>, <rstplib-users@lists.sourceforge.net>,
        <bridge-mib@ietf.org>
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:  <bridge-mib.ietf.org>
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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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 <bridge-mib@ietf.org>; 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: <Arozin@Opticalaccess.com>
From: alexr@nbase.co.il (Alex Ruzin)
To: <mick_seaman@ieee.org>, <stds-802-1@ieee.org>,
        <rstplib-users@lists.sourceforge.net>, <bridge-mib@ietf.org>
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:  <bridge-mib.ietf.org>
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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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 <bridge-mib@ietf.org>; 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: <Arozin@Opticalaccess.com>
From: alexr@nbase.co.il (Alex Ruzin)
To: <mick_seaman@ieee.org>, <stds-802-1@ieee.org>,
        <rstplib-users@lists.sourceforge.net>, <bridge-mib@ietf.org>
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:  <bridge-mib.ietf.org>
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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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 <bridge-mib@ietf.org>; 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: <Arozin@Opticalaccess.com>
From: alexr@nbase.co.il (Alex Ruzin)
To: <mick_seaman@ieee.org>, <stds-802-1@ieee.org>,
        <rstplib-users@lists.sourceforge.net>, <bridge-mib@ietf.org>
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:  <bridge-mib.ietf.org>
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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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 <bridge-mib@ietf.org>; 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: <Arozin@Opticalaccess.com>
From: alexr@nbase.co.il (Alex Ruzin)
To: <mick_seaman@ieee.org>, <stds-802-1@ieee.org>,
        <rstplib-users@lists.sourceforge.net>, <bridge-mib@ietf.org>
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:  <bridge-mib.ietf.org>
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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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 <bridge-mib@ietf.org>; 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: <mick_seaman@ieee.org>
From: "Mick Seaman" <mick_seaman@ieee.org>
To: <Arozin@Opticalaccess.com>, <stds-802-1@ieee.org>,
        <rstplib-users@lists.sourceforge.net>, <bridge-mib@ietf.org>
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:  <bridge-mib.ietf.org>
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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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 <bridge-mib@ietf.org>; 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: <mick_seaman@ieee.org>
From: "Mick Seaman" <mick_seaman@ieee.org>
To: <Arozin@Opticalaccess.com>, <stds-802-1@ieee.org>,
        <rstplib-users@lists.sourceforge.net>, <bridge-mib@ietf.org>
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:  <bridge-mib.ietf.org>
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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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 <bridge-mib@ietf.org>; 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 <bridge-mib@ietf.org>; 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 <WZTLVAM1>; Wed, 21 Nov 2001 10:14:21 -0500
Message-ID: <59358A738F45D51186A30008C74CE25062A696@slc-exc1.ctron.com>
From: "Norseth, KC" <knorseth@enterasys.com>
To: "'bridge-mib@ietf.org'" <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:  <bridge-mib.ietf.org>
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
 
 <<Norseth, KC.vcf>> 

------_=_NextPart_001_01C1729F.302A4E50
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>draft-ietf-bridge-bridgemib-smiv2-01.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Folks,</FONT>
</P>

<P><FONT SIZE=3D2>I have submitted the update the the =
draft-ietf-bridge-bridgemib-smiv2-01.txt to the IETF.&nbsp; While =
waiting for it to officially be posted, I have posted it on my website =
for review.&nbsp; It is at:</FONT></P>

<P><FONT SIZE=3D2>&nbsp;<A =
HREF=3D"http://norseth.org/ietf/bridgemib/draft-ietf-bridge-bridgemib-sm=
iv2-01.txt" =
TARGET=3D"_blank">http://norseth.org/ietf/bridgemib/draft-ietf-bridge-br=
idgemib-smiv2-01.txt</A></FONT>
</P>

<P><FONT SIZE=3D2>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.&nbsp; If =
I did, we can fix that.</FONT></P>
<BR>

<P><FONT SIZE=3D2>K.C. Norseth</FONT>
<BR><FONT SIZE=3D2>Firmware Engineering -&nbsp; Routing </FONT>
<BR><FONT SIZE=3D2>Enterasys Networks</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Phone: 801.887.9823</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; FAX:&nbsp;&nbsp;&nbsp; 801.972.5789 =
</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Email:&nbsp;&nbsp; =
knorseth@enterasys.com</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; www:&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://www.enterasys.com" =
TARGET=3D"_blank">http://www.enterasys.com</A></FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

<P><FONT FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"> &lt;&lt;Norseth, =
KC.vcf&gt;&gt; </FONT>=20

</BODY>
</HTML>
------_=_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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@ns.ietf.org>; 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 <bridge-mib@ietf.org>; 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: <Arozin@Opticalaccess.com>
From: alexr@nbase.co.il (Alex Ruzin)
To: <mick_seaman@ieee.org>, <stds-802-1@ieee.org>,
        <rstplib-users@lists.sourceforge.net>, <bridge-mib@ietf.org>
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:  <bridge-mib.ietf.org>
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 <TBD> 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 <bridge-archive@lists.ietf.org>; 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 <bridge-mib@external.cisco.com>; 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 <bridge-mib@external.cisco.com>; 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 <bridge-mib@external.cisco.com>; 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" <more93x@eudoramail.com>
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

<html>

<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dwindows-=
1252">
<meta name=3D"GENERATOR" content=3D"Microsoft FrontPage 4=2E0">
<meta name=3D"ProgId" content=3D"FrontPage=2EEditor=2EDocument">
<title>FREE Computer With Merchant Account Setup</title>
</head>

<body>

<center>
<p><b>COMPLETE CREDIT CARD PROCESSING SYSTEMS FOR YOUR BUSINESS=2E INTERNE=
T -  HOME
BASED -  MAIL ORDER -  PHONE ORDER</b></p>
<p><b>Do you accept credit cards? Your competition does!</b></p>
<p>&nbsp;</p>
<p>Everyone Approved - Credit Problems OK!<br>
Approval in less than 24 hours!<br>
Increase your sales by 300%<br>
Start Accepting Credit Cards on your website!<br>
Free Information, No Risk, 100% confidential=2E<br>
Your name and information will not be sold to third parties!<br>
Home Businesses OK!  Phone/Mail Order OK!<br>
No Application Fee, No Setup Fee!<br>
Close More Impulse Sales!<br>
<br>
</p>
<div align=3D"center">
  <table border=3D"0" cellspacing=3D"0" width=3D"85%">
    <tr>
      <td width=3D"100%">
        <p align=3D"center"><b><font face=3D"Times New Roman" size=3D"5" c=
olor=3D"#CC0000">Everyone Approved!</font></b></p>
        <p><b><font face=3D"Times New Roman"> Good Credit or Bad!&nbsp; 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 &quot;n/a&quot; in the box=2E<br>
<br>
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<br>&nbsp;</font></b>
        </p>
      </td>
    </tr>
  </table>
</div>
<table border=3D"10" cols=3D"3" width=3D"385">
  <tbody>
    <tr>
      <td align=3D"center" bgColor=3D"#990000" width=3D"119"><b><font colo=
r=3D"#ffff00" face=3D"Arial,Helvetica" size=3D"3">Service</font></b></td>
      <td align=3D"center" bgColor=3D"#990000" width=3D"160"><b><font colo=
r=3D"#ffff00" face=3D"Arial,Helvetica" size=3D"3">Industry
        Standard</font></b></td>
      <td align=3D"center" bgColor=3D"#990000" width=3D"66">
        <p align=3D"center"><b><font color=3D"#ffff00" face=3D"Arial,Helve=
tica" size=3D"3">US</font></b></p>
      </td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Site
        Inspection</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$50 - $75</fo=
nt></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Shipping</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$50 - $75</fo=
nt></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Warranty</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$10 Per Month=
</font></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Sales
        Receipts</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$10 - $50&nbs=
p;</font></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Fraud
        Screening</font></b></td>
      </center>
    <td align=3D"middle" width=3D"160">
      <p align=3D"left"><font size=3D"2"><b>$=2E50 - $1=2E00</b><br>
      <b>Per Transaction</b></font></p>
    </td>
<center>
<td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica" size=3D=
"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Amex Set
        Up</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$50 - $75</fo=
nt></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">24 Hour&nbsp;Help
        Line</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$10 Month</fo=
nt></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Security
        Bond</font></b></td>
      <td align=3D"middle" width=3D"160"><font size=3D"2"><b>$5000- $10,00=
0</b><br>
        <b>Or More</b></font></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">NONE</font></b></td>
    </tr>
  </tbody>
</table><p>
<div align=3D"center">
  <table border=3D"0" cellspacing=3D"0" width=3D"85%">
    <tr>
      <td width=3D"100%">
        <p><font face=3D"Arial,Helvetica" size=3D"2"><b>This is a <font co=
lor=3D"#3333ff">No
        Obligation Qualification Form</font> and is your first step to<fon=
t color=3D"#cc0000">
        accepting credit cards=2E</font> By filling out this form you will=
 <font color=3D"#3333ff">&quot;not
        enter&quot;</font> in to any <font color=3D"#006600">obligations o=
r
        contracts </font>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</b></font>
        <p align=3D"center"><font face=3D"Arial,Helvetica" size=3D"2"><b><=
font color=3D"#cc0000">Note:</font>&nbsp;
        All Information Provided To Us <font color=3D"#cc0000">Will Remain=
 100%
        Confidential</font>
        !!&nbsp;</b></font></td>
    </tr>
  </table>
</div>
<table border=3D"0">
  <tbody>
    <tr>
      <td width=3D"100%">
        <p align=3D"center"><b><font color=3D"#000099" face=3D"arial" size=
=3D"+2">Apply
        Free With No Risk!</font></b></p>
      </td>
    </tr>
  </tbody>
</table>
  </center>
</form>
<div align=3D"left">
  <table border=3D"0" width=3D"95%">
    <tr>
      <td width=3D"100%">
        <p align=3D"center"><b><i><font size=3D"2" color=3D"#CC0000">Pleas=
e fill out the
        express application form completely=2E<br>Incomplete information m=
ay prevent us from properly
        processing your application=2E</font></i></b></p>
      </td>
    </tr>
  </table>
</div>
<form name=3D"form"
  method=3D"post"
  action=3D"mailto:yzztm@alloymail=2Ecom?SUBJECT=3DForm"
  enctype=3D"text/plain"
  
 
 <tr>
<div align=3D"left">
  <table border=3D"0" width=3D"95%">
    <tr>
      <td width=3D"61%" align=3D"right"><font size=3D"2"><b>Your Full Emai=
l Address:</b><br>
        <font color=3D"#ff0000">be sure to use your full address </font>(i=
=2Ee=2E<font color=3D"#ff0000">
        </font>user@domain=2Ecom)</font></td>
      <td width=3D"39%" align=3D"center"><input type=3D"text" name=3D"user=
_email" size=3D"29"></td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Your Name:</fo=
nt></b></td>
      <td width=3D"39%" align=3D"center"><input type=3D"text" name=3D"Appl=
icant_Name" size=3D"29"></td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Business Name:=
</font></b></td>
      <td width=3D"39%" align=3D"center"><input type=3D"text" name=3D"Busi=
ness_Name" size=3D"29"></td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Business Phone=
 Number:</font></b></td>
      <td width=3D"39%" align=3D"center"><input type=3D"text" name=3D"Busi=
ness_Phone" size=3D"29"></td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Home Phone Num=
ber:</font></b></td>
      <td width=3D"39%" align=3D"center"><input type=3D"text" name=3D"Home=
Phone" size=3D"29"></td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Type of Busine=
ss:</font></b></td>
      <td width=3D"39%">
        <div align=3D"left">
          <table border=3D"0" width=3D"95%">
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"retail" name=3D"Type_Business"></td>
              <td width=3D"88%"><font size=3D"2"><b>Retail Business</b></f=
ont></td>
            </tr>
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"mailorder" name=3D"Type_Business"></td>
              <td width=3D"88%"><font size=3D"2"><b>Mail Order Business</b=
></font></td>
            </tr>
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"internet" name=3D"Type_Business"></td>
              <td width=3D"88%"><font size=3D"2"><b>Internet Based Busines=
s</b></font></td>
            </tr>
          </table>
        </div>
      </td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Personal Credi=
t Rating:</font></b></td>
      <td width=3D"39%">
        <div align=3D"left">
          <table border=3D"0" width=3D"95%">
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"excellent" name=3D"Credit_Rank"></td>
              <td width=3D"88%">Excellent</td>
            </tr>
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"good" name=3D"Credit_Rank"></td>
              <td width=3D"88%">Good</td>
            </tr>
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"fair" name=3D"Credit_Rank"></td>
              <td width=3D"88%">Fair</td>
            </tr>
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"poor" name=3D"Credit_Rank"></td>
              <td width=3D"88%">Poor</td>
            </tr>
          </table>
        </div>
      </td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">How Soon Would=
 You Like a Merchant
        Account?</font></b></td>
      <td width=3D"39%">
        <p align=3D"center"><input type=3D"text" name=3D"How_Soon" size=3D=
"29"></p>
      </td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2">
        <div align=3D"center">
          <center>
          <table border=3D"0" width=3D"13%">
            <tr>
              <td width=3D"100%">
                <p align=3D"center"><input type=3D"submit" value=3D"Submit=
" name=3D"B1"></td>
            </tr>
          </table>
          </center>
        </div>
      </td></form>
    </tr>
  </table>
</div><br>
<div align=3D"center">
  <center>
  <table border=3D"3" cellspacing=3D"0" width=3D"85%" bgcolor=3D"#E8E8E8" =
bordercolor=3D"#C0C0C0">
    <tr>
      <td width=3D"100%" bgcolor=3D"#E8E8E8"><font size=3D"2"><b>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</b></font>
      </td>
    </tr>
  </table>
  </center>
</div>

</form>

<p align=3D"center">
<br><b><font size=3D"3" color=3D"#FF0000">List
 Removal/OPT-OUT Option</font></b>
 <br><b><font color=3D"#000000"><font size=3D-1><a
 href=3D"mailto:dynnkd@netscape=2Enet?subject=3Dremove">Click
 Here</a></font></font></b>m

</body>


</html>


------=_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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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:  <bridge-mib.ietf.org>
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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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:  <bridge-mib.ietf.org>
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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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 <Bridge-mib@ietf.org>; 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" <Les_Bell@eur.3com.com>
To: Rohit Rohit <Rohit.Rohit@worldwidepackets.com>
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:  <bridge-mib.ietf.org>
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 <Rohit.Rohit@worldwidepackets.com> on 13/11/2001 22:46:18

Sent by:  Rohit Rohit <Rohit.Rohit@worldwidepackets.com>


To:   "'Les Bell'" <Les_Bell@eur.3com.com>, 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 <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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 <Bridge-mib@ietf.org>; 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 <Bridge-mib@ietf.org>; 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 <Bridge-mib@ietf.org>; Wed, 28 Nov 2001 10:45:18 -0800
Date: Wed, 28 Nov 2001 10:45:18 -0800 (PST)
From: Chris Wellens <chrisw@iwl.com>
Reply-To: Chris Wellens <chrisw@iwl.com>
To: <Bridge-mib@ietf.org>
Message-ID: <Pine.LNX.4.33.0111281035590.22597-100000@web110.iwl.com>
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:  <bridge-mib.ietf.org>
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