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

[802.3_100G-OPTX] 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:

o   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.

o   Code 4I1-4D1F a 4 channel 50 Gb/s PAM4 800 GHz grid application over 10 km, so being similar to 200GBASE-LR4.

o   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