Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Forwarding Mick's message. The original message bounced due to the word "adver_tised". ----- Original Message ----- > From: "Mick Seaman" <mick_seaman@ieee.org> > To: <stds-802-1@ieee.org>, <stds-802-linksec@ieee.org> > Cc: <tak@cisco.com>, <bob.grow@ieee.org> > Subject: RE: [802.1] Fwd: Re: IESG question on Ethernet related to-be-RFC > Date: Tue, 10 Jun 2003 09:51:00 -0700 > Message-ID: <001101c32f70$7bbf40c0$210110ac@corp.telseon.com> > > > The proposed Informational RFC (EAPS - Ethernet Protection Switching) is > more than a little misleading when it claims as its basic rationale: > > "Also, most MAN operators want to minimise the recovery time in > the event a fibre cut occurs. The Spanning Tree Protocol can take as > long as 40 seconds to converge in the event of a topology change. The > newer Rapid Spanning Tree Protocol is considerably faster. However, its > convergence time is still dependent upon the number of nodes in the ring. > Both STP and RSTP limit the number of nodes in the ring. The Ethernet > Automatic Protection Switching (EAPS) technology described here > converges in less than one second, often in less than 100 milliseconds. > EAPS technology does not limit the number of nodes in the ring, and the > convergence time is independent of the number of nodes." > > Good shipping implementations of RSTP (Rapid Spanning Tree Protocol) achieve > around 200 milliseconds convergence time in typical networks of general (not > limited to ring) topology, and the protocol is quite capable of achieving 1 > millisecond per node convergence in rings with current in place technology. > The practical limit today is probably being set by the rate of detection of > a single link down in the first place. Beyond that the theoretical limit is > 2*light propagation speed. > > Since EAPS has to be implemented at every node to obtain the adver_tised > benefit, quoting old Spanning Tree Protocol timing should be irrelevant, > this has nothing to do with the installed customer base, just to do with > what is implemented on switches in the ring. > > Part of the operation of EAPS appears to be indiscrimnate flushing of bridge > forwarding databases. If the proposed polling schemem is rapid enough to out > perform local detection it has the potential of turning temporary network > overload (loss of poll frame) into network collapse (loss of control frame > and much data as all filtering databases are flushed). > > Mick > > > > > > > > > > > -----Original Message----- > From: owner-stds-802-1@majordomo.ieee.org > [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Tony Jeffree > Sent: Tuesday, June 10, 2003 6:38 AM > To: stds-802-1@ieee.org; stds-802-linksec@ieee.org > Subject: [802.1] Fwd: Re: IESG question on Ethernet related to-be-RFC > > > > F.Y.I. > > Please feed any comments on this to the list. > > Regards, > Tony > > > > >Envelope-to: tony@jeffree.co.uk > >Reply-To: "Paul Nikolich" <p.nikolich@ieee.org> > >From: "Paul Nikolich" <paul.nikolich@att.net> > >To: "Erik Nordmark" <Erik.Nordmark@sun.com>, > > <p.nikolich@ieee.org>, > > "Tony Jeffree" <tony@jeffree.co.uk>, > > "Mike Takefman" <tak@cisco.com>, > > <bob.grow@ieee.org> > >Cc: <erik.nordmark@sun.com> > >Subject: Re: IESG question on Ethernet related to-be-RFC > >Date: Tue, 10 Jun 2003 08:30:06 -0400 > >X-Mailer: Microsoft Outlook Express 6.00.2800.1158 > > > >Erik, > > > >Via this email, I will ask the chairs of the Working Groups most likely to > >be affected by this work (Tony Jeffree 802.1, Bob Grow 802.3 and Mike > >Takefman 802.17) to look at the RFC and provide comment to you. Our next > >plenary session is scheduled for the week of July 21st, so it will be a > >while before any 'official' feedback can be provided. In the interim, > >perhaps Tony, Bob, or Mike can provide 'un-official' feedback--I will > leave > >it up to them. > > > >Tony, Bob, Mike--please review the below referenced document and, if > >appropriate, put it on your agenda for discussion in July. Also, if > another > >WG in 802 should be included in the review/comment that I missed, please > let > >me know and I'll give them instructions to review it. > > > >Regards, > > > >--Paul Nikolich > >Chairman, IEEE 802 > > > >----- Original Message ----- > >From: "Erik Nordmark" <Erik.Nordmark@sun.com> > >To: <p.nikolich@ieee.org> > >Cc: <erik.nordmark@sun.com> > >Sent: Monday, June 09, 2003 4:47 PM > >Subject: IESG question on Ethernet related to-be-RFC > > > > > > > > > > Paul, > > > I'm one of the IETF Area Directors and Russ Housley suggested I contact > >you. > > > > > > The issue is a document which the IESG has on its plate: > > > http://www.ietf.org/internet-drafts/draft-shah-extreme-eaps-03.txt > > > > > > The authors have requested by the RFC editor that this be published as > > > an INFORMATIONAL RFC and the RFC editor has asked the IESG whether > > > this conflicts with any active work in the IETF. > > > Since the document is about "Ethernet protection switching" it > > > makes sense for the IESG to ask your advise. > > > > > > If case you are not aware of the RFC editor and informational document > > > it is worth-while for me to mention that the RFC editor routinely > >publishes > > > informational and experimental RFCs that are unrelated to the > >standardization > > > activities in the IETF. > > > Some of these provide documentation of proprietary solutions, as is > > > the case in hand. An older example of such a document is RFC 1761. > > > > > > Note that the IESG can only provide advise to the RFC editor, which will > > > make their independent evaluation. > > > But in any case, the IESG is interested in the opinion of IEEE 802 > > > whether this document would conflict with ongoing standardization > >activities. > > > > > > Sincerely, > > > Erik Nordmark > > > > > Regards, > Tony > > > >