Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [EFM] [EFM-OAM] OAM Transport Proposal




Rich,

I have responded in line in the message.

Thank you,
Roy

At 11:57 PM 5/2/2002 -0700, Rich Taborek wrote:

>Roy,
>
>See below.
>
>Roy Bynum wrote:
> >
> > Rich,
> >
> > An implementer can do the same with the 108 bytes of the frame payload that
> > Hiroshi's presentation did with the EOC, or the ITU-T xDSL standards do
> > with the EOC.  There is absolutely nothing that can be done with OAMiP that
> > can not be done with OAMiF.
>
>Agreed. However, OAMinP does it at the right level, in hardware,
>efficiently, with no impact on customer bandwidth (wasn't this one of
>your more prominent platforms recently).

Doing it in hardware is good thing if it the return on investment is worth 
it.  Adding new hardware is not always cost effective.  In today's market, 
and for the next few years, keeping it cost effective is the name of the 
game.  The time response delta between OAMiP and OAMiF is minimal since 
both can react with alarm information faster than 125us.

>
> > At the bit times rate of GbE, it would only take ~1.5us for a frame to send
> > out bit level alarms, so that argument is null and void.  Channelization of
> > the P2P data stream is out of scope of 802.3ah, so that argument is null
> > and void.  Managment of intermediate NEs can be done through the MCC/EOC in
> > the OAMiF payload, so that argument is null and void.  OAMiP is inside the
> > Ethernet PHY encoding just like OAMiF so neither proposal will support
> > leased circuit Private Line standards, so that argument is null and void.
>
>Your calculations assume hardware implementations. Your assumptions
>require MACs to be implemented in all ENE's. I still don't understand
>the relevance of PHY encoding to the preamble and what leased circuit
>Private Line standards have anything to do with Ethernet, EFM and
>Ethernet OAM.
>
>Best Regards,
>Rich
>
>--
>
> > Thank you,
> > Roy Bynum
> >
> > At 11:14 AM 5/2/2002 -0700, Rich Taborek wrote:
> >
> > >Roy,
> > >
> > >Please elucidate your claim below. It makes absolutely sense to me so
> > >I'll have to discard it as baseless.
> > >
> > >Best Regards,
> > >Rich
> > >
> > >--
> > >
> > >Roy Bynum wrote:
> > > >
> > > > Sergiu,
> > > >
> > > > The use of OAMiF as a transport for an EOC per ITU-T standards will 
> provide
> > > > support intermediate optical converters even better than OAMiP 
> can.  Please
> > > > take a look at the ITU xDSL standards files on the EFM web site.
> > > >
> > > > Thank you,
> > > > Roy Bynum
> > > >
> > > > At 04:33 PM 4/23/2002 -0700, Sergiu Rotenstein wrote:
> > > >
> > > > >All,
> > > > >
> > > > >I am sorry I am responding so late. I assume from the exchange of
> > > e-mails up
> > > > >to this date
> > > > >that my oppinions will be in minority.
> > > > >
> > > > >What I do not see in this proposal is the compromise.
> > > > >The main idea of the Suzuki preamble proposal was the support for 
> non-MAC
> > > > >based
> > > > >optical ethernet termination units - sometimes called converters. 
> These
> > > > >units
> > > > >are the most inexpensive form of deploying Ethernet based FTTH or 
> Optical
> > > > >Ethernet.
> > > > >The intention of the preamble proposal was to support the link 
> management
> > > > >for these
> > > > >type of units. These are widely deployed worldwide, and especially in
> > > Japan.
> > > > >And also
> > > > >this type of basic optical ethernet termination makes sense as a 
> starting
> > > > >deployment
> > > > >point.
> > > > >
> > > > >As I see in slide 5, in order to determine the capabilities of each
> > > end unit
> > > > >a frame
> > > > >exchange needs to take place. If the CPE side is a converter, that
> > > normally
> > > > >does not
> > > > >have frame/MAC support, than there is no link management.
> > > > >
> > > > >I assume that this is what the customers - the service providers - 
> had in
> > > > >mind.
> > > > >
> > > > >This is the essence of the proposal. The rest can be agreed 
> through enough
> > > > >work and
> > > > >intelligence. But, by eliminating the basic idea of the Suzuki 
> preamble
> > > > >proposal,
> > > > >we also eliminated the basic link management capabilities of a 
> simple non
> > > > >MAC type
> > > > >Optical Ethernet Termination... To correct this, we can add a simple
> > > > >auto-sense capability
> > > > >based on preamble information transmission that will affect the 
> link only
> > > > >when the
> > > > >link goes from down to up.
> > > > >
> > > > >Too bad that this is not on the agenda...
> > > > >
> > > > >Sergiu Rotenstein
> > > > >
> > > > > >>-----Original Message-----
> > > > > >>From: Kevin Daines [mailto:Kevin.Daines@xxxxxxxxxxxxxxxxxxxx]
> > > > > >>Sent: Friday, April 19, 2002 2:01 PM
> > > > > >>To: stds-802-3-efm@ieee.org
> > > > > >>Subject: [EFM] [EFM-OAM] OAM Transport Proposal
> > > > > >>
> > > > > >>
> > > > > >>All,
> > > > > >>
> > > > > >>A number of individuals have worked since the St. Louis
> > > > > >>Meeting in March on a compromise OAM Transport proposal. We
> > > > > >>are posting the proposal for review/comment from the larger
> > > > > >>802.3ah Task Force.
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>Kevin Daines
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > >
> > > > >
> > > > >
> > > > >The information contained in this electronic mail is privileged and
> > > > >confidential, intended only for the use of the individual or 
> entity named
> > > > >above. If the reader of this message is not the intended recipient,
> > > you are
> > > > >hereby notified that any dissemination, distribution, or copying 
> of this
> > > > >communication is strictly prohibited. If you receive this 
> communication in
> > > > >error, please immediately notify Disclaimer@xxxxxxxxxx Thank you.
>
>---------------------------------------------------------
>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