Re: [EFM] FW: IEEE802.3 EFM Process
All,
This thread seems to be heading into very dangerous areas.
I'll try to address the comments in order:
Dolors suggests that we should focus first on 802.3 specific requirements
(clause 31B and 43) - specifically the question of whether compliance is
required. There is some room for debate here since the standards are defined for
point-to-point, not shared media.
Larry goes further to suggest that we should focus on our "EFM objectives" even
if this takes us outside the scope of 802.3. At this point I must disagree
strongly! We are a sub-group of 802.3, there is never any doubt that we come
under their auspices. The requirement of "compliance to 802.3" takes precedence
over any other objective or requirement. Period.
Richard goes just a little further, suggesting that a "compliant baseline" is
desirable but not mandatory and that compliance with 802.X is a good "check box"
item but not gating. I must disagree with this even more strongly as the
hierarchical nature of the organization forces 802.3 to comply with 802 just as
we (802.3ah) comply with 802.3.
John's comments are non sequitor to this discussion (although still valid).
There is nothing to prevent us complying with other standards alongside 802.3. I
think it's worth starting that discussion as a separate thread.
To summarize:
1. There is no possible way that we can write a standard for 802.3ah that does
not comply with 802.3 (& thus 802). Just from a practical perspective - how
would you edit a few clauses of a document in such a way that it is not
compliant with the document as a whole?
2. It is a free country! If you wish to form a new subgroup of 802 then you are
welcome to try. A new sub-group (say 802.19) would not carry any of the burden
of 802.3. By all means go ahead and do that - don't try to move 802.3ah into a
different group through an underground passage.
Similarly, if 802.X is too restrictive then there is nothing preventing a new
standard from being developed within any existing or yet-to-be-created standards
body. There are many fine examples of that ranging from industry consortia (such
as BlueTooth, DOCSIS, HPNA, FSAN) to other ANSI or ISO accredited standards
organizations (such as ANSI T1, ETSI TM6, ITU-T, IETF).
3. If there is massive support for an external body standardizing EFM, then it
will effect our "broad market potential" criteria. It is always possible that
802.3ah may be unsuccessful - we could fail to produce a new standard for one or
more of the objectives, we could produce the standard but get marginalized by
other industry movements. That's life! it has happened in the past (to numerous
802.3 & 802.X) standards, we must strive for success but accept that failure is
a risk.
In the meantime, in the context of any discussion regarding 802.3ah, please do
not consider any possibility that we would not be compliant with 802.X or 802.3.
With regards,
Hugh.
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 conceptshave 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, onewith 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:
>
> o Extended temperature range
> o Local loops vary greatly in make up and will not be rerun to bring them
> into conformance with an EFM standard
> o Defined band plans exist
> o Defined line codings exist
> o 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.
>>