Re: [EFM] RE: OAM Proposals - a ping by any other name
Now children, stay off the reflector and go outside and play.
Roy Bynum wrote:
> 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