Re: [EFM] RE: OAM Proposals - a ping by any other name
Rich,
By your not seeing any "S's" in EFM, does that mean that you are not
concerning yourself with whether EFM will have any "service" markets? ;-)
Thank you,
Roy
At 10:38 AM 5/3/2002 -0700, Rich Taborek wrote:
>Roy,
>
>You're very welcome. Note that the "E" in EFM stands for Ethernet. I
>don't see any "S's" in EFM.
>
>Best Regards,
>Rich
>
>--
>
>Roy Bynum wrote:
> >
> > 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