|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
Hi Mark, Kent, Joel,
I was just responding to Brad’s description of the path forward and Mark’s confirmation that Brad captured well the consensus. Thank you for clarifying the actual agreement.
The SMF PMD comment was a recognition of the only way to have a fast 50G Ethernet project. As Steve pointed out, a quick project reuses existing work, as was done in the 25G Ethernet project. At this point, the only 50G PMD work is being done in 802.3bs, and if we want KR, CR and MMF that will be new work and won’t be fast.
I also support the next step of putting together one detailed CFI for Nx50G Ethernet and PMDs. Once we have the details of what is in the project(s) and the interdependencies, we can make a decision on the organization. We have spent a lot of time fine tuning the organization without having the detailed content.
+1 to Kent and Mark
Also +1 to Mark … I never heard any discussion that we only do an SMF PMD … I heard the same span Mark discussed.
FWIW, I, too, took away from the (infamous?) lunch meeting that the best path forward was 1 CFI that yielded 2 SGs. This is because, as Mark explained, the SG ceases to exist when the PAR is accepted. The 2 SG path offers a safety net to us, if one of the SG happens to take more time to resolve the CSDs.
The takeaway that I had coming out of all the discussions last week was to move forward with a single CFI in November. This CFI would request two SGs to be formed. The value in two SGs being formed is that per the IEEE rules, once a SG has a PAR accepted, it ceases to exist, therefore two SGs enables two PARs to be generated if needed. It would make sense for these two SGs to be run jointly to explore the interdependecies of all the topics but by having two it enables separate PARs to be generated at separate times if that is the outcome. I don’t want to put words into David Law’s mouth but he indicated that he would be comfortable with this approach. We’ve explored the challenges of having one SG trying to generate more than one PAR before and know it has issues. With this approach we effectively have one CFI, one effective SG (but procedurally two) and the option to create one or two TFs.
I don’t understand your question on only-SMF PMD for 50GE. I don’t think that has ever been proposed. The potential 50GE PMDs span twinax to SMF.
Finally, no attempt was implied to shut down conversation on the Dialog reflector, I was just asking for names to be included in meeting invitations.
On 9/24/15, 5:30 PM, "Chris Cole" <chris.cole@xxxxxxxxxxx> wrote:
I am confused as to what was agreed at the lunch discussion, as I have now heard conflicting views.
Is it as you and Brad remember that it’s two CFIs, two Study Groups, two PARs, two Task Forces, i.e. separate 50G and 100/200G projects from the get go?
Or is it as others remember that it’s one CFI, two coordinated Study Groups, then TBD by the SGs for either:
1) one PAR, one Task Force,
2) or two PARs, two Task Forces with content of the two PARs and Task Forces also TBD by the SGs?
Further, if all 50G PMDs are restricted to the 50G project and since that is a “fast project” standardizing only SMF PMDs, does this leave CR, KR and SR to a later third project?
I don’t understand the suggestion to cut off discussion on the reflector of what is a topic of great importance to many 802.3 members, especially since there was no opportunity for discussion during the ICAID meeting. Given the confusion and lack of consensus, open discussion should be encouraged, not shut down. As an aside, loaded adjectives like “flooding” are not conducive to a good discussion, even if the deluge is of opposing views.
I’ve been slow to catch up with this thread and want to thank Brad for summarizing the discussions that happened later in the week after John’s ICAID meeting. I think Brad has captured well the essence and general consensus that we came to.
We had a lot of experienced 802.3 leadership perspectives that were concerned about the feasibility of one large project potentially handling 3 MAC rates simultaneously. We also heard the recommendation that we make sure we don’t initiate a process that may, due to IEEE rules, prematurely terminate any path of study we want to do.
It is clear we have interest in ensuring progress on both single lane 50Gb/s Ethernet and multiples (100Gb/s and 200Gb/s) Ethernet. We’d be defining new MACs and PCS’s where we don’t have them as well as new PMDs for new and existing MAC rates.
I’m putting together the CFI request to capture this. I’ll be setting up a series of pre-CFI review meetings for those who are interested to attend. I’ve gathered an email distribution list already from those who asked to be included after the May and July Flash mobs we had on the topic. I’ll send meeting details to that group to not flood the dialog reflector - please send me an email if you want to be included and aren’t on the list (or not sure you are on the list).
On 9/24/15, 12:12 PM, "Brad Booth" <bbooth@xxxxxxxx> wrote:
Unfortunately you decided to head home early and missed some of the discussion that occurred in Bonita Springs.
One aspect that I liked in the discussion was the formation of two projects: 50G and n*50G. They could have one consensus meeting, two CFIs, two study groups, two PARs and two task forces that are coordinated and work in parallel. The nice aspect of this is that it permits each project to operate on a timeline that suits their requirements, rather than creating a dependency that could impact one or the other.
Splitting a PAR after the project has started is something we should try to avoid. Amending and modifying PARs is also something worth avoiding. Both add delays to the work being done.
So, while there are some that may feel there is opposition to 200G or n*50G as being a project in 802.3, I believe that is a false interpretation. To me, it is not a question of do we need to do 200G/n*50G, but rather what is the most efficient and effective means to manage and accomplish the work required. IMHO and with past experience as a chair and chief editor, I believe that two projects would be the optimal path forward.
On Wed, Sep 23, 2015 at 10:44 AM, Chris Cole <chris.cole@xxxxxxxxxxx> wrote:
I had several off line conversations prompted by my Dialog reflector email and have been pleasantly surprised to learn that there is almost uniform agreement about the need for 200G Ethernet and Nx50G (N=1,2,4) PMDs. This is a nice change from where we were even at July meeting.
The major questions facing us now are whether 50G and Nx50G are one project or two projects, and what PMDs to standardize in the project(s).
Steve Trowbridge nicely summarized the status and complex dependencies of the project organization choices in a private email exchange, and with his permission I am sharing his observations verbatim.
< It SEEMS LIKE 50G could be a faster project than 200G (or 2^n*50G), and it SEEMS LIKE the market need for 50G would be earlier than the market need for 2^n*50G, BUT:
· 50G is only a “fast” project (like P802.3by) if it is opportunistically reusing the 50G lane technology from P802.3bs. But all you get if you do this are SMF PMDs and a single lane LAUI chip-to-chip and chip-to-module. These don’t seem like the ideal PMDs for what many think is the initial application for single-lane 50G, which is server to ToR in the cloud scale data centers. If you add a (long) backplane 50GBASE-KR, a 50GBASE-CR copper cable, and a 50GBASE-SR PAM4 MMF (which seems like what would be desirable for a project like this), since you didn’t have a bj or bm equivalent project to do those lane technologies for you, they need to be done in the 50G project, which makes this a long, slow, difficult project.
· If you were to decide to do a “fast” 50G project with only SMF PMDs, and leave the heavy lifting for a 200G or 2^n*50G project (e.g., develop 200GBASE-KR4, 200GBASE-CR4, and 200GBASE-SR4 in this project), then for sure you would want to not couple the time scales since the 50G project would be done a lot faster. But I am not sure it is realistic to leave all of the “hard” PMDs out of the 50G project.
· If you do all the heavy lifting in the 50G project, then the 200G or 2^n*50G project becomes a simple, almost “logic only” project (and even the logic isn’t hard – it is mostly scaling down what 802.3bs has done), then there is no reason the 200G spec couldn’t be done the instant that 50G is done. So in that case, the only reason for putting 50G and 200G in different projects and on different timescales would be if the market need for 200G is substantially later than the market need for 50G. >
One of my key take away points is that we don’t know enough now to be making decisions about what should be the project structure and content. Which means that 802.3 processes which were designed to deal with just such uncertainty should be fully taken advantage of to make our decisions.
Thanks Chris for opening the discussion.
You have expressed my views better than I would have myself. J
The Industry Connections meeting last night missed an opportunity to substantially discuss the major issue in front of us: what next Ethernet rate(s) and associated PMD(s) are important to industry. We heard well prepared presentations which raised important technical and market considerations and presented two different views of what’s important. Unfortunately there was no time for questions and most of the subsequent discussion time was allocated to administrative issues. At end of the meeting, we agreed to start discussion on the 802.3 Dialog Reflector.
Mark’s presentation proposed 50G Ethernet and 40G and 50G Serial PMDs as the next important industry priority. Scott’s presentation proposed 50G and 200G Ethernet together as the next important industry priority, supported by nx50G (n=1,2,4) PMDs. There was broad agreement before and during the meeting that the workload to standardize everything is huge. Regardless of how we end up slicing the work: by Ethernet rate, by PMDs, or by functionality (logic, copper, optics, etc.), we have to prioritize.
As a contributor to Scott’s presentation my position is that what’s important to industry is the standardizing of 50G and 200G Ethernet together, and at a minimum backplane, chip-to-chip and chip-to-module interfaces (LAUI, CAUI-2, CCAUI-4) to enable designing next generation mainstream data center ASICs and switches based on 50G PAM4 technology. This is followed by copper cable, MMF, and short reach SMF to enable 50G and 100G server I/O, and 200G switch uplinks. 400G is already in standardization so that will be available as an uplink option. (As an aside, the pronunciation of CCAUI: kha-ka-wee, sounds like an espresso drink as in “I would like a double kha-ka-wee, 2% milk.”)
The need for 200G Ethernet has been repeatedly challenged as not demonstrated. That misses the point. The need for an Ethernet rate above 100G is clear. 50G servers need faster speed switch uplinks than 100G. The real question is whether that rate is 200G or 400G. Industry roadmap of 10G server I/O with 40G switch uplinks, followed by 25G server I/O with 100G switch uplinks, followed by 50G server I/O with 200G switch uplinks has many strong arguments in favor of it, as in Scott’s presentation.
What has not been demonstrated is a broad industry need for 40G Serial PMDs. In fact just the opposite is the case. Once 50G Ethernet and PMDs are standardized, 40G Ethernet will plateau and decline. That’s because 50G Serial cost will be the same as 40G Serial cost, but offer 25% more bandwidth. Few new deployments will chose 25% less free bandwidth. There will be some 40G Serial applications, but the importance of these is insignificant compared to the need for 200G Ethernet as the next high-volume low-cost datacenter switch uplink rate. This is where the need to prioritize comes into play.
Hopefully the above is enough to start a vigorous discussion on the Reflector of what next Ethernet rate(s) and PMD(s) are important to industry, including their relative priority.