[RPRWG] RE: [802.1] Fwd: Re: IESG question on Ethernet related to-be-RFC
Hi Mike,
One could make that argument, and you would know better than I how strong of
an argument it is. It seems to me that there is a fundamental difference
between two MACs connected by a 802.1 bridge relay and two physical
interfaces connected to a single MAC with a single connection to a bridge or
host. I would think this difference would have to be accomodated in any
topology or protection protocol -- certainly both wrapping and steering
would be viewed somewhat differently in each case. I wasn't aware that
802.17 felt it was in scope to define protocols running between any two
arbitrary MACs on a bridge, and I'd be very surprised if the group really
wanted to undertake that particular distraction. Even if you did, we'd be
back to the discussion of this being an Informational RFC for the purposes
of providing open documentation of a proprietary solution. That said, I'll
be happy to discuss this in the WG in July as you see fit.
Steve
-----Original Message-----
From: Mike Takefman [mailto:tak@xxxxxxxxx]
Sent: Thursday, June 12, 2003 7:25 AM
To: mick_seaman@xxxxxxxx
Cc: 'Steve Haddock'; stds-802-1@xxxxxxxx; bob.grow@xxxxxxxx; RPRWG
Subject: Re: [802.1] Fwd: Re: IESG question on Ethernet related
to-be-RFC
Steve,
one could argue that the topology and protection protocols
for RPR could run on any MAC. As our project is defining
a MAC, we obviously targetted the dot17 one. It is
clear to me that there is overlap between EAPS and RPR.
One question the WG will have to decide is whether there is
enough to warrant a formal response.
mike
Mick Seaman wrote:
> I agree that, from my point of view, that this does not conflict with an
> ongoing activity, although I would be very surprised to find it perform
> better than the best RSTP implementations even in its chosen application.
>
> Obviously it is of benefit to have proprietary implementations documented.
I
> would be happy to continue to dispute its supposed advantage, and the
choice
> of application space (I think there is a place for an 'end to end' shared
> redundancy solution, but the ends could be chosen much more generally to
be
> useful, given that an 'end to end path' could have mutlipel segements and
> protecting each of these segment by segment means a doubling of cost for
> each layering of protection). However if we held all proprietary
techniques
> to the same standards as the levels we (should) hold standards to then
we'd
> never see any of them documented.
>
> Perhaps the authors might reword the comparison to remove the 'side swipe'
> impression. I'm claiming better than 2 millseconds per node for RSTP
> convergence (not aggresive assumptions, and I am prepared to hustify with
> data), so I guess for rings with 50 or more nodes EAPS may do better (I do
> suspect that most old implementations will spend more time flushing
> databases than executing protocol).
>
> Mick
>
>
>
>
>
>
>
> -----Original Message-----
> From: owner-stds-802-1@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-1@xxxxxxxxxxxxxxxxxx]On Behalf Of Steve Haddock
> Sent: Wednesday, June 11, 2003 1:47 PM
> To: 'mick_seaman@xxxxxxxx'; stds-802-1@xxxxxxxx;
> stds-802-linksec@xxxxxxxx
> Cc: tak@xxxxxxxxx; bob.grow@xxxxxxxx
> Subject: 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@xxxxxxxx]
> Sent: Tuesday, June 10, 2003 9:51 AM
> To: stds-802-1@xxxxxxxx; stds-802-linksec@xxxxxxxx
> Cc: tak@xxxxxxxxx; bob.grow@xxxxxxxx
> 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@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-1@xxxxxxxxxxxxxxxxxx]On Behalf Of Tony Jeffree
> Sent: Tuesday, June 10, 2003 6:38 AM
> To: stds-802-1@xxxxxxxx; stds-802-linksec@xxxxxxxx
> 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@xxxxxxxxxxxxx
>>Reply-To: "Paul Nikolich" <p.nikolich@xxxxxxxx>
>>From: "Paul Nikolich" <paul.nikolich@xxxxxxx>
>>To: "Erik Nordmark" <Erik.Nordmark@xxxxxxx>,
>> <p.nikolich@xxxxxxxx>,
>> "Tony Jeffree" <tony@xxxxxxxxxxxxx>,
>> "Mike Takefman" <tak@xxxxxxxxx>,
>> <bob.grow@xxxxxxxx>
>>Cc: <erik.nordmark@xxxxxxx>
>>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@xxxxxxx>
>>To: <p.nikolich@xxxxxxxx>
>>Cc: <erik.nordmark@xxxxxxx>
>>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
>
>
>
>
>
--
Michael Takefman tak@xxxxxxxxx
Manager of Engineering, Cisco Systems
Chair IEEE 802.17 Stds WG
2000 Innovation Dr, Ottawa, Canada, K2K 3E8
voice: 613-254-3399 cell:613-220-6991