| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Mark, Thanks for clarifying. My bad for having missed that point. Kind regards, Peter From: Mark Nowell (mnowell) [mailto:mnowell@xxxxxxxxx]
Peter, This was also clarified on the call, so I’ll take a stab at answering it. I’m sure Chris will correct me if I’ve got it wrong. As Chris points out on page 4 in the presentation
http://www.ieee802.org/3/cu/public/cu_adhoc/cu_archive/cole_3cu_adhoc_102319.pdf, he indicates that the letter code associated with reach (e.g. D, F, L) would have an assumed default value which is consistent with what most of us already assume. If the
reach matches the default value, then there would be no need to add any extra digits. So in Chris’ framework, the other 3 PHYs wouldn’t need any change. Mark From: Peter Stassar <Peter.Stassar@xxxxxxxxxx> Hi Mark & Chris, Thanks for clarifying your points of view and understanding while setting the boundaries for the discussion.
Looking at the presentation itself and listening to what was said yesterday, it wasn’t that obvious to me that we were only discussing a proposal to rename 400GBASE-LR4 as 400GBASE-LR4-6.
It would have been helpful to have stated that more specifically in the presentation, because that is what is being archived. Some people were not able to attend yesterday’s call and the only reference point is the posted presentation. Therefore this email exchange is very helpful. Then the specifics again. So the proposal is to use 400GBASE-LR4-6 for the 6 km CWDM approach while maintaining 100GBASE-LR1 (without any inclusion of distance) for the 1x100G PAM4 over 10km. Does that make sense?
Kind regards, Peter From: Chris Cole [mailto:chris.cole@xxxxxxxxxxx]
Hi Mark That is exactly correct. This is a preview of a presentation for the November meeting in support of a comment that will propose changing 400GBASE-LR4 to 400GBASE-LR4-6.
The background and more general proposal is to for context to show that in other existing or future TFs, if there is a need for reach to be included in the name, the precedent set in 802.3cu gives
those TF lots of leeway to consider a variety of options. We don’t debate specific names for hypothetical future PMDs, but rather we should make sure that if they do come up, we have a reasonable starting point.
I will add a few more naming examples to my presentation as per suggestions by Paul and Mike on the ad hoc. Chris From: Mark Nowell (mnowell) <00000b59be7040a9-dmarc-request@xxxxxxxx>
Hi Peter, I wanted to confirm what was discussed in the ad hoc with regards to Chris’ proposal and some process issues you raise. Only the naming of the PHYs under consideration in .3cu Task Force are in scope for the Task Force. As we’ve already had nomenclature debates in the Task Force, we’ve seen how the TF accepted
a proposed change from the originally adopted nomenclature to bring alignment with another Task Force’s adopted nomenclature when we added the “1” to the 100G PHYs. Our currently adopted nomenclatures as outlined in D1.0 are: 100GBASE-FR1 100GBASE-LR1 400GBASE-FR4 And 400GBASE-LR4 Given the opportunity for confusion around the newly adopted baseline for 400GBASE-LR4 having a max reach of 6km but a loss budget equivalent to 10km, it was raised in the September meeting that
we might want to consider an alternative naming for that one. You are correct that I stated that my intention is to entertain discussion on this nomenclature topic up until the November plenary where I’d like a decision to change or leave alone made by the
TF. I added extra ad hocs to help facilitate any discussion. We will deal with the decision separately (outside of comment resolution) but probably have a placeholder comment in place to use to make any changes, if the TF comes to some consensus. My interpretation of Chris’ proposal is that he has done exactly that and is proposing an updated nomenclature for 400GBASE-LR4 to be changed to 400GBASE-LR4-6. I believe this is his only specific
proposal into the .3cu Task Force. And I think he confirmed that on the call. Chris has shared a broader nomenclature framework to help explain why his proposal makes sense (at least to him) and to help justify it as a choice. It also offers everyone some context and ability
to explain it as well as envisage naming for things we might want to do in the future. I think most people appreciate having some sort of context for naming as it is confusing at the best of times as you point out below with the recent ITU codes. Regardless though I don’t think Chris is proposing any adoption of a broader “official 802.3” naming approach. Are you Chris? I imagine we will continue to deal with this in a TF by TF approach
and any decisions to retroactively change things in maintenance would again be made on those individual merits in anyone submits a request. Regardless, all of that is outside the scope of .3cu Task Force. The nice thing about Chris’ proposal is his proposed framework means that the other three PHYs we have under consideration by the TF are untouched as I understand it minimizing the changes we
would have to make. Not sure that any of above helps, but I wanted to clarify things from my Chair perspective as I know nomenclature can become a passionate topic we all love to have an opinion on. With that I’d
like to remind everyone that our last ad hoc on Nov 6th would be an excellent chance to continue the nomenclature discussion ahead of the plenary or use the reflector as Peter has done. Regards, Mark From: Peter Stassar <Peter.Stassar@xxxxxxxxxx> Dear 802.3cu colleagues, I am taking the opportunity to further respond by email to Chris’s presentation given at yesterday’s ad hoc call,
http://www.ieee802.org/3/cu/public/cu_adhoc/cu_archive/cole_3cu_adhoc_102319.pdf. I want to emphasize that I was certainly not dismissing the proposal and that I fully appreciate the effort to step up and make a proposal. Furthermore I must say that the time available to discuss this proposal and the associated limitations of a conference call, made it pretty hard (if not impossible) to have a complete
discussion on the topic of completely new nomenclature. Let me start with observing that I was actually quite confused about the width and potential impact of the proposal and how it fitted with the scope of the 802.3cu project and these
were the reason why I said that I struggled with the proposal. First if statements are made about work done in ITU-T I feel the obligation to review those and put them in perspective, considering my engagement with the work in ITU-T SG15. On slide 2 Chris made the statement “Fortunately, this problem is solved by ITU-T …” Then on slide 3 Chris refers to Recommendation ITU-T G.693 (downloadable from
https://www.itu.int/rec/T-REC-G.693-200911-I). As you can see the last version is from 2009, which has the following scope: “The purpose of this Recommendation is to provide optical interface specifications to enable transverse (multivendor) compatibility of nominal 10 Gbit/s
and 40 Gbit/s aggregate bit rate intra-office systems for link distances up to 2 km.” Chris makes the suggestion that ITU-T has made a fundamental choice how to treat distances in their application codes. Unfortunately that is not true. In the case referenced the treatment of distance applies only to 10G and 40G codes over distances up to 2km specifically within Recommendation G.693. These are all single lane codes. More recent (2018) codes can be found in Recommendations ITU-T G.695 and G.959.1 which have very close relationships with PMD specifications in IEEE 802.3. Some examples:
So I trust you understand my confusion when Chris said “Fortunately, this problem is solved by ITU-T …”, looking at these recently (2018) adopted codes C4S1-4D1F, 8R1-4D1F, 4I1-4D1F
and 8I1-4D1F, which have no obvious relation to any distance. Even I need a lookup table to understand them. So if Chris had said “In Recommendation G.693 an application code methodology was used which may be useful to re-use” then it would have been an appropriate statement. Now back to the issue at hand. During the meeting in Indianapolis there was an agreement to review whether the code 400GBASE-LR4 was appropriate for a 6 km application. Mark indicated that he would want the discussion on this topic to be completed during the Hawaii meeting in November. I am in full agreement with that objective. I had expected that the direction of the discussion would be to use the letter “L” for 6 km or something else. From Chris’s presentation I understand the he doesn’t want to go that
direction. This would have been a discussion to easily wrap up during the November meeting. Now looking at Chris’s presentation I am not sure what he is actually proposing and how that fits with the scope of the 802.3cu project. It appears that Chris is not only proposing a code for the 4 channel 100 Gb/s PAM4 CWDM application, but rather proposing a completely new nomenclature proposal for (optical) PDMs
not only under consideration in 802.3, but also for those in in-force standards/clauses. If it’s the latter, then I think it is out of scope of the 802.3cu project. Are we only discussing the 4 channel 6 km CWDM application currently named as 400GBASE-LR4 or also the other 3 applications 100GBASE-FR1, 100GBASE-LR1 and 400GBASE-FR4?
So before being actually able to provide specific feedback to the proposal made yesterday I want to understand what we are trying to do here.
I believe I understood that Chris is going to make a comment against D1.0 of P802.3cu related to the nomenclature, which would be sufficient to get the discussion started. If this discussion is limited to 802.3cu then I would agree with an objective to complete it in November. If we want to engage other projects and maintenance then it may take quite some longer time to agree on a general approach because each project can make its own decisions, which
are potentially different. Now to a specific name. Adding the distance is an interesting proposal potentially providing clarity. On slide 5 Chris suggests 400GBASE-LR4-6. If we want to go this direction then there are (obvious) alternatives, 400GBASE-LR4-6k, 400GBASE-LR4/6, 400GBASE-LR4/6k, etcetera. Is this really making things easier? Not sure yet. Kind regards, Peter Stassar To unsubscribe from the STDS-802-3-100G-OPTX list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-100G-OPTX&A=1
To unsubscribe from the STDS-802-3-100G-OPTX list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-100G-OPTX&A=1
To unsubscribe from the STDS-802-3-100G-OPTX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-100G-OPTX&A=1 |