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




Tom,

Yes. The office that consists of my cubicle :-)

Best Regards,
Rich
       
--

Thomas Dineen wrote:
> 
> Rich:
> 
> "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."
> 
>    Rich: Are you running for office?
> 
> Thomas Dineen
> 
> >
> > 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