Re: [RPRWG] RE: [802.1] Fwd: Re: IESG question on Ethernet relatedto-be-RFC
Steve,
Dot17 is definely not suggesting an increase in its scope,
but merely pointing out overlap and a protocol that likely
implements the same sort of function.
What is not clear is whether the protocols used by MACs in
a ring is substancially different from the protocols used by
Bridges in a Ring, to solve protection and recovery. More
important is whether the IETF cares in terms of granting an
informational RFC. If the requested RFC has no overlap with
any existing standards (or drafts) then documenting a proprietary
implementation makes good sense. If the RFC has overlap with
existing standards (or drafts) as I believe this one does,
then the IETF has a more difficult decision to take.
If the WG wants to take up this issue in July, I'll let you know
so you can come and be part of the fun.
thanks,
mike
Steve Haddock wrote:
> 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