Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [EFM] RE: OAM Proposals - a ping by any other name




Rich,

My track record is in building many of the proof of concept and prototype 
architectures of several of the successful data communications/transmission 
networks and services.  I have had to take the "stuff" that has been sold 
by vendors for years and actually make it work and support it in a real 
world.  I am the original host master for MCI.  I deployed the first long 
reach MAN in North America.  I deployed the first large OSPF (OSPF v1) 
routed network in North America.  I deployed the first POS in North 
America.  I deployed one the SNAP Ethernet MANs in North America.  I 
designed and deployed the first interlinked international IP/SNA Ethernet 
routed/bridged network in the world. I designed and deployed the proof of 
concept network that became the base for Frame Relay services.  I was part 
of the original routed surveillance DCN in the world, which happened to be 
for one of the largest SONET transmission networks in the world.  I have 
been working with SONET standards, not Ethernet standards for most of the 
last 12 years.

I have not had the experience that you have in the 802.3 body.  I did not 
get involved in Ethernet until it became necessary to add OAM to 
Ethernet.  I do know what does and does not meet the subscription network 
service providers requirements.  I had hoped that, just as I look to you 
for guidance relative to the 8b/10b-Fibre Channel protocol, you would 
recognize my background and track record.  You are attempting to create 
functionality in Ethernet that I have almost 12 years of experience with.

Even though I do not have your respect, I respect your background and track 
record.

Thank you,
Roy Bynum

At 06:18 PM 5/2/2002 -0700, Rich Taborek wrote:

>Ladies and Gentlemen,
>
>I apologize to all of you for the FUD coming from Roy. I can't speak for
>Hiroshi and others but I can for myself. I have enough knowledge of
>SONET and many, many other interfaces to have spend the last 7 years or
>so working on Ethernet. Those of you that know me know the contributions
>that I've made to Gigabit Ethernet and 10 Gigabit Ethernet. Those of you
>that know Roy can check his track record on Ethernet projects. You'll
>find that it speaks for itself. I'm now actively working on EFM and
>promise to work for you with the same level of commitment to Ethernet
>that I've shown in the past.
>
>Roy, I apologize for OAMinP being faster than SONET OAM.
>
>Best Regards,
>Rich
>
>--
>
>Roy Bynum wrote:
> >
> > All,
> >
> > I apologize for the tone of this e-mail.  I realize that Rich, Hiroshi, and
> > others may not have very much experience with SONET, so it is easy for them
> > to get confused.  There may be others that are attempting to "market" OAMiP
> > by positioning it as something that it is not.  It is sometimes a
> > "marketing" practice to attempt to confuse, or blur the details of one
> > thing in order to make it appear to be something else.  I am not
> > insinuating that OAMiP is being "marketed" in that way.
> >
> > I think that bit level alarms generated faster than every 125us is not a
> > bad thing.  The rest of the OAMiP proposal, I do not think is a good thing.
> >
> > Thank you,
> > Roy Bynum
> >
> > At 06:03 AM 5/1/2002 -0500, Roy Bynum wrote:
> >
> > >Rich,
> > >
> > >I will say the same thing to you as I have said to Hiroshi on several
> > >occasions.  OAMiP has no relationship, compatibility, or comparibility
> > >with SONET.  SONET has three separate levels of bit stream encoding and
> > >management, while OAMiP does not.  SONET services treats the PCS
> > >equivalent encoding of the customer data bit stream as part of the
> > >customer data bandwidth, OAMiP does not.  Please, in future references, do
> > >not make any comparisons between OAMiP and SONET except as how they are
> > >different.
> > >
> > >Thank you,
> > >Roy Bynum
> > >At 08:22 PM 4/30/2002 -0700, Rich Taborek wrote:
> > >
> > >>Geoff,
> > >>
> > >>Actually, service providers today pull management information out of
> > >>"overhead" and not frame information. The OAMinP portion of the OAM
> > >>Baseline proposals go one better by providing SONET equivalent
> > >>management
> > >>information from an Ethernet stream without the overhead expense. Frame
> > >>information
> > >>must be routed to the user or management entity. OAMinP information
> > >>always goes directly to the management entity.
> > >>
> > >>Best Regards,
> > >>Rich
> > >>
> > >>Geoff Thompson wrote:
> > >> >
> > >> > Roy-
> > >> >
> > >> > At 10:12 AM 4/22/02 -0500, Roy Bynum wrote:
> > >> >
> > >> > >Martin,
> > >> > >
> > >> > >For packet services such as Ethernet VPN, OAMiP is useful to provide
> > >> > >"Section" equivalent level autonomous fault bit alarms, or a very low
> > >> > >level maintenance function such as turning on or off "Section" 
> equivalent
> > >> > >level loop back functions.  This is the reason that I supported a
> > >> > >simplified version of OAMiP as being optional for EFM.
> > >> > >
> > >> > >For Private Line services OAMiP is useless.
> > >> >
> > >> > I do not believe that this is true.
> > >> >
> > >> > This assumes that the provide wants to keep a sophisticated customer
> > >> > completely segregated from OAM. In fact this is not the case, 
> especially
> > >> > over long term trends. As carriers get squeezed for revenue they will
> > >> > depend more and more for input from their customers. Customer's 
> facilities
> > >> > will span several supplier's environments. They are gonna have to 
> be able
> > >> > to participate. I believe that putting the relevant data within 
> frames is
> > >> > the only viable way to allow that to happen.
> > >> >
> > >> > >Thank you,
> > >> > >Roy Bynum
> > >> >
> > >> > Geoff
>
>---------------------------------------------------------
>Richard Taborek Sr.                     Intel Corporation
>XAUI Sherpa                    Intel Communications Group
>3101 Jay Street, Suite 110    Optical Strategic Marketing
>Santa Clara, CA 95054           Santa Clara Design Center
>408-496-3423                                     JAY1-101
>Cell: 408-832-3957          mailto:rich.taborek@xxxxxxxxx
>Fax: 408-486-9783                    http://www.intel.com