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

Re: [EFM] FW: IEEE802.3 EFM Process


You need an additional item to your list:

Defined physical operational management overhead

Thank you,
Roy Bynum

At 11:40 AM 10/28/01 -0800, John.Egan@xxxxxxxxxxxx wrote:
>EFM members,
>Although the thread below is focused on EFM P2MP, I would like to extend 
>this thread by proposing that Richard's and Larry's comments not be taken 
>only as far as P2MP fiber (EPON) is concerned. I believe these concepts 
>have validity regarding the EFM-Copper endeavors as well. Additionally, 
>compliance should not be focused only on 80x issues, but on compliance 
>regarding external agencies and standards bodies.
>The EFM-Copper effort is working in the Access space, one with 
>requirements outside the typical LAN scenario and is a regulated space, as 
>well. The areas of difference from the copper access space to a LAN include:
>    * Extended temperature range
>    * Local loops vary greatly in make up and will not be rerun to bring 
> them into conformance with an EFM standard
>    *  Defined band plans exist
>    * Defined line codings exist
>    * Already defined layers up to an adaptation layer - the Transport 
> Protocol Specific layers. (EPON is a far distant relative to APON and 
> does not have this issue.)
>I believe that the EFM-Copper effort should consider an approach to its 
>Objectives that has been broadly hinted at by our Chairman, maintain the 
>IEEE tradition and borrow someone else s existing PHY. Toward this end, I 
>recommend that the TPS layers (PMD, etc.) be left aside for the standards 
>bodies that have already done this work (ANSI, ITU, ETSI). These bodies, 
>and the local regulatory agencies (FCC,...) will eventually dictate the 
>band plans appropriate for the local loop, therefore we should be working 
>on conformance, as stated already in our Objective #2, and initially 
>concentrate on the adaptation layer and MAC. Included in this work should 
>be collaboration with these other standards bodies in an attempt to extend 
>their existing definitions of the Packet Transport Mode layer to enable 
>better Ethernet functionality above it. Moreover, the EFM-Copper effort 
>should not consider additional efforts that conflict with the band plans 
>or line coding definitions already codified, as this may be in conflict 
>with Objectives established and result in a standard that may not be 
>accepted for use in bundles where regulated services exist.
>John Egan
>-----Original Message-----
>From: Richard Brand [mailto:rbrand@xxxxxxxxxxxxxxxxxx]
>Sent: Thursday, October 25, 2001 6:22 PM
>To: larry rennie
>Cc: Dolors Sala; Glen.kramer@xxxxxxxxxxxx; jc.kuo@xxxxxxxxxxxx; 
>rhirth@xxxxxxxxxxxx; onn.haran@xxxxxxxxxxx; ariel.maislos@xxxxxxxxxxx; 
>kobi.mizrahi@xxxxxxxxxxxx; HHvostov@xxxxxxxxxxxx; RShamsi@xxxxxxxxxxxx; 
>eyal@xxxxxxxxxxxxxxxxxxxxxx; meir@xxxxxxxx; tony@xxxxxxxx; 
>jstiscia@xxxxxxxxxx; glen@xxxxxxxxxxx; cicook@xxxxxxxxx; 
>carlosal@xxxxxxxxxxxxxxxxxx; ajay@xxxxxxxxxxxx; limb@xxxxxxxxxxxx; 
>jpickens@xxxxxxxxx; jcpoint@xxxxxxxx; lior.khermosh@xxxxxxxxxxx; 
>gerry.pesavento@xxxxxxxxxxxx; tony@xxxxxxxxxxxxx; 
>vincent.bemmel@xxxxxxxxxxxx; johngeorge@xxxxxxxxxx; wsoto@xxxxxxxxx; 
>stds-802-3-efm-p2mp@xxxxxxxxxxxxxxxxxx; Roy Bynum; Kent McCammon; puru 
>kamat; DeNap
>Subject: Re: IEEE802.3 EFM Process
>LA Attendees:
>I was unable to attend anything but the beginning of the ah meeting on 
>Wednesday, but I am supportive of Larry Rennie's proposal with one 
>addition. Even as one who has been participating in 802.3 standards for 
>some time and understands the importance of backwards compatibility to 
>"legacy" Ethernet and 802.1, there is no denying that the Ethernet in the 
>First Mile space puts us squarely into new territory outside of the LAN 
>box.  This environment is not the enterprise environment, with the need 
>for extended temp requirements (the ONU for sure) and it brings a new set 
>of potential as well as future asymmetric applications.  Knowing that our 
>charter is narrowly defined as L1/L2 and our objectives must match that 
>space, the future of our industry demands our creative thinking about the 
>services that could be provided on various implementations of the 802.3ah 
>infrastructure.  We have already spent many hours of presentations in the 
>Study Group on these.   We do not have to shut off that input yet, but is 
>now time to establish a process that puts 802.X compliance in as a check 
>but not as a gate at this time point.
>My addition would be to establish an Ad Hoc/advisory group that would sit 
>between the "Modifications to 802.3 and Other Standards Required to Meet 
>Objectives" box and the "Existing Objectives and Criteria" box.  This 
>group would constantly review the compliance vs objectives issues 
>including any new proposed objectives (note the small "o" in objectives).
>The timing of the process proposed by Larry would be critical to our 
>completion of a document in a timely fashion, and we would have to adhere 
>to that schedule in order for the process to be successful.
>Richard Brand
>larry rennie wrote:
>>In listening to the presentations and responses at last weeks meeting, 
>>there was always the constant question of compliance. We need a 
>>structured methodology of dealing with this question.  During the talks I 
>>sketched a very top level flow diagram approach.  Copy attached.  It is 
>>an  iterative process.  I believe we first need a strawman architecture 
>>that meets the criteria and objectives, always keeping 802.3 compliance 
>>as a goal in mind but not letting it control the initial architecture 
>>design to the point that prevents us from even getting to a strawman 
>>design that meets our criteria and objectives.   After we have a strawman 
>>design that meets our criteria and objectives, we then look at 802.3 
>>compliance.  If not compliant we look at what modifications we could make 
>>to our objectives in order to get a viable 802.3 compliant architecture 
>>(and resulting EFM standard). If this is not possible, then we then have 
>>to look at the modifications needed to the existing 802.3stds (and other 
>>stds, such as 802.1) in order to come up with a viable EFM standard.
>>Toward this end, I suggest that at the end of each presentation 
>>(particularly architecture related presentations) that an 
>>802.3  compliance matrix be included with emphasis on what not is 
>>compliant and what existing standard changes are necessary for compliance 
>>of the subject matter in the presentation.
>>Dolors Sala wrote:
>>>We had a good discussion during the meeting on requirements. The
>>>feedback on the forwarding rules was to present this problem to 802.1
>>>for a possible incorporation of this functionality at the 802.1 layer.
>>>Hence the discussion on this topic is put on hold in the requirements
>>>effort. It will continue with the preparation of the presentation
>>>to 802.1 group.
>>>The idea of this email is to define the objectives of the requirements,
>>>both short term for the November meeting and longer term to capture the
>>>general scope to be considered.
>>>Suggested list of issues is included below. Comments and modifications
>>>are welcome. The focus of the effort can be modified accordingly.
>>>The suggestion is to focus first on 802.3x compliance. To start
>>>the discussion, the first question on this topic is the following.
>>>Both Pause and link aggregation are specified for full-duplex operation.
>>>Is an 802.3 requirement to support them in PON since it is a shared
>>>medium? If it is not, then this requirement is not a
>>>compliance issue but rather a definition issue. In this case,
>>>should they be supported?
>>>Overall objectives of requirements effort:
>>>     1 Discussion of the remaining requirements
>>>         (see list below, and suggest additions
>>>         if list is not complete)
>>>     2 Polishing/agreement of existing requirements
>>>         The current document needs to be polished
>>>         to clean any concerns of out of scope
>>>         specification. So we have some work in
>>>         there to reduce the specification and
>>>         reach agreement.
>>>     3 Peer-to-peer and bridging compliance
>>>         (in a separate presentation
>>>         in Nov meeting)
>>>General objectives for the requirements effort
>>>Pending topics for discussion:
>>>     1- 802.3 clause 31B (PAUSE mechanism)
>>>     2- 802.3 clause 43 (link aggregation)
>>>     3- Link security
>>>         3.1 yes/no
>>>         3.2 specific functionality
>>>     4- PON-specific OAM
>>>It was a question during the requirements presentation on the
>>>consideration of OAM requirements.
>>>The initial idea was to leave item 4 for the OAM subgroup,
>>>and concentrate on the system and protocol issues in this one. Any OAM
>>>PON-protocol specific cannot be specified until the baseline protocol is
>>>defined. Hence the idea was/is to only focus on this part of OAM in this
>>>discussion. And hence leave it as the last topic for the discussion.
>>>Comments on this are welcome.
>>>Objectives for Nov meeting
>>>Given that there is only 3 weeks for next meeting, a good
>>>objective could be to continue the discussion of the pending
>>>requirements. The suggestion would be to focus first on 802.3x
>>>compliance (pause, link aggregation) and then on the need (yes/no)
>>>of security.