Re: [EFM] [EFM-OAM] OAM Transport Proposal
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).
> 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