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

Re: [802.3_100G-OPTX] Comments to cole_3cu_adhoc_102319 on new nomenclature PMDs



John

 

You make an excellent point.

 

I believe we should debate each number separately. We could have 400GBASE-LR4-6, or 400GBASE-LR4-VI, or 400GBASE-IV-6, or 400GBASE-LRIV-VI, or CDGGBASE-LR4-6, etc.

 

I am optimistic again that we can hit Mark’s November target.

 

November 2020!

 

Chris

 

From: jdambrosia@xxxxxxxxx <jdambrosia@xxxxxxxxx>
Sent: Thursday, October 24, 2019 11:43 AM
To: Chris Cole <chris.cole@xxxxxxxxxxx>; STDS-802-3-100G-OPTX@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_100G-OPTX] Comments to cole_3cu_adhoc_102319 on new nomenclature PMDs

 

Chris,

I believe Jonathan would have wrote

 

CDGBASE-LRIV-VI

 

😊

 

John

 

From: Chris Cole <chris.cole@xxxxxxxxxxx>
Sent: Thursday, October 24, 2019 2:38 PM
To: STDS-802-3-100G-OPTX@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_100G-OPTX] Comments to cole_3cu_adhoc_102319 on new nomenclature PMDs

 

Hi Mark

 

Channeling Jonathan, what maybe an important debate which could take 802.3cu into next July is whether the name should 400GBASE-LR4-6 or 400GBASE-LR4-VI.

 

Chris

 

From: Chris Cole
Sent: Thursday, October 24, 2019 9:28 AM
To: 'Mark Nowell (mnowell)' <mnowell@xxxxxxxxx>; STDS-802-3-100G-OPTX@xxxxxxxxxxxxxxxxx
Subject: RE: Comments to cole_3cu_adhoc_102319 on new nomenclature PMDs

 

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>
Sent: Thursday, October 24, 2019 9:01 AM
To: STDS-802-3-100G-OPTX@xxxxxxxxxxxxxxxxx
Subject: [EXTERNAL]: Re: [802.3_100G-OPTX] Comments to cole_3cu_adhoc_102319 on new nomenclature PMDs

 

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>
Date: Thursday, October 24, 2019 at 9:33 AM
To: 100G OPTX <STDS-802-3-100G-OPTX@xxxxxxxxxxxxxxxxx>
Cc: Mark Nowell <mnowell@xxxxxxxxx>, Adam Healey <adam.healey@xxxxxxxxxxxx>, John D'Ambrosia <jdambrosia@xxxxxxxxx>, Robert Lingle <rlingle@xxxxxxxxxxxxx>
Subject: Comments to cole_3cu_adhoc_102319 on new nomenclature PMDs

 

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:

  • G.695, 2018 version (https://www.itu.int/rec/T-REC-G.695-201807-I), Table 8-24: Code C4S1-4D1F, referring to a 4 channel 50 Gb/s PAM4 CWDM application over 2 km, so being similar to 200GBASE-FR4.
  • G.959.1, 2018 version (https://www.itu.int/rec/T-REC-G.959.1-201807-I), Table 8-6:
    • Code 8R1-4D1F, referring to an 8 channel 50 Gb/s PAM4 800 GHz grid application over 2 km, so being similar to 400GBASE-FR8.
    • Code 4I1-4D1F a 4 channel 50 Gb/s PAM4 800 GHz grid application over 10 km, so being similar to 200GBASE-LR4.
    • Code 8I1-4D1F an 8 channel 50 Gb/s PAM4 800 GHz grid application over 10 km, so being similar to 400GBASE-LR8.

 

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.

  • Are we only discussing one or all 4 codes under responsibility of 802.3cu, fitting with clauses 140 and 151?
  • If 802.3cu would agree on a another approach for the nomenclature would we just leave it as such or try to expand to other running projects like 802.3cm, 802.3ct and 802.3cw? Or also to maintenance to address the nomenclature of in-force clauses.
  • Or are we trying to initiate a general discussion on a new, future proof nomenclature structure for in-force, in progress and future applications?

 

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