From carment5y@usa.com Tue Aug 7 07:30:37 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 HAA01128 for ; Tue, 7 Aug 2001 07:30:37 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f77BD2307785 for ; Tue, 7 Aug 2001 04:13:02 -0700 (PDT) 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 f77BCpR00021 for ; Tue, 7 Aug 2001 04:12:51 -0700 (PDT) Received: from fileserver.estop.co.kr (IDENT:root@[211.112.7.141]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f77BDR510547 for ; Tue, 7 Aug 2001 04:13:27 -0700 (PDT) Received: from host (06-107.081.popsite.net [64.24.246.107]) by fileserver.estop.co.kr (8.9.3/8.9.3) with ESMTP id TAA32470; Tue, 7 Aug 2001 19:32:37 +0900 Message-Id: <200108071032.TAA32470@fileserver.estop.co.kr> From: "Charles T. Miller" Subject: Been Chosen #3003 To: lis49r@fileserver.estop.co.kr X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Date: Tue, 07 Aug 2001 06:57:13 -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 Executive Guild Membership ApplicationResponse-O-Matic Form

Dear Candidate,=A0

You have been selected as a potential candidate for a free listing in=A0<= br> the 2001 Edition of the International Executive Guild Registry=2E=A0
=
Please accept our congratulations for this coveted honor=2E=A0

As this edition is so important in view of the new millennium, the=A0
= International Executive Guild Registry will be published in two different= =A0
formats; the searchable CD-ROM and the Online Registry=2E=A0

Since inclusion can be considered recognition of your career position=A0<= br> and professionalism, each candidate is evaluated in keeping with high=A0<= br> standards of individual achievement=2E In light of this, the Internationa= l Executive
Guild thinks that you may make an interesting biographical subject=2E=A0<= br>
We look forward to your inclusion and appearance in the International=A0<= br> Executive Guild's Registry=2E Best wishes for your continued success=2E=A0=

International Executive Guild=A0
Listing Dept=2E=A0

If you wish to be removed from our list, please submit your request
at the bottom of this email=2E

International Executive Guild
Registration Form
(US and Canada Only)
Please fill out this form if you would like to be included on The International Executive Guild, For accuracy and publication purposes, please complete and send this form at the earliest opportunity=2E There is no charge or obligation to be listed on The International Executive Guild=2E
Your Name
Your Company
Title
Address
City
State or Province
Country
ZIP/Postal Code
Day Time Telephone
Home Phone
 (Not To Be Published)
Email

TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF=2E=2E=2E
Your Business
(Financial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc=2E)
Type of Organization
(M= fg, Dist/Wholesaler, Retailer, Law Firm,
Investment Bank, Commercial Bank, University,
Financial Consultants, Ad Agency, Contractor, Broker, etc=2E)
Your Business Expertise
(Corp=2EMgmt, Marketing, Civil Engineering,
Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortgage Banking, etc=2E)
Major Product Line
(Integrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc=2E)


Note: Submitting this form= will be made by email, not by use of  www=2E  Confirmation of its de= livery is made by browsing your outgoing mail=2E

Thank you for filling in this form, we will contact you with more information=2E

List Removal
Click Here
------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From bridge-mib-admin@ietf.org Wed Aug 8 20:05:12 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 UAA23976 for ; Wed, 8 Aug 2001 20:05:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05591; Wed, 8 Aug 2001 20:06:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05560 for ; Wed, 8 Aug 2001 20:06:00 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23969 for ; Wed, 8 Aug 2001 20:04:52 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id CAA01170; Thu, 9 Aug 2001 02:05:59 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id CAA25826; Thu, 9 Aug 2001 02:05:59 +0200 Date: Thu, 9 Aug 2001 02:05:59 +0200 Message-Id: <200108090005.CAA25826@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Les_Bell@3com.com CC: bridge-mib@ietf.org Subject: [Bridge-mib] smiv2 bridge mib smilint warnings Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org I have looked at the smilint warning for the BRIDGE-MIB in . Here is what smilint 0.2.16 says: ./BRIDGE-MIB:1086: implicit node definition ./BRIDGE-MIB:1240: group `dot1dTrapGroup' is unconditionally optional Both messages are just warnings (level 6). So it is actually fine to ignore them. Anyway, the first warning says that the OID dot1dBridge.0 does not have an associated descriptor. So rather than using ::= { dot1dBridge 0 1 } and ::= { dot1dBridge 0 2 } in the notification definitions, you could use ::= { dot1dNotification 1 } and ::= { dot1dNotification 2 } and adding dot1dNotification OBJECT IDENTIFIER ::= { dot1dBridge 0 } at the top of the MIB module. The second warning says that the dot1dTrapGroup (perhaps this should be dot1dNotificationGroup?) is not contained in any conformance group - not sure this is really what you want. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org http://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-admin@ietf.org Thu Aug 9 05:42:35 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 FAA19101 for ; Thu, 9 Aug 2001 05:42:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29394; Thu, 9 Aug 2001 05:43:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29359 for ; Thu, 9 Aug 2001 05:43:13 -0400 (EDT) Received: from relay3.bt.net (relay3.bt.net [194.72.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19096 for ; Thu, 9 Aug 2001 05:42:05 -0400 (EDT) Received: from [217.33.137.123] (helo=dperkins-nb2.dsperkins.com) by relay3.bt.net with esmtp (Exim 3.22 #1) id 15UmKQ-00061E-00; Thu, 09 Aug 2001 10:42:10 +0100 Message-Id: <5.0.2.1.2.20010809021554.0260f6b0@mail.scruznet.com> X-Sender: dperkins@mail.scruznet.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 09 Aug 2001 02:42:39 -0700 To: Juergen Schoenwaelder , Les_Bell@3com.com From: "David T. Perkins" Subject: Re: [Bridge-mib] smiv2 bridge mib smilint warnings Cc: bridge-mib@ietf.org In-Reply-To: <200108090005.CAA25826@henkell.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org HI, Note, object dot1dStaticAllowedToGoTo is an octet string with no size specified, and, thus, can vary in size from 0 to 65535 octets. Since this is a BIT string to identify ports, you can have from zero to 8*65535 (524280). Is this valid? Also, for support of port big numbers, such as port 65535, the object will have length of 8192 octets. This will probably be greater than the typical max message size. Is this OK, or not realistic. (Note, I don't have a copy of the IEEE 802.1D-1990 document with me. It's at home, sorry, so I cannot check what it says is the max port number.) In checking the max port number, I saw that object dot1dBaseNumPorts has data type of Integer32, which means it can have negative values and positive values as great as 2^31 -1. Do you really support this? The "no label on the "0" subidentifier" message from smilint is "helpful", since the MIB parser in some "broken" management systems cannot cope with a sub-identifier without a label. However, there is no requirement in the SMI (nor in ASN.1) to have a label. Note that it is valid to specify a label via the following: ::= { dot1dbridge dot1dNotification(0) 1 } The SMI and ASN.1 says this is valid. Again, some broken MIB parsers may not support it. On the group dot1dTrapGroup not being in a compliance, this is OK following the SMI rules. However, due to the requirements for IETF standards-track documents, there must be no features defined in RFCs that have no usage requirement, which is a strange way of saying that for advancement to DRAFT, all features must be shown to be useful, implemented, and interoperation demonstrated. Thus, having a feature totally optional is not a good thing. I suggest that it be specified in a separate compliance specification that describes the situations where it is appropriate. At 02:05 AM 8/9/2001 +0200, Juergen Schoenwaelder wrote: >I have looked at the smilint warning for the BRIDGE-MIB in >. Here is what smilint >0.2.16 says: > >./BRIDGE-MIB:1086: implicit node definition >./BRIDGE-MIB:1240: group `dot1dTrapGroup' is unconditionally optional > >Both messages are just warnings (level 6). So it is actually fine to >ignore them. > >Anyway, the first warning says that the OID dot1dBridge.0 does not >have an associated descriptor. So rather than using > > ::= { dot1dBridge 0 1 } > >and > > ::= { dot1dBridge 0 2 } > >in the notification definitions, you could use > > ::= { dot1dNotification 1 } > >and > > ::= { dot1dNotification 2 } > >and adding > >dot1dNotification OBJECT IDENTIFIER ::= { dot1dBridge 0 } > >at the top of the MIB module. The second warning says that the >dot1dTrapGroup (perhaps this should be dot1dNotificationGroup?) is not >contained in any conformance group - not sure this is really what you >want. > >/js Regards, /david t. perkins _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org http://www1.ietf.org/mailman/listinfo/bridge-mib From renee47@mail.com Sat Aug 18 08:50:20 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11740 for ; Sat, 18 Aug 2001 08:50:19 -0400 (EDT) From: renee47@mail.com Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7ICW3T04906 for ; Sat, 18 Aug 2001 05:32:03 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f7ICVi319131 for ; Sat, 18 Aug 2001 05:31:44 -0700 (PDT) Received: from misnt01.hondaphil.com ([202.163.237.83]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f7ICTLc10037 for ; Sat, 18 Aug 2001 05:29:21 -0700 (PDT) Received: from localhost by misnt01.hondaphil.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id QRMJG6MM; Fri, 17 Aug 2001 13:39:49 +0800 Received: from 64.24.138.127 by misnt01.hondaphil.com (InterScan E-Mail VirusWall NT); Fri, 17 Aug 2001 13:39:40 +0800 Received: from mail.zuellig.com by c03-127.071.popsite.net with ESMTP; Fri, 17 Aug 2001 00:23:22 -0500 Message-ID: <00000ced6aba$000033be$0000699f@mail.zuellig.com> To: Subject: We deliverer 323 27039 Date: Fri, 17 Aug 2001 00:23:21 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Reply-To: renee47@mail.com Content-Transfer-Encoding: quoted-printable

Can't get email out to the masses without losing your ISP???

Don't= know how to get sales for your product???

Can't get traffic to your site???

Call 1-888-829-1943

I have plenty of fresh = verified email names and can get you results.


Price List
Discounts for larger orders

   100 Thousand - $200
   500 Thousand - $875
   1 Million - $1500

It is this easy!
You simply furnish your message and I do the rest. I gua= rantee you 100% delivery. It can even be done in full color at no extra= cost

NO= TICE

To be removed, hit reply and type remove in the subject line.
From DavedWell@hotmail.com Sun Aug 19 10:54:39 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13743 for ; Sun, 19 Aug 2001 10:54:39 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7JERVT14354 for ; Sun, 19 Aug 2001 07:27:31 -0700 (PDT) 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 f7JERED11883 for ; Sun, 19 Aug 2001 07:27:14 -0700 (PDT) Received: from mail.bridgestonetj.com ([202.99.123.135]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f7JERpE17228 for ; Sun, 19 Aug 2001 07:27:51 -0700 (PDT) Message-Id: <200108191427.f7JERpE17228@proxy3.cisco.com> Received: from plastic1 (slip-12-64-60-149.mis.prserv.net [12.64.60.149]) by mail.bridgestonetj.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id RG4T1CH6; Sun, 19 Aug 2001 22:29:02 +0800 From: "Ed Wellsville" Subject: Stressed with Debt? To: <#field0#@cisco.com> Date: Fri, 18 May 2001 23:51:39 -0700 X-Mailer: diffondi V4,0,1,0 (W95/NT) (Build: Feb 20 2001) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA13743 Consolidate all your debt into ONE, EASY monthly payment! We will help you: *Eliminate interest charges *Waive late fee charges *Improve your credit rating And best of all, lower your monthly payments by 40%-60% and KEEP MORE CASH IN YOUR POCKET! Take just 1 minute to complete our Credit Card Consolidation Form and one of our experienced professional consultants will contact you! http://www.1xin.net/creditconsolidation There is no obligation and our service is fast and free! All information is kept strictly confidential. **************************************************************** Since you have received this message you have either responded to one of our offers in the past or your address has been registered with us. If you wish to be removed please reply: mailto:crcleads1@yahoo.ca?subject=remove **************************************************************** From cosmo@bigexec.net Mon Aug 20 22:59:04 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 WAA11709 for ; Mon, 20 Aug 2001 22:59:03 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7L2YkD26154 for ; Mon, 20 Aug 2001 19:34:46 -0700 (PDT) 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 f7L2aci26098 for ; Mon, 20 Aug 2001 19:36:38 -0700 (PDT) Received: from www.css.co.kr ([211.171.182.100]) by proxy1.cisco.com (8.11.2/8.11.2) with SMTP id f7L2aND24649 for ; Mon, 20 Aug 2001 19:36:26 -0700 (PDT) Date: Mon, 20 Aug 2001 19:36:26 -0700 (PDT) Message-Id: <200108210236.f7L2aND24649@proxy1.cisco.com> Received: from inbound.bigexec.net.criticalpath.net ([63.208.231.2]) by www.css.co.kr (MERAK 3.10.110) with ESMTP id 906305C3; Tue, 21 Aug 2001 11:32:35 +0900 Reply-To: From: "cosmo@bigexec.net" To: "3749@rtodd@eurosport.com" <3749@rtodd@eurosport.com> Subject: Need more web traffic? Content-Type: text/plain; charset="us-ascii";format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Triple Your Business in 60 Days or Less !! Generate traffic to your website by the thousands!!! Have complete control on who receives your ad. Get thousands of Targeted visitors!!! Why it Works. Because you can deliver your message to millions of people for a fraction of the cost of conventional advertising. That's right it's less than a classified ad that would only reach a fraction of the audience. What we offer you. A complete turn-key operation for you. * Total Control- We can expose your product to hundreds of millions of people of your choosing. * Full Marketing Team - Our marketing team will help you create an effective marketing piece for your campaign . * FREE use of software - we will provide you with state of the art software specifcally designed to contact all the prospects you need. * 100% customer service and tech support . Your success is our success !! EASY As 1...2...3... It's easy to get started simply reply today and we will set you up with this fantastic system, specifically designed for "Your success on The Net" Call 702-242-5725 To Unsubscribe to this email list, please go to deletes@eurosport.com and type "ELIMINATE" in the subject line. Thank you. From bridge-mib-admin@ietf.org Fri Aug 24 17:48:56 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 RAA16115 for ; Fri, 24 Aug 2001 17:48:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15397; Fri, 24 Aug 2001 17:40:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15368 for ; Fri, 24 Aug 2001 17:40:55 -0400 (EDT) Received: from creeper.bmc.com ([63.111.188.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16000 for ; Fri, 24 Aug 2001 17:39:33 -0400 (EDT) Received: from ec02-hou.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f7OLei000035 for ; Fri, 24 Aug 2001 16:40:45 -0500 (CDT) Received: by EC02-HOU.bmc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 16:40:51 -0500 Message-ID: From: "Ayers, Mike" To: "'bridge-mib@ietf.org'" Date: Fri, 24 Aug 2001 16:40:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" Subject: [Bridge-mib] Test Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org please ignore _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-admin@ietf.org Fri Aug 24 17:56:16 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 RAA16220 for ; Fri, 24 Aug 2001 17:56:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15548; Fri, 24 Aug 2001 17:46:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15515 for ; Fri, 24 Aug 2001 17:46:56 -0400 (EDT) Received: from creeper.bmc.com ([63.111.188.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16067 for ; Fri, 24 Aug 2001 17:45:33 -0400 (EDT) Received: from ec02-hou.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f7OLkj900554 for ; Fri, 24 Aug 2001 16:46:46 -0500 (CDT) Received: by EC02-HOU.bmc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 16:46:52 -0500 Message-ID: From: "Ayers, Mike" To: "'bridge-mib@ietf.org'" Date: Fri, 24 Aug 2001 16:46:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" Subject: [Bridge-mib] Meeting minutes for the 51st IETF Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org Here's the first pass of the minutes for the IETF meeting. Please review carefully - in some places my notes were a little unintelligible. /|/|ike Meeting minutes for the Bridge MIB WG, 51st IETF Tuesday August 7, 2001, 1700 1.) Overview There are three drafts in progress. Bert W.: Currently the chair is authoring documents. Can we get co-editors? John Flick & K.C. Norseth volunteered. RFCs 1493, 1525, & 2674 need to progress. RFCs 1493 & 1525 are being updated to SMIv2. There are some new 802.1 MIBs Implementation reports are needed for RFCs: 1493 - currently draft 1525 - currently proposed 2674 - currently proposed Please submit implkementation reports! If you do not wish to submit your report to the group at large, you may submit privately to Les or Bert (addresses?) 2.) SMIv2 Bridge MIB Draft draft-ietf-bridge-bridgemib-smiv2.txt This is a direct translation of RFC1493 into SMIv2. However, a few issues have arisen: a.) The object dot1dBasePortIfIndex should be of type InterfaceIndex, but is currently Integer32. Bert W.: We can progress the IF MIB and use InterfaceIndex. Les: We should also change "traps" to "notifications" in a comment. All: OK b.) There are still problems with logical link aggregation. c.) Is dot1dStdPortEnable redundant? Mike A.: No, a port may not have a unique ifIndex. dot1dStdPortEnable remains. d.) Some (many?) implementations permit spanning tree to be turned off an a per-port basis. Should we standardize this? Many questions were raised about why this would be done and what the default behavior could be. The group sought a rationale for doing this, but could not find one. Therefore no action will be taken. e.) Should we add an object to give the time of last change for dot1dBasePortTable? Mike A.: Why make a change like this now? Bert W.: We would have to recycle. Les: Does anyone think that we should do this? (silence). f.) Smilint complained about some notification definitions. 3.) SMIv2 Source Routing Bridge MIB Draft Another direct translation of an SMIv1 MIB. No comments have been received yet. Is anyone using the source routing bridge MIB anymore? Bert W.: Why advance what nobody is currently implementing? (name?): This is like the FDDI MIB, which needs no advancement. 4.) 802.1 Standards 802.1w - Rapid reconfiguration 802.1t - Update to 802.1d 802.1u - Update to 802.1q 802.1v - VLAN classification by port/protocol 802.1 documents are available at http://grouper.ieee.org/groups/802/1/index.html, username: p8021 password: go_wildcats 5.) New MIBs Rapid Spanning Tree Protocol MIB (RSTPMIB): Involves changes to the bridge MIB. We don't need to change the syntax, but there may be interoperability issues. U-bridge MIB: Only one new item. This can be merged with 2674. John F.: Can we merge all new MIBs with 2674? Mike A.: If we merge them, will we just split them out again? 6.) 802.1 Standards, part 2 Updates on 802.1t, 802.1w, 802.1u, 802.1v, and 802.1s (per- VLAN spanning trees) For 802.1x, IEEE wrote their own MIB - should we publish it as an informational RFC? Bert W.: Do we want to? Mike A.: We would then have all the bridge docs in one place. Les: 802.1x is not just a bridge. Bert W.: Then we'd best take this to the mailing list. 7.) Close A.) Action Items Mike A.: Write up explanation of the port/ifIndex issue for the list. _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-admin@ietf.org Fri Aug 24 19:22:13 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 TAA16887 for ; Fri, 24 Aug 2001 19:22:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17543; Fri, 24 Aug 2001 19:19:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17510 for ; Fri, 24 Aug 2001 19:19:45 -0400 (EDT) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16855 for ; Fri, 24 Aug 2001 19:18:27 -0400 (EDT) Received: from mordor.yagosys.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id QAA19390; Fri, 24 Aug 2001 16:19:14 -0700 (PDT) Received: from eire.riverstonenet.com by mordor.yagosys.com (SMI-8.6/SMI-SVR4) id QAA01984; Fri, 24 Aug 2001 16:19:13 -0700 Message-Id: <5.1.0.14.1.20010824155735.00a910c0@mordor.yagosys.com> X-Sender: mrm@mordor.yagosys.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 24 Aug 2001 16:19:06 -0700 To: "Ayers, Mike" , "'bridge-mib@ietf.org'" From: Michael MacFaden Subject: Re: [Bridge-mib] Meeting minutes for the 51st IETF In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org At 04:46 PM 8/24/2001 -0500, Ayers, Mike wrote: > c.) Is dot1dStdPortEnable redundant? > > Mike A.: No, a port may not have a unique ifIndex. > > dot1dStdPortEnable remains. Due to the rather poor scheduling of the bridge and entity working groups, I wasn't able to discuss this in London. Since most modern ethernet switches as opposed to old repeaters have a one for one mapping from dot1d to ifIndex, the following situations arise which I think lead to implementation/interoperability problems: Consider these two case: a) port both bridges and routes b) port bridges only 1) When ifAdminStatus is set to down, what should dot1dStpPortEnable? Probably up (bridging could occur, but underlying port is shut down), 2) When dot1dStpPort is set to disabled, what should ifAdminStatus report? In case a), I can see this object as a means to only stop bridging on a port w/out affecting routing or ifAdminStatus. Yet most devices I've tested have this object shut down the entire port like ifAdminStatus for both bridging and routing and if I recall some of them set ifAdminStatus to down. In case b), the behavior I susepect is to only shut down bridging but not shut the link off as in the case of ethernet. Almost any implementation I can find, even old ones, make dot1dStpPortEnable basically shut off the port (ethernet link led goes off). My point is, I don't think this object has been either implemented properly or described properly which is why I asked for it to be deprecated. I'm not sure if any applications are using it either. Comments welcome. Regards, Mike MacFaden _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-admin@ietf.org Fri Aug 24 19:28:34 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 TAA16954 for ; Fri, 24 Aug 2001 19:28:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17684; Fri, 24 Aug 2001 19:24:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17649 for ; Fri, 24 Aug 2001 19:24:20 -0400 (EDT) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16900 for ; Fri, 24 Aug 2001 19:23:01 -0400 (EDT) Received: from mordor.yagosys.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id QAA19674; Fri, 24 Aug 2001 16:23:50 -0700 (PDT) Received: from eire.riverstonenet.com by mordor.yagosys.com (SMI-8.6/SMI-SVR4) id QAA01992; Fri, 24 Aug 2001 16:23:48 -0700 Message-Id: <5.1.0.14.1.20010824161939.00a8b670@mordor.yagosys.com> X-Sender: mrm@mordor.yagosys.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 24 Aug 2001 16:23:41 -0700 To: bridge-mib@ietf.org From: Michael MacFaden Subject: Re: [Bridge-mib] Meeting minutes for the 51st IETF In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org At 04:46 PM 8/24/2001 -0500, you wrote: >d.) Some (many?) implementations permit spanning tree > to be turned off an a per-port basis. Should we > standardize this? > > Many questions were raised about why this would be done > and what the default behavior could be. The group > sought a rationale for doing this, but could not find > one. Therefore no action will be taken. I agree that any new features would recycle the MIB module and in the interest of moving 1493 up in the standards process, no new objects should be added in the SMIv2 rewrite. (Maybe an BRIDGE2-MIB)... The simple rational is that many devices support this feature. Can't we just look at the many existing implementations and compare them to see if they all behave the same way? Should be an easy report to create, maybe Tolly or Meir has one already. Mike _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-admin@ietf.org Sun Aug 26 10:06: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 KAA12759 for ; Sun, 26 Aug 2001 10:06:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13195; Sun, 26 Aug 2001 10:06:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13164 for ; Sun, 26 Aug 2001 10:06:41 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12744 for ; Sun, 26 Aug 2001 10:05:22 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05932 for ; Sun, 26 Aug 2001 10:05:18 -0400 (EDT) Received: from itc-eml1.lannet.com (h149-49-38-51.avaya.com [149.49.38.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05912 for ; Sun, 26 Aug 2001 10:05:07 -0400 (EDT) Received: by ITC-EML1 with Internet Mail Service (5.5.2650.21) id ; Sun, 26 Aug 2001 17:02:42 +0200 Message-ID: <18609D34D984D31183780090279CF7E004BA8A1E@ITC-EML1> From: =?UTF-8?B?RGFuIFJvbWFzY2FudQ==?= To: =?UTF-8?B?J0F5ZXJzLCBNaWtlJw==?= , =?UTF-8?B?J2JyaWRnZS1taWJAaWV0Zi5vcmcn?= Date: Sun, 26 Aug 2001 17:02:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12E40.2272D460" Subject: [Bridge-mib] =?UTF-8?B?UkU6IFtCcmlkZ2UtbWliXSBNZWV0aW5nIG1pbnV0ZXMgZm9yIHRo?= =?UTF-8?B?ZSA1MXN0IElFVEY=?= Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12E40.2272D460 Content-Type: text/plain; charset="UTF-8" > d.) Some (many?) implementations permit spanning tree > to be turned off an a per-port basis. Should we > standardize this? > > Many questions were raised about why this would be done > and what the default behavior could be. The group > sought a rationale for doing this, but could not find > one. Therefore no action will be taken. Because of the unhappy scheduling conflict of the Bridge MIB meeting with another meeting, I could not attend the meeting in London, but I have at least one strong reason in favor of supporting spanning tree per port activation / de-activation. The source of the information is from our Technical Support, who brought the requirement to the attention of our software group. Some customers using Novell clients asked for Spanning Tree to be disabled per port, because on some Novell clients, the blocking state of a port with Spanning Tree enabled and no station connected prevented the clients to connect to their servers. It appears that the timers for the learning mechanism to learn the address and allow the propagation of the client messages to the Novell severs are longer than the timers that allow the client to reach the conclusion that there is no server around, and no appropriate re-trial mechanism is available. This may be enough taking into account the popularity of the Novell environments. In any case, as the activation / de-activation of spanning tree per port seems to be quite wide-spread in implementations, I would suggest that we reverse the decision taken in the meeting. Regards, Dan ------_=_NextPart_001_01C12E40.2272D460 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable RE: [Bridge-mib] Meeting minutes for the 51st IETF

>       =         d.)  Some (many?) = implementations permit spanning tree
>       =         to be turned off an a = per-port basis.  Should we
>       =         standardize this?
>
>       =         Many questions were raised = about why this would be done
>       =         and what the default = behavior could be.  The group
>       =         sought a rationale for doing = this, but could not find
>       =         one.  Therefore no = action will be taken.

Because of the unhappy scheduling conflict of the = Bridge MIB meeting with another meeting, I could not attend the meeting = in London, but I have at least one strong reason in favor of supporting = spanning tree per port activation / de-activation. The source of the = information is from our Technical Support, who brought the requirement = to the attention of our software group. Some customers using Novell = clients asked for Spanning Tree to be disabled per port, because on = some Novell clients, the blocking state of a port with Spanning Tree = enabled and no station connected prevented the clients to connect to = their servers. It appears that the timers for the learning mechanism to = learn the address and allow the propagation of the client messages to = the Novell severs are longer than the timers that allow the client to = reach the conclusion that there is no server around, and no appropriate = re-trial mechanism is available.

This may be enough taking into account the popularity = of the Novell environments. In any case, as the activation / = de-activation of spanning tree per port seems to be quite wide-spread = in implementations, I would suggest that we reverse the decision taken = in the meeting.

Regards,

Dan
  

------_=_NextPart_001_01C12E40.2272D460-- _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-admin@ietf.org Sun Aug 26 10:07: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 KAA12796 for ; Sun, 26 Aug 2001 10:07:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13285; Sun, 26 Aug 2001 10:08:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13253 for ; Sun, 26 Aug 2001 10:08:38 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12789 for ; Sun, 26 Aug 2001 10:07:19 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06203 for ; Sun, 26 Aug 2001 10:07:38 -0400 (EDT) Received: from itc-eml1.lannet.com (h149-49-38-51.avaya.com [149.49.38.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06195 for ; Sun, 26 Aug 2001 10:07:37 -0400 (EDT) Received: by ITC-EML1 with Internet Mail Service (5.5.2650.21) id ; Sun, 26 Aug 2001 17:05:12 +0200 Message-ID: <18609D34D984D31183780090279CF7E004BA8A1F@ITC-EML1> From: =?UTF-8?B?RGFuIFJvbWFzY2FudQ==?= To: =?UTF-8?B?J0F5ZXJzLCBNaWtlJw==?= , =?UTF-8?B?J2JyaWRnZS1taWJAaWV0Zi5vcmcn?= Date: Sun, 26 Aug 2001 17:05:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12E40.80ADE830" Subject: [Bridge-mib] =?UTF-8?B?UkU6IFtCcmlkZ2UtbWliXSBNZWV0aW5nIG1pbnV0ZXMgZm9yIHRo?= =?UTF-8?B?ZSA1MXN0IElFVEY=?= Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12E40.80ADE830 Content-Type: text/plain; charset="UTF-8" > For 802.1x, IEEE wrote their own MIB - should we publish it as > an informational RFC? > > Bert W.: Do we want to? > > Mike A.: We would then have all the bridge docs in one place. > > Les: 802.1x is not just a bridge. > > Bert W.: Then we'd best take this to the mailing list. > I support publishing the 802.1x as an Informational RFC, for the reason mentioned by Mike A. in the meeting. Regards, Dan ------_=_NextPart_001_01C12E40.80ADE830 Content-Type: text/html; charset="UTF-8" RE: [Bridge-mib] Meeting minutes for the 51st IETF

>       For 802.1x, IEEE wrote their own MIB - should we publish it as
>       an informational RFC?
>
>       Bert W.:  Do we want to?
>
>       Mike A.:  We would then have all the bridge docs in one place.
>
>       Les:  802.1x is not just a bridge.
>
>       Bert W.:  Then we'd best take this to the mailing list.
>

I support publishing the 802.1x as an Informational RFC, for the reason mentioned by Mike A. in the meeting.

Regards,

Dan
 

------_=_NextPart_001_01C12E40.80ADE830-- _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From avalanche@netposta.net Tue Aug 28 02:44:17 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28411 for ; Tue, 28 Aug 2001 02:44:17 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7S6LMl23352 for ; Mon, 27 Aug 2001 23:21:22 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f7S6LZY21472 for ; Mon, 27 Aug 2001 23:21:35 -0700 (PDT) Received: from amazon.sscnet.ucla.edu (amazon.sscnet.ucla.edu [128.97.194.29]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f7S6Ik109959 for ; Mon, 27 Aug 2001 23:18:46 -0700 (PDT) Received: by amazon.sscnet.ucla.edu id XAA92815; Mon, 27 Aug 2001 23:14:13 -0700 (PDT) Date: Mon, 27 Aug 2001 23:14:13 -0700 (PDT) Reply-To: From: "avalanche@netposta.net" To: "3302@hurra.de" <3302@hurra.de> Message-ID: <0998983485.0754892759@mx1.netposta.net> Subject: Start Accepting Credit Cards NOW# Cc: bridgcon@aol.com Cc: bridgdawg@aol.com Cc: bridgdilauro@yahoo.com Cc: bridge-boy@msn.com Cc: bridge-comments@java.sun.com Cc: bridge-mib-request@cisco.com Cc: bridge-mib-request@pa.dec.com Cc: bridge-mib@external.cisco.com Cc: bridge.he@mailcity.com Cc: bridge.intl@bridgecompanies.com Cc: bridge.port@usa.net Cc: bridge.wood@virgin.net Cc: bridge03@aol.com Cc: bridge0426@yahoo.com Cc: bridge101@yahoo.com Cc: bridge114@hotmail.com Content-Type: text/plain; charset="us-ascii";format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit mvc9vc We help business owners accept credit cards! Competitive Rates! Below Market Prices! Our approval process is quick and simple! We offer complete processing systems for your business: *Internet *Retail *Mail Order *Phone Order Free information request form: PLEASE VISIT http://www.freewebdirect.net/merchantservices/ **************************************************************** Since you have received this message you have either responded to one of our offers in the past or your address has been registered with us. If you wish to be removed please reply to: mailto:morleads7@yahoo.com?subject=remove **************************************************************** mv9vc * From bridge-mib-admin@ietf.org Tue Aug 28 06:22:35 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 GAA01011 for ; Tue, 28 Aug 2001 06:22:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07919; Tue, 28 Aug 2001 06:23:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07890 for ; Tue, 28 Aug 2001 06:23:27 -0400 (EDT) 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 GAA01007 for ; Tue, 28 Aug 2001 06:22:08 -0400 (EDT) Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.eur.3com.com with ESMTP id f7SAPNZ11405; Tue, 28 Aug 2001 11:25:23 +0100 (BST) Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id f7SAMLh25205; Tue, 28 Aug 2001 11:22:21 +0100 (BST) Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256AB6.00399AC0 ; Tue, 28 Aug 2001 11:29:11 +0100 X-Lotus-FromDomain: 3COM From: "Maurice Goodfellow" To: Dan Romascanu cc: "'Ayers, Mike'" , "'bridge-mib@ietf.org'" Message-ID: <80256AB6.0039989D.00@notesmta.eur.3com.com> Date: Tue, 28 Aug 2001 11:26:29 +0100 Subject: Re: [Bridge-mib] RE: [Bridge-mib] Meeting minutes for the 51st IETF Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=Sy2iiy2WI7JhmiMluXFhFyR8bYCMsRPmHzNxNNZ4C7O10T7q8GWBujlY" Content-Disposition: inline Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org --0__=Sy2iiy2WI7JhmiMluXFhFyR8bYCMsRPmHzNxNNZ4C7O10T7q8GWBujlY Content-type: text/plain; charset=us-ascii Content-Disposition: inline My understanding is that Edge Ports are there in the specification to deal with just this issue. Maurice Dan Romascanu on 26/08/2001 16:02:33 Sent by: Dan Romascanu To: "'Ayers, Mike'" , "'bridge-mib @ietf.org'" cc: (Maurice Goodfellow/GB/3Com) Subject: [Bridge-mib] RE: [Bridge-mib] Meeting minutes for the 51st IETF > d.) Some (many?) implementations permit spanning tree > to be turned off an a per-port basis. Should we > standardize this? > > Many questions were raised about why this would be done > and what the default behavior could be. The group > sought a rationale for doing this, but could not find > one. Therefore no action will be taken. Because of the unhappy scheduling conflict of the Bridge MIB meeting with another meeting, I could not attend the meeting in London, but I have at least one strong reason in favor of supporting spanning tree per port activation / de-activation. The source of the information is from our Technical Support, who brought the requirement to the attention of our software group. Some customers using Novell clients asked for Spanning Tree to be disabled per port, because on some Novell clients, the blocking state of a port with Spanning Tree enabled and no station connected prevented the clients to connect to their servers. It appears that the timers for the learning mechanism to learn the address and allow the propagation of the client messages to the Novell severs are longer than the timers that allow the client to reach the conclusion that there is no server around, and no appropriate re-trial mechanism is available. This may be enough taking into account the popularity of the Novell environments. In any case, as the activation / de-activation of spanning tree per port seems to be quite wide-spread in implementations, I would suggest that we reverse the decision taken in the meeting. Regards, Dan --0__=Sy2iiy2WI7JhmiMluXFhFyR8bYCMsRPmHzNxNNZ4C7O10T7q8GWBujlY Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PVVURi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTEuNjciPg0KPFRJVExFPlJFOiBbQnJpZGdl LW1pYl0gTWVldGluZyBtaW51dGVzIGZvciB0aGUgNTFzdCBJRVRGPC9USVRMRT4NCjwvSEVBRD4N CjxCT0RZPg0KDQo8UD48Rk9OVCBTSVpFPTI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGQuKSZuYnNw OyBTb21lIChtYW55PykgaW1wbGVtZW50YXRpb25zIHBlcm1pdCBzcGFubmluZyB0cmVlPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8gYmUgdHVybmVkIG9m ZiBhbiBhIHBlci1wb3J0IGJhc2lzLiZuYnNwOyBTaG91bGQgd2U8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdGFuZGFyZGl6ZSB0aGlzPzwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBNYW55IHF1ZXN0aW9ucyB3ZXJlIHJhaXNlZCBhYm91dCB3aHkgdGhpcyB3b3Vs ZCBiZSBkb25lPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg YW5kIHdoYXQgdGhlIGRlZmF1bHQgYmVoYXZpb3IgY291bGQgYmUuJm5ic3A7IFRoZSBncm91cDwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNvdWdodCBhIHJh dGlvbmFsZSBmb3IgZG9pbmcgdGhpcywgYnV0IGNvdWxkIG5vdCBmaW5kPC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb25lLiZuYnNwOyBUaGVyZWZvcmUgbm8g YWN0aW9uIHdpbGwgYmUgdGFrZW4uPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+QmVj YXVzZSBvZiB0aGUgdW5oYXBweSBzY2hlZHVsaW5nIGNvbmZsaWN0IG9mIHRoZSBCcmlkZ2UgTUlC IG1lZXRpbmcgd2l0aCBhbm90aGVyIG1lZXRpbmcsIEkgY291bGQgbm90IGF0dGVuZCB0aGUgbWVl dGluZyBpbiBMb25kb24sIGJ1dCBJIGhhdmUgYXQgbGVhc3Qgb25lIHN0cm9uZyByZWFzb24gaW4g ZmF2b3Igb2Ygc3VwcG9ydGluZyBzcGFubmluZyB0cmVlIHBlciBwb3J0IGFjdGl2YXRpb24gLyBk ZS1hY3RpdmF0aW9uLiBUaGUgc291cmNlIG9mIHRoZSBpbmZvcm1hdGlvbiBpcyBmcm9tIG91ciBU ZWNobmljYWwgU3VwcG9ydCwgd2hvIGJyb3VnaHQgdGhlIHJlcXVpcmVtZW50IHRvIHRoZSBhdHRl bnRpb24gb2Ygb3VyIHNvZnR3YXJlIGdyb3VwLiBTb21lIGN1c3RvbWVycyB1c2luZyBOb3ZlbGwg Y2xpZW50cyBhc2tlZCBmb3IgU3Bhbm5pbmcgVHJlZSB0byBiZSBkaXNhYmxlZCBwZXIgcG9ydCwg YmVjYXVzZSBvbiBzb21lIE5vdmVsbCBjbGllbnRzLCB0aGUgYmxvY2tpbmcgc3RhdGUgb2YgYSBw b3J0IHdpdGggU3Bhbm5pbmcgVHJlZSBlbmFibGVkIGFuZCBubyBzdGF0aW9uIGNvbm5lY3RlZCBw cmV2ZW50ZWQgdGhlIGNsaWVudHMgdG8gY29ubmVjdCB0byB0aGVpciBzZXJ2ZXJzLiBJdCBhcHBl YXJzIHRoYXQgdGhlIHRpbWVycyBmb3IgdGhlIGxlYXJuaW5nIG1lY2hhbmlzbSB0byBsZWFybiB0 aGUgYWRkcmVzcyBhbmQgYWxsb3cgdGhlIHByb3BhZ2F0aW9uIG9mIHRoZSBjbGllbnQgbWVzc2Fn ZXMgdG8gdGhlIE5vdmVsbCBzZXZlcnMgYXJlIGxvbmdlciB0aGFuIHRoZSB0aW1lcnMgdGhhdCBh bGxvdyB0aGUgY2xpZW50IHRvIHJlYWNoIHRoZSBjb25jbHVzaW9uIHRoYXQgdGhlcmUgaXMgbm8g c2VydmVyIGFyb3VuZCwgYW5kIG5vIGFwcHJvcHJpYXRlIHJlLXRyaWFsIG1lY2hhbmlzbSBpcyBh dmFpbGFibGUuPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPlRoaXMgbWF5IGJlIGVub3Vn aCB0YWtpbmcgaW50byBhY2NvdW50IHRoZSBwb3B1bGFyaXR5IG9mIHRoZSBOb3ZlbGwgZW52aXJv bm1lbnRzLiBJbiBhbnkgY2FzZSwgYXMgdGhlIGFjdGl2YXRpb24gLyBkZS1hY3RpdmF0aW9uIG9m IHNwYW5uaW5nIHRyZWUgcGVyIHBvcnQgc2VlbXMgdG8gYmUgcXVpdGUgd2lkZS1zcHJlYWQgaW4g aW1wbGVtZW50YXRpb25zLCBJIHdvdWxkIHN1Z2dlc3QgdGhhdCB3ZSByZXZlcnNlIHRoZSBkZWNp c2lvbiB0YWtlbiBpbiB0aGUgbWVldGluZy48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+ UmVnYXJkcyw8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5EYW48L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyA8L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRN TD4= --0__=Sy2iiy2WI7JhmiMluXFhFyR8bYCMsRPmHzNxNNZ4C7O10T7q8GWBujlY-- _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-admin@ietf.org Tue Aug 28 07:31:47 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 HAA04188 for ; Tue, 28 Aug 2001 07:31:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09195; Tue, 28 Aug 2001 07:23:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09162 for ; Tue, 28 Aug 2001 07:23:01 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03489 for ; Tue, 28 Aug 2001 07:21:42 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00179 for ; Tue, 28 Aug 2001 07:22:01 -0400 (EDT) Received: from itc-eml1.lannet.com (h149-49-38-51.avaya.com [149.49.38.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00166 for ; Tue, 28 Aug 2001 07:22:00 -0400 (EDT) Received: by ITC-EML1 with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Aug 2001 14:19:35 +0200 Message-ID: <18609D34D984D31183780090279CF7E004BA8A4E@ITC-EML1> From: Dan Romascanu To: "'Maurice Goodfellow'" Cc: "'Ayers, Mike'" , "'bridge-mib@ietf.org'" Subject: RE: [Bridge-mib] RE: [Bridge-mib] Meeting minutes for the 51st IE TF Date: Tue, 28 Aug 2001 14:19:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12FBB.B27D7200" Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12FBB.B27D7200 Content-Type: text/plain; charset="iso-8859-8" Maurice, The current definition of the edge ports is by two objects in the dot1dStpExtPortTable which contains port-specific Rapid Spanning Tree information. The issue that I am raising is not specific for Rapid Spanning Tree environments. Do you suggest to take the objects referring to Edge ports out of rtspConformance? This might work only if we place the objects in a separate table, and actually it might be the right thing to do because edge ports are defined in 802.1t, and not in 802.1w. Regards, Dan > -----Original Message----- > From: Maurice Goodfellow [mailto:Maurice_Goodfellow@eur.3com.com] > Sent: Tuesday, August 28, 2001 12:26 PM > To: Dan Romascanu > Cc: 'Ayers, Mike'; 'bridge-mib@ietf.org' > Subject: Re: [Bridge-mib] RE: [Bridge-mib] Meeting minutes > for the 51st IETF > > > > > > My understanding is that Edge Ports are there in the > specification to deal with > just this issue. > > Maurice > > > > > > Dan Romascanu on 26/08/2001 16:02:33 > > Sent by: Dan Romascanu > > > To: "'Ayers, Mike'" , "'bridge-mib @ietf.org'" > > cc: (Maurice Goodfellow/GB/3Com) > Subject: [Bridge-mib] RE: [Bridge-mib] Meeting minutes for > the 51st IETF > > > > > > d.) Some (many?) implementations permit spanning tree > > to be turned off an a per-port basis. Should we > > standardize this? > > > > Many questions were raised about why this would be done > > and what the default behavior could be. The group > > sought a rationale for doing this, but could not find > > one. Therefore no action will be taken. > > Because of the unhappy scheduling conflict of the Bridge MIB > meeting with > another meeting, I could not attend the meeting in London, > but I have at > least one strong reason in favor of supporting spanning tree per port > activation / de-activation. The source of the information is from our > Technical Support, who brought the requirement to the attention of our > software group. Some customers using Novell clients asked for > Spanning Tree > to be disabled per port, because on some Novell clients, the > blocking state > of a port with Spanning Tree enabled and no station connected > prevented the > clients to connect to their servers. It appears that the > timers for the > learning mechanism to learn the address and allow the > propagation of the > client messages to the Novell severs are longer than the > timers that allow > the client to reach the conclusion that there is no server > around, and no > appropriate re-trial mechanism is available. > > This may be enough taking into account the popularity of the Novell > environments. In any case, as the activation / de-activation > of spanning > tree per port seems to be quite wide-spread in > implementations, I would > suggest that we reverse the decision taken in the meeting. > > Regards, > > Dan > > > ------_=_NextPart_001_01C12FBB.B27D7200 Content-Type: text/html; charset="iso-8859-8" Content-Transfer-Encoding: quoted-printable RE: [Bridge-mib] RE: [Bridge-mib] Meeting minutes for the 51st = IETF

Maurice,

The current definition of the edge ports is by two = objects in the dot1dStpExtPortTable which contains port-specific Rapid = Spanning Tree information. The issue that I am raising is not specific = for Rapid Spanning Tree environments. Do you suggest to take the = objects referring to Edge ports out of rtspConformance? This might work = only if we place the objects in a separate table, and actually it might = be the right thing to do because edge ports are defined in 802.1t, and = not in 802.1w.

Regards,

Dan




> -----Original Message-----
> From: Maurice Goodfellow [mailto:Maurice_Goodfello= w@eur.3com.com]
> Sent: Tuesday, August 28, 2001 12:26 PM
> To: Dan Romascanu
> Cc: 'Ayers, Mike'; 'bridge-mib@ietf.org'
> Subject: Re: [Bridge-mib] RE: [Bridge-mib] = Meeting minutes
> for the 51st IETF
>
>
>
>
>
> My understanding is that Edge Ports are there = in the
> specification to deal with
> just this issue.
>
> Maurice
>
>
>
>
>
> Dan Romascanu <dromasca@avaya.com> on = 26/08/2001 16:02:33
>
> Sent by:  Dan Romascanu = <dromasca@avaya.com>
>
>
> To:   "'Ayers, Mike'" = <Mike_Ayers@bmc.com>, "'bridge-mib @ietf.org'"
>       = <bridge-mib@ietf.org>
> cc:    (Maurice = Goodfellow/GB/3Com)
> Subject:  [Bridge-mib] RE: [Bridge-mib] = Meeting minutes for
> the 51st IETF
>
>
>
>
> = >         d.)  Some = (many?) implementations permit spanning tree
> = >         to be turned off = an a per-port basis.  Should we
> = >         standardize = this?
> >
> = >         Many questions = were raised about why this would be done
> = >         and what the = default behavior could be.  The group
> = >         sought a rationale = for doing this, but could not find
> = >         one.  = Therefore no action will be taken.
>
> Because of the unhappy scheduling conflict of = the Bridge MIB
> meeting with
> another meeting, I could not attend the meeting = in London,
> but I have at
> least one strong reason in favor of supporting = spanning tree per port
> activation / de-activation. The source of the = information is from our
> Technical Support, who brought the requirement = to the attention of our
> software group. Some customers using Novell = clients asked for
> Spanning Tree
> to be disabled per port, because on some Novell = clients, the
> blocking state
> of a port with Spanning Tree enabled and no = station connected
> prevented the
> clients to connect to their servers. It appears = that the
> timers for the
> learning mechanism to learn the address and = allow the
> propagation of the
> client messages to the Novell severs are longer = than the
> timers that allow
> the client to reach the conclusion that there = is no server
> around, and no
> appropriate re-trial mechanism is = available.
>
> This may be enough taking into account the = popularity of the Novell
> environments. In any case, as the activation / = de-activation
> of spanning
> tree per port seems to be quite wide-spread in =
> implementations, I would
> suggest that we reverse the decision taken in = the meeting.
>
> Regards,
>
> Dan
>
>
>

------_=_NextPart_001_01C12FBB.B27D7200-- _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-admin@ietf.org Tue Aug 28 12:21: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 MAA14702 for ; Tue, 28 Aug 2001 12:21:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18329; Tue, 28 Aug 2001 12:23:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18296 for ; Tue, 28 Aug 2001 12:23:01 -0400 (EDT) Received: from creeper.bmc.com ([63.111.188.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14679 for ; Tue, 28 Aug 2001 12:21:41 -0400 (EDT) Received: from ec02-hou.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f7SGMsQ10421 for ; Tue, 28 Aug 2001 11:22:55 -0500 (CDT) Received: by EC02-HOU.bmc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Aug 2001 11:23:02 -0500 Message-ID: From: "Ayers, Mike" To: "'bridge-mib@ietf.org'" Subject: RE: [Bridge-mib] RE: [Bridge-mib] Meeting minutes for the 51st IE TF Date: Tue, 28 Aug 2001 11:22:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org > From: Dan Romascanu [mailto:dromasca@avaya.com] > Sent: Sunday, August 26, 2001 08:03 AM > > d.) Some (many?) implementations permit > spanning tree > > to be turned off an a per-port basis. Should we > > standardize this? > > > > Many questions were raised about why this > would be done > > and what the default behavior could be. The group > > sought a rationale for doing this, but could not find > > one. Therefore no action will be taken. > > Because of the unhappy scheduling conflict of the Bridge MIB > meeting with another meeting, I could not attend the meeting > in London, but I have at least one strong reason in favor of > supporting spanning tree per port activation / de-activation. > The source of the information is from our Technical Support, > who brought the requirement to the attention of our software > group. Some customers using Novell clients asked for Spanning > Tree to be disabled per port, because on some Novell clients, > the blocking state of a port with Spanning Tree enabled and > no station connected prevented the clients to connect to > their servers. It appears that the timers for the learning > mechanism to learn the address and allow the propagation of > the client messages to the Novell severs are longer than the > timers that allow the client to reach the conclusion that > there is no server around, and no appropriate re-trial > mechanism is available. Why can't this be done with dot1dStpPortEnable? > This may be enough taking into account the popularity of the > Novell environments. In any case, as the activation / > de-activation of spanning tree per port seems to be quite > wide-spread in implementations, I would suggest that we > reverse the decision taken in the meeting. I don't know that it was a decision as such that we made, but we failed to find a champion for the idea. Tag - you're it! /|/|ike _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-admin@ietf.org Tue Aug 28 17:39:00 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 RAA22048 for ; Tue, 28 Aug 2001 17:39:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28179; Tue, 28 Aug 2001 17:40:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28145 for ; Tue, 28 Aug 2001 17:40:05 -0400 (EDT) Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22042 for ; Tue, 28 Aug 2001 17:38:41 -0400 (EDT) Received: from ec02-hou.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id f7SLekU13849 for ; Tue, 28 Aug 2001 16:40:46 -0500 (CDT) Received: by EC02-HOU.bmc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Aug 2001 16:39:27 -0500 Message-ID: From: "Ayers, Mike" To: "'bridge-mib@ietf.org'" Subject: RE: [Bridge-mib] Meeting minutes for the 51st IETF Date: Tue, 28 Aug 2001 16:39:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org > From: Michael MacFaden [mailto:mrm@riverstonenet.com] > Sent: Friday, August 24, 2001 04:19 PM > > At 04:46 PM 8/24/2001 -0500, Ayers, Mike wrote: > > c.) Is dot1dStdPortEnable redundant? > > > > Mike A.: No, a port may not have a unique ifIndex. > > > > dot1dStdPortEnable remains. > > Due to the rather poor scheduling of the bridge and entity > working groups, > I wasn't able to discuss this in London. > > Since most modern ethernet switches as opposed to old repeaters have > a one for one mapping from dot1d to ifIndex, That's news to me. I looked at one of our bridges, and it does seem to create an internal VLAN, perhaps to this purpose, but I do not believe that all equipment does this. In fact, when I was building a simulation network last year, I discovered this to be (apparently) the minority case. The two methods that we confirmed as used in the field were: 1.) All ports bound to a single ifIndex, which represented the IP address (and corresponding single ethernet address, realized on all ports) of the bridge's management agent. 2.) A single listed ifIndex, the same as (1). However, the dot1dBasePortIfIndex objects would start at that object and increment, pointing to nonexistent ifIndex entries. This seemed (still seems) wierd, but we saw it in use, apparently (I didn't personally confirm this one). Note: action item done! > the following > situations arise > which I think lead to implementation/interoperability problems: > > Consider these two case: > a) port both bridges and routes > b) port bridges only > > 1) When ifAdminStatus is set to down, what should dot1dStpPortEnable? > Probably up (bridging could occur, but underlying port is > shut down), Correction: the underlying port is fully operational, but no traffic is being sent to it or received on it because the interface to it is shut down. > 2) When dot1dStpPort is set to disabled, what should > ifAdminStatus report? Up or down, whatever it is set to. It will try and fail to pass packets along and listen for packets that never arrive - the same thing happens when you pull the cable. > In case a), I can see this object as a means to only stop > bridging on a port > w/out affecting routing or ifAdminStatus. Yet most devices > I've tested have this object > shut down the entire port like ifAdminStatus for both > bridging and routing > and if I recall some of them set ifAdminStatus to down. I don't see bad implementations as a case for removing an object. I concede, however, that a critical mass of bad implementations can render an object useless - so I see (but not necessarily concede) your point for depracation. > In case b), the behavior I susepect is to only shut down > bridging but not > shut the link off as in the case of ethernet. I would expect the link to be shut down by dot1dStpPortEnable in all cases. > Almost any implementation I can find, even old ones, make > dot1dStpPortEnable > basically shut off the port (ethernet link led goes off). Yep - that's what I expect. > My point is, I don't think this object has been either > implemented properly > or described properly which is why I asked for it to be > deprecated. I'm not > sure if any applications are using it either. Ah, but we'd really need to confirm that applications are not using - and that isn't really possible. Unsolicited opinion: It seems that whenever we find ourselves deep in some muck or other of confused, possibly incompatible implementations, we can look back and find a lot of assumptions in our wake. It can also be difficult, looking back, to understand why we once felt that terms like "port", "interface", and "enable" didn't need definitions. Fun with myopia... /|/|ike _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-admin@ietf.org Wed Aug 29 08:03:24 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 IAA21767 for ; Wed, 29 Aug 2001 08:03:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00098; Wed, 29 Aug 2001 08:04:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00065 for ; Wed, 29 Aug 2001 08:04:23 -0400 (EDT) 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 IAA21763 for ; Wed, 29 Aug 2001 08:03:02 -0400 (EDT) Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.eur.3com.com with ESMTP id f7TC6LZ27485; Wed, 29 Aug 2001 13:06:21 +0100 (BST) Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id f7TC3Kh09581; Wed, 29 Aug 2001 13:03:20 +0100 (BST) Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256AB7.0042DBC3 ; Wed, 29 Aug 2001 13:10:16 +0100 X-Lotus-FromDomain: 3COM From: "Les Bell" To: Dan Romascanu cc: "'bridge-mib@ietf.org'" Message-ID: <80256AB7.0042DACB.00@notesmta.eur.3com.com> Date: Wed, 29 Aug 2001 13:01:51 +0100 Subject: Re: [Bridge-mib] RE: [Bridge-mib] Meeting minutes for the 51st IETF Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org The Rapid Spanning Tree Protocol (RSTP) with "Edge Port" configuration enabled for the Novell client ports will solve this problem, while still allowing detection of loops created by users 'accidently' plugging another switch into the port instead of a host. RSTP allows an Edge Port to go to the forwarding state immediately, blocking it again, if required, as indicated by any received BPDUs on that port. Legacy STP implementations could mimic this behaviour. This allows the Novell client on an Edge Port to get a timely response, while still protecting the network against inadvertent loops. The problem with disabling STP/RSTP on a per port basis is how to define the behaviour of the port when it is disabled. Does the port still act as a Bridge port? Or does it act as a Repeater port? If you flood the STP BPDUs received on that port, you cannot rely on simple hardware flooding, as this will be limited to the VLAN defined by the PVID for the port, as it is an untagged frame, and some loops will not be detected. If you filter the STP BPDUs received on that port, as a Bridge is supposed to, loops will not be detected. Some (third party) hardware architectures that I have come across do not allow individual addresses from the Bridge reserved Address range to be enabled (forwarded to the CPU only) and disabled (flooded, like user data frames, within VLAN constraints) independently. Thus disabling STP blindly will cause problems for other protocols. * GVRP BPDUs, like STP and RSTP BPDUs would need to be flooded across all VLANs. * GMRP BPDUs would need to be flooded within the VLAN constraints. * If we flood LACPDUs we will make a full duplex port behave like a shared media, which will cause constant churning and LACP will not enable the port. * 802.3 Pause frames should never be flooded. * Port Access Entity (PAE) control frames for Network Login should never be flooded. I guess there are other aspects of the Bridge behaviour that need to be considered that I have not listed. In conclusion, I would suggest the Edge Port behaviour defined in 802.1t and 802.1w is a simple solution, which has fewer implications on other aspects of Bridge behaviour. Les... Dan Romascanu on 26/08/2001 16:02:33 Sent by: Dan Romascanu To: "'Ayers, Mike'" , "'bridge-mib @ietf.org'" cc: (Les Bell/GB/3Com) Subject: [Bridge-mib] RE: [Bridge-mib] Meeting minutes for the 51st IETF > d.) Some (many?) implementations permit spanning tree > to be turned off an a per-port basis. Should we > standardize this? > > Many questions were raised about why this would be done > and what the default behavior could be. The group > sought a rationale for doing this, but could not find > one. Therefore no action will be taken. Because of the unhappy scheduling conflict of the Bridge MIB meeting with another meeting, I could not attend the meeting in London, but I have at least one strong reason in favor of supporting spanning tree per port activation / de-activation. The source of the information is from our Technical Support, who brought the requirement to the attention of our software group. Some customers using Novell clients asked for Spanning Tree to be disabled per port, because on some Novell clients, the blocking state of a port with Spanning Tree enabled and no station connected prevented the clients to connect to their servers. It appears that the timers for the learning mechanism to learn the address and allow the propagation of the client messages to the Novell severs are longer than the timers that allow the client to reach the conclusion that there is no server around, and no appropriate re-trial mechanism is available. This may be enough taking into account the popularity of the Novell environments. In any case, as the activation / de-activation of spanning tree per port seems to be quite wide-spread in implementations, I would suggest that we reverse the decision taken in the meeting. Regards, Dan _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-admin@ietf.org Wed Aug 29 08:07:23 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 IAA21858 for ; Wed, 29 Aug 2001 08:07:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00234; Wed, 29 Aug 2001 08:08:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00198 for ; Wed, 29 Aug 2001 08:08:25 -0400 (EDT) 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 IAA21854 for ; Wed, 29 Aug 2001 08:07:04 -0400 (EDT) Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.eur.3com.com with ESMTP id f7TCAQZ27739; Wed, 29 Aug 2001 13:10:26 +0100 (BST) Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id f7TC7Ph09836; Wed, 29 Aug 2001 13:07:25 +0100 (BST) Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256AB7.00433B85 ; Wed, 29 Aug 2001 13:14:21 +0100 X-Lotus-FromDomain: 3COM From: "Les Bell" To: Dan Romascanu cc: "'bridge-mib@ietf.org'" Message-ID: <80256AB7.00433AB7.00@notesmta.eur.3com.com> Date: Wed, 29 Aug 2001 13:05:57 +0100 Subject: Re: [Bridge-mib] RE: [Bridge-mib] Meeting minutes for the 51st IETF Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=N9sqEBR2MSflpasZEBn3az6DOxGKx3gHF0Ls8pbYCPAZzuOZJNl6wwDp" Content-Disposition: inline Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org --0__=N9sqEBR2MSflpasZEBn3az6DOxGKx3gHF0Ls8pbYCPAZzuOZJNl6wwDp Content-type: text/plain; charset=us-ascii Content-Disposition: inline My preference is to publish this as an Informational RFC, but we must ensure that the IEEE 802.1X document is referenced as the definitive source for this MIB and to re-publish it if IEEE 802.1 update the MIB in future revisions of that standard. Les... Dan Romascanu on 26/08/2001 16:05:11 Sent by: Dan Romascanu To: "'Ayers, Mike'" , "'bridge-mib @ietf.org'" cc: (Les Bell/GB/3Com) Subject: [Bridge-mib] RE: [Bridge-mib] Meeting minutes for the 51st IETF > For 802.1x, IEEE wrote their own MIB - should we publish it as > an informational RFC? > > Bert W.: Do we want to? > > Mike A.: We would then have all the bridge docs in one place. > > Les: 802.1x is not just a bridge. > > Bert W.: Then we'd best take this to the mailing list. > I support publishing the 802.1x as an Informational RFC, for the reason mentioned by Mike A. in the meeting. Regards, Dan --0__=N9sqEBR2MSflpasZEBn3az6DOxGKx3gHF0Ls8pbYCPAZzuOZJNl6wwDp Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PVVURi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTEuNjciPg0KPFRJVExFPlJFOiBbQnJpZGdl LW1pYl0gTWVldGluZyBtaW51dGVzIGZvciB0aGUgNTFzdCBJRVRGPC9USVRMRT4NCjwvSEVBRD4N CjxCT0RZPg0KDQo8UD48Rk9OVCBTSVpFPTI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgRm9yIDgwMi4xeCwgSUVFRSB3cm90ZSB0aGVpciBvd24gTUlCIC0gc2hvdWxkIHdlIHB1 Ymxpc2ggaXQgYXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGFuIGluZm9ybWF0aW9uYWwgUkZDPzwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEJlcnQgVy46Jm5ic3A7IERvIHdlIHdhbnQgdG8/PC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTWlrZSBBLjombmJzcDsgV2Ugd291bGQgdGhlbiBoYXZl IGFsbCB0aGUgYnJpZGdlIGRvY3MgaW4gb25lIHBsYWNlLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IExlczombmJzcDsgODAyLjF4IGlzIG5vdCBqdXN0IGEgYnJpZGdlLjwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlcnQgVy46Jm5ic3A7IFRoZW4gd2UnZCBi ZXN0IHRha2UgdGhpcyB0byB0aGUgbWFpbGluZyBsaXN0LjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+Jmd0OzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkkgc3VwcG9ydCBwdWJsaXNo aW5nIHRoZSA4MDIuMXggYXMgYW4gSW5mb3JtYXRpb25hbCBSRkMsIGZvciB0aGUgcmVhc29uIG1l bnRpb25lZCBieSBNaWtlIEEuIGluIHRoZSBtZWV0aW5nLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZP TlQgU0laRT0yPlJlZ2FyZHMsPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+RGFuPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDs8L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwv SFRNTD4NCg== --0__=N9sqEBR2MSflpasZEBn3az6DOxGKx3gHF0Ls8pbYCPAZzuOZJNl6wwDp-- _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-admin@ietf.org Wed Aug 29 14:20:16 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 OAA05143 for ; Wed, 29 Aug 2001 14:20:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11633; Wed, 29 Aug 2001 14:21:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11600 for ; Wed, 29 Aug 2001 14:21:22 -0400 (EDT) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05140 for ; Wed, 29 Aug 2001 14:20:01 -0400 (EDT) Received: from mordor.yagosys.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id LAA14748; Wed, 29 Aug 2001 11:20:50 -0700 (PDT) Received: from eire.riverstonenet.com by mordor.yagosys.com (SMI-8.6/SMI-SVR4) id LAA13154; Wed, 29 Aug 2001 11:20:49 -0700 Message-Id: <5.1.0.14.1.20010829102415.00a1d140@mordor.yagosys.com> X-Sender: mrm@mordor.yagosys.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 29 Aug 2001 11:20:46 -0700 To: bridge-mib@ietf.org From: Michael MacFaden Subject: Re: [Bridge-mib] RE: [Bridge-mib] Meeting minutes for the 51st IETF In-Reply-To: <80256AB7.0042DACB.00@notesmta.eur.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org Les writes: >The problem with disabling STP/RSTP on a per port basis is how to define >the behaviour of the port when it is disabled. > > Does the port still act as a Bridge port? > Or does it act as a Repeater port? Can you be more specific? I assume these definitions: A repeater is a physical layer function that just amplifies a signal. A bridge port parses the frame and resends it either cut-through or store/forward to one or more ports. I don't see how turning off stp would change this physical port behavior. >If you filter the STP BPDUs received on that port, as a Bridge is >supposed to, loops will not be detected. Why not let the operator decide if that is going to be a problem or not. Also, please consider these cases: 1) Take two physical ports that are bridging. Next combine them into a Link Aggregation. What should the effect be on the existing instances in the dot1dBasePortTable? (Keep or remove?) 2) Take a port that bridges traffic within its assigned vlan. Change it to protocol based vlan and possibly add an ip interface to route to other vlans as is possible with most l2/l3 switch routers. The switch still bridges traffic within the vlan but STP may or may not be running. Basic frame inspection, learning, forwarding and flooding still work without stp. Should the port continue to exist in the dot1dBasePorTable if it is capable of bridging but not currently running STP even though it still bridges IP packets that transit (src/dest) on the subnet/vlan set of ports found on that bridge? Turning on/off stp on a given port/interface should be a standard feature just like all other control protocols in use: ospf, isis, bgp. Even if it causes loops. Mike At 01:01 PM 8/29/2001 +0100, you wrote: >In conclusion, I would suggest the Edge Port behaviour defined in 802.1t >and 802.1w is a simple solution, which has fewer implications on other >aspects of Bridge behaviour. _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-admin@ietf.org Fri Aug 31 02:36: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 CAA25795 for ; Fri, 31 Aug 2001 02:36:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA03145; Fri, 31 Aug 2001 02:37:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA03114 for ; Fri, 31 Aug 2001 02:37:36 -0400 (EDT) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25792 for ; Fri, 31 Aug 2001 02:36:16 -0400 (EDT) Received: from mordor.yagosys.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id XAA21061; Thu, 30 Aug 2001 23:36:51 -0700 (PDT) Received: by mordor.yagosys.com (SMI-8.6/SMI-SVR4) id XAA21244; Thu, 30 Aug 2001 23:36:50 -0700 Date: Thu, 30 Aug 2001 23:36:50 -0700 Message-Id: <200108310636.XAA21244@mordor.yagosys.com> From: Mike MacFaden To: bridge-mib@ietf.org Reply-to: mrm@riverstonenet.com Subject: [Bridge-mib] RFC 1473 dot1dStpPortEnable is not well specified Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org Folks, I did some testing to see if dot1dStpPortEnable is well specified or not. I choose the following set of widely available, modular, well known layer 2 bridging platforms with layer 3 capability that have dot1dStpPortEnable and ifAdminStatus objects. The sysDescr's from the systems tested: Cisco Systems WS-C6509-NEB Cisco Catalyst Operating System Software, Version 6.1(1d) Extreme MSM64 - Version 6.1.7 (Build 9) by Release_Master Thu 04/05/2001 3:40p Foundry Networks, Inc. Router, IronWare Version 07.2.02T51 Riverstone Networks Firmware Version: 7.0.0.1 Cisco 6509: 1. What is in dot1dBasePortTable? By default, all ethernet ports included. dot1dBasePortIfIndex points to unique ifIndexes, one per port. ifTable has vlans (contrary to rfc 2674, populate the ifTable as propVirtual) ifDescr.61 = VLAN 1002. No rfc 2674 dot1q tables GigE ports ifType contrary to rfc 2665, set ifType to 117 instead of 6. no ifStackTable 2. What does ifAdminStatus affect when set to 2(down)? a) Physical link is disabled (LED turns yellow) b) dot1dStpPortEnable is set to disabled(2). 3. What does dot1dStpPortEnable affect when set to 2(disable) Behaves the exactly same behavior as ifAdminStatus, ifAdminStatus is affected. I ran these set/get operations after dumping the ifTable, ifStackTable (if any) and dot1dBasePortTable to determine indexing for a given ethernet port to twiddle with. Detail for cisco cat: % setany box ifAdminStatus.260 1 ifAdminStatus.260 = up(1) % getmany ... ifAdminStatus.260 = up(1) ifOperStatus.260 = up(1) dot1dStpPortEnable.228 = enabled(1) ifName.260 = 4/36 % setany box dot1dStpPortEnable.228 2 dot1dStpPortEnable.228 = disabled(2) % getmany ... ifAdminStatus.260 = down(2) ifOperStatus.260 = down(2) dot1dStpPortEnable.228 = disabled(2) ifName.260 = 4/36 Extreme: 1. What is in dot1dBasePortTable? All ethernet ports that are actually running stp are included. dot1dBasePortIfIndex points to unique ifIndexes, one per port. Vlans (contrary to rfc 2674, populate the ifTable as propVirtual) ifDescr.20002 = VLAN 00001 (Default) ifName reported in ifXtable is not the same as what one uses in CLI 1/1 vs 1:1 ifStackTable malformed per rfc2863, missing terminator "0" entries like : ifStackStatus.0.x=active, ifStackTable used to relate ports to vlans (vlans being the lower layer). No rfc 2674 dot1q tables. GigE/FastE ports ifType all are ifType 6 per rfc 2665. 2. What does ifAdminStatus affect when set to 2(down)? a) Physical link is slowly blinks a green led, remote end of the fast ethernet link reports link as physically up b) dot1dStpPortEnable is not affected 3. What does dot1dStpPortEnable affect when set to 2(disable) Turns of STP per port. ifAdminStatus not affected CLI shows stp per port as ENABLED | DISABLED * MSM64:32 # show stpd s0 ports 3:25 Stpd: s0 Port: 3:25 PortId: 2099 Stp: DISABLED Path Cost: 19 ------------- The Extreme manual is very clear about what it means to turn off STP per port: port put into forwarding state, BPDU's received are disregarded cli cmd: disable stp port Foundry: 1. What is in dot1dBasePortTable? All ethernet ports included. dot1dBasePortIfIndex points to unique ifIndexes, one per port. No ifXTable, no ifStackTable, probably an enterprise mib mod relates ports/vlans GigE/FE ports ifType all are ifType 7, contrary to rfc 2665. Complies with rfc 2674, No Vlans in ifTable 2. What does ifAdminStatus affect when set to 2(down)? a) Physical link is shutdown, link LED powered off end of the fast ethernet link reports link as physically down b) dot1dStpPortEnable is not affected 3. What does dot1dStpPortEnable affect when set to 2(disable) Turns of STP per port. ifAdminStatus is no affected The CLI shows stp per port as ON | OFF RT-NetIron Router#show int e8/1 FastEthernet8/1 is up, line protocol is up Hardware is FastEthernet, address is 0004.8016.80e0 (bia 0004.8016.80e0) Configured speed auto, actual 100Mbit, configured duplex fdx, actual fdx Member of L2 VLAN ID 1, port is untagged, port state is FORWARDING STP configured to ON, priority is level0, flow control enabled -------------------- Riverstone: 1. What is in dot1dBasePortTable? All ethernet ports included. dot1dBasePortIfIndex points to unique ifIndexes, one per port. Vlans (contrary to rfc 2674, populate the ifTable as propVirtual), Ports are related to vlans via a) ifStackTable, b) dot1qVlanCurrent(Static)Table ifDescr.19 = VLAN: DEFAULT, ifType ifType.19 = l2vlan(135) ports being the lower layer. GigE/FastE ports ifType all are ifType 6 per rfc 2665. 2. What does ifAdminStatus affect when set to 2(down)? a) Physical link is LED stays up end of the fast ethernet link reports link as physically up b) dot1dStpPortEnable is not affected 3. What does dot1dStpPortEnable affect when set to 2(disable) Returns noSuch, agent-cap mib module states does not support sets on this object. CLI allows one to turn on/off STP per port via the cmd: stp enable port ifAdminStatus is not affected So I strongly suggest the revised BRIDGE-MIB receive more than just and SMIv2 facelift. Some text is needed to explain what the objects should really be doing and future mib modules should standardize what the marketplace has generally implemented. Mike MacFaden _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-admin@ietf.org Fri Aug 31 13:28:33 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 NAA11328 for ; Fri, 31 Aug 2001 13:28:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19851; Fri, 31 Aug 2001 13:29:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19819 for ; Fri, 31 Aug 2001 13:29:31 -0400 (EDT) Received: from creeper.bmc.com ([63.111.188.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11299 for ; Fri, 31 Aug 2001 13:28:09 -0400 (EDT) Received: from ec03-hou.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f7VHTMh26490 for ; Fri, 31 Aug 2001 12:29:22 -0500 (CDT) Received: by ec03-hou.bmc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 Aug 2001 12:29:11 -0500 Message-ID: From: "Ayers, Mike" To: bridge-mib@ietf.org Subject: RE: [Bridge-mib] RFC 1473 dot1dStpPortEnable is not well specifie d Date: Fri, 31 Aug 2001 12:29:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org > From: Mike MacFaden [mailto:mrm@riverstonenet.com] > Sent: Thursday, August 30, 2001 11:37 PM > So I strongly suggest the revised BRIDGE-MIB receive more than > just and SMIv2 facelift. Some text is needed to explain what > the objects > should really be doing and future mib modules should standardize what > the marketplace has generally implemented. I agree. However, I don't think we can standardize what the marketplace has implemented when their implementations are so far apart. /|/|ike _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-admin@ietf.org Fri Aug 31 14:17:53 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 OAA12652 for ; Fri, 31 Aug 2001 14:17:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21190; Fri, 31 Aug 2001 14:19:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21153 for ; Fri, 31 Aug 2001 14:19:01 -0400 (EDT) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12632 for ; Fri, 31 Aug 2001 14:17:38 -0400 (EDT) Received: from mordor.yagosys.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id LAA00079; Fri, 31 Aug 2001 11:18:29 -0700 (PDT) Received: from agile.riverstonenet.com by mordor.yagosys.com (SMI-8.6/SMI-SVR4) id LAA21724; Fri, 31 Aug 2001 11:18:28 -0700 Message-Id: <5.1.0.14.1.20010831111222.00a354d0@mordor.yagosys.com> X-Sender: mrm@mordor.yagosys.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 31 Aug 2001 11:18:23 -0700 To: bridge-mib@ietf.org From: Michael MacFaden Subject: RE: [Bridge-mib] RFC 1473 dot1dStpPortEnable is not well specifie d In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org At 12:29 PM 8/31/2001 -0500, you wrote: >I agree. However, I don't think we can standardize what the >marketplace has implemented when their implementations are so far apart. I don't think from the data I collected they were "far apart" actually. Can you elaborate? Three of the four brouters allow for STP to be turned off. The behavior for what happens when STP is turned of is the same for all three. dot1dStpPortEnable should be clarified as to what the relationship with ifAdminStatus is in various configurations. Port Membership in dot1dBasePortTable also needs to be clarified. The ifAdminStatus behavior could easily be resolved. There really is *one* right answer for turning ifAdminStatus to down(2) for an ifType of 6. Updates to RFC 2665 should clarify that behavior. Mike MacFaden _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-admin@ietf.org Fri Aug 31 14:51: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 OAA13499 for ; Fri, 31 Aug 2001 14:51:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21880; Fri, 31 Aug 2001 14:52:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21848 for ; Fri, 31 Aug 2001 14:52:48 -0400 (EDT) Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13494 for ; Fri, 31 Aug 2001 14:51:26 -0400 (EDT) Received: from ec02-hou.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id f7VIrb904805 for ; Fri, 31 Aug 2001 13:53:37 -0500 (CDT) Received: by EC02-HOU.bmc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 Aug 2001 13:52:16 -0500 Message-ID: From: "Ayers, Mike" To: bridge-mib@ietf.org Subject: RE: [Bridge-mib] RFC 1473 dot1dStpPortEnable is not well specifie d Date: Fri, 31 Aug 2001 13:51:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: bridge-mib-admin@ietf.org Errors-To: bridge-mib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: bridge-mib@ietf.org > From: Michael MacFaden [mailto:mrm@riverstonenet.com] > Sent: Friday, August 31, 2001 11:18 AM > At 12:29 PM 8/31/2001 -0500, you wrote: > >I agree. However, I don't think we can standardize what the > >marketplace has implemented when their implementations are > so far apart. > > I don't think from the data I collected they were "far apart" > actually. > Can you elaborate? > > Three of the four brouters allow for STP to be turned off. Not really. Two use dot1dStpPortEnable to turn off STP. One uses it to turn off the port. One does not permit its use. That seems far apart to me, since I do not interpret shutting down the port as turning off STP, even though that is a side effect of it. > The behavior > for what happens when STP is turned of is the same for all three. > dot1dStpPortEnable should be clarified as to what the relationship > with ifAdminStatus is in various configurations. Given the evidence, I must agree that this would be necessary, although without evidence, I would not have thought so. > Port Membership in dot1dBasePortTable also needs to be clarified. Please elaborate. > The ifAdminStatus behavior could easily be resolved. There > really is *one* right > answer for turning ifAdminStatus to down(2) for an ifType of 6. Agreed, and, I think, never in question. /|/|ike > Updates to RFC 2665 should clarify that behavior. > > Mike MacFaden > > > _______________________________________________ > 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