[LinkSec] RE: [802.1] Fwd: Re: IESG question on Ethernet related to-be-RFC
The basic rationale for EAPS is that it's scope is limited to a ring of
switches (which is considered an advantage by some and a disadvantage by
others), and it's re-convergence time is independendent of the number of
switches in the ring. If this is misleading relative to RSTP then we would
certainly be willing to rephrase that the convergence times would be roughly
equivalent for similar implementations on small rings. The point is simply
that EAPS has an advantage for a very specific topology -- a large ring of
Ethernet switches -- that happens to be very important for some people even
though it is not a general solution as is RSTP.
Please keep in mind that this was submitted as an Informational RFC for
exactly the intended purpose of Informational RFC's as stated by Erik in his
letter to the IEEE below: "provide documentation of proprietary solutions".
Erik's question to the IEEE was whether the document conflicts with ongoing
standardization activies. I don't believe that EAPS conflicts with RSTP, or
for that matter with RPR, because it has a significantly different scope
than either. RSTP provides rapid reconfiguration for an arbitrary topology,
whereas EAPS is optimized for (and only operates in) a very specific
topology. While RPR is targeted at ring topologies, it is defining an
entire new MAC which is quite different than a control protocol running on
top of an existing MAC.
Steve
-----Original Message-----
From: Mick Seaman [mailto:mick_seaman@ieee.org]
Sent: Tuesday, June 10, 2003 9:51 AM
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
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 advertised
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