Re: [EFM] RE: OAM Proposals - a ping by any other name
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