Re: [EFM] RE: OAM Proposals - a ping by any other name
Rich,
I thank you for stating that your level of expertise on Ethernet. I also
thank you for stating your lack of knowledge of SONET.
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