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

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




Geoff,

These are the same issues that I brought up in the baseline break out 
group.  I was over ruled by the predominately OAMiP participation in that 
group.  That is the reason that I withdrew my support of the baseline 
proposal being presented at the EFMA meeting.

Thank you,
Roy Bynum

At 12:47 PM 4/20/2002 -0700, Geoff Thompson wrote:
>Roy-
>
>I have not examined the proposal.
>It sounds like the proposal to send a preamble without a frame would either:
>         1) Violate the minimum frame size of Ethernet
>         or
>         2) Violate the frame format requirements of Ethernet
>My questions would then be:
>         Why do the proposers think that this "would be Ethernet?"
>         How do they expect to get it approved in 802.3
>         How do they expect these entities to show up on Ethernet test 
> equipment?
>         Have they checked it against the 5 Criteria lately?
>
>Geoff
>
>
>At 08:38 AM 4/20/02 -0500, Roy Bynum wrote:
>
>>Matt,
>>
>>I had to withdraw my support of this baseline proposal.  The people that 
>>were in your breakout group originally were replaced by individuals that 
>>had less of a neutral agenda.  While this might be a natural evaluation, 
>>I found the group diverting from its original direction.
>>
>>What forced me to withdraw was the re-insertion in the baseline proposal 
>>of the new frame type shown in slide 10 as a stand alone preamble with no 
>>Ethernet frame behind it.  This has not has very much discussion in the 
>>EFM TF group as a whole, or the dot 3 voters.  This functionality was not 
>>part of the original functionality that the breakout group has originally 
>>agreed on.
>>
>>Several people are saying that preamble will not work properly without 
>>that non-Ethernet-frame preamble type frame.  The alternative concept is 
>>that the OAM frame will always be available to be sent, so there is never 
>>a need to send a preamble without a frame.
>>
>>Also, the PHY ID was re-introduced in the P2P baseline OAM as well as the 
>>P2MP, as shown in slide 9.  The breakout group had originally agreed that 
>>P2P would not support multiple network elements within the P2P link, and 
>>so the PHY ID was specific to P2MP and should not be part of the basic 
>>OAM baseline.
>>
>>I enjoyed working with the group that you originally invited to 
>>participate.  Thank you for the oportunity.
>>
>>Thank you,
>>Roy Bynum
>>
>>
>>I have the perception (I could be wrong) that more representation from 
>>the "preamble" camp participated in developing the baseline.  For example 
>>HS was there while DG was not.
>>
>>At 02:58 PM 4/19/2002 -0700, Booth, Bradley wrote:
>>
>>>Kevin,
>>>
>>>I have a few questions:
>>>*       OAM in VOC/eoc is not explained in the document.  Is there a
>>>proposal that should be referenced?
>>>*       Do these OAM protocols assume no repeaters?  Is the OAM scheme
>>>designed to work in half-duplex?
>>>*       Is there a specific OAM scheme that should be used for end-to-end
>>>(versus link-by-link) OAM messaging?  Carrier class equipment has section,
>>>line and path, do we have something similar?
>>>*       IEEE Std. 802.3z currently permits GbE fiber links to generate
>>>either 7 or 8 bytes of preamble.  How does the OAM in preamble compensate
>>>for this?
>>>
>>>Thanks,
>>>Brad
>>>
>>>Brad Booth
>>>Intel Platform Networking Group - Austin
>>>bradley.booth@intel.com <mailto:bradley.booth@intel.com>
>>>
>>>                 -----Original Message-----
>>>                 From:   Kevin Daines
>>>[mailto:Kevin.Daines@worldwidepackets.com]
>>>                 Sent:   Friday, April 19, 2002 4:01 PM
>>>                 To:     stds-802-3-efm@ieee.org
>>>                 Subject:        [EFM] [EFM-OAM] OAM Transport Proposal
>>>
>>>                 << File: OAMtransport_041902.pdf >> 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
>>>