Re: [EFM] FW: IEEE802.3 EFM Process
John,
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.
>
>Regards,
>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.
>>
>>Regards,
>>
>>Larry
>>
>>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?
>>>
>>>Dolors
>>>
>>>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.