[LinkSec] Fw: BOUNCE stds-802-linksec@majordomo.ieee.org: taboo body match "/Advertis/i" at line 24
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
>
>
>
>