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

Re: [802.3_NGMMF] MPO-24 pin-out definition



Paul 

Thanks for pointing that my version of MPO24 lane assignment still not compatible with structure cabling, actually what I had in mind is below somewhat similar to your option 2:
TX 1 2 3 4 xxxx 5 6 7 8 
Rx 8 7 6 5 xxxx 4 3 2 1 


It is a valid question to raise in context of Ethernet if we should concern ourself with lane number, I would say as long we don’t define breakout applications then we can leave to the MSAs which they have already defined lane numbers.  Hopefully we end up defining an MDI which is compatible with connector definition in the MSAs!

Thanks,
Ali Ghiasi


On May 3, 2018, at 2:27 PM, Kolesar, Paul <PKOLESAR@xxxxxxxxxxxxx> wrote:

Ali,
I agree that the MPO16 lanes assignment is compatible with structured cabling.  I also agree that the MPO24 lanes you first show are incompatible with structured cabling (for applications that care about lane numbers) unless they are first broken out into two separate 12f channels, which is how the QSFP-DD MSA restricts their use today.  But Ethernet does not care about lane numbers, so that restriction does not apply here.
 
I do not agree that your revised lane assignment is compatible with structured cabling.  That revision would have TX1 connect to TX5.  If you read the thread further, you will discover that I’ve already given the assignments that would be generally compatible.  They are, for examples:
 
1) for optical engines that are like (2x) SR4, DR4:
T1 T2 T3 T4 o o o o R8 R7 R6 R5
T5 T6 T7 T8 o o o o R4 R3 R2 R1
 
2) for optical engines that are like SR16:
o o  T1 T2 T3 T4 T5 T6 T7 T8  o o
o o R8 R7 R6 R5 R4 R3 R2 R1 o o
 
where “o” means not used.
 
One question we need to consider is whether we, in the context of Ethernet, need to concern ourselves with lane numbers or not.  So far, for all existing parallel fiber MDIs, we have not.  But for breakout of Ethernet, and MSAs that go beyond Ethernet, the lane numbering is a very real issue. 
 
Regards,
Paul
 
From: Ali Ghiasi [mailto:aghiasi@xxxxxxxxx] 
Sent: Thursday, May 03, 2018 5:03 PM
To: Kolesar, Paul <PKOLESAR@xxxxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>
Cc: STDS-802-3-NGMMF@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGMMF] MPO-24 pin-out definition
 
Paul/Brian
 
The MPO definition in QSFP-dd is compatible with structure cabling but the MPO 24 (2x12) definition in QSFP-dd is not compatible structure cabling.
Below is the definition of MPO24 (2x12) QSFP-dd
TX 1 2 3 4 xxxx 4 3 2 1 RX
TX 5 6 7 8 xxxx 8 7 6 5 RX
the above definition is compatible with dual port of SR4 definition.
 
To make the above MPO24 (2x12) structure cabling compatible one needs to swap the bottom TX and RX lanes to make the connector symmetrical about the center point of connector:
TX 1 2 3 4 xxxx 4 3 2 1 RX
Rx 5 6 7 8 xxxx 8 7 6 5 TX
The above port map is awkward from transceiver perspective.
 
Therefore I agree with Brain that we should specify MPO-16 for 400GBASE-SR8!  
 
 

Thanks,
Ali Ghiasi

 
On May 3, 2018, at 12:38 PM, Kolesar, Paul <PKOLESAR@xxxxxxxxxxxxx> wrote:
 
This is a repeat of my earlier response that was rejected by the IEEE reflector.
 
Brian,
That lane assignment will be compatible with structured cabling using MPO-16.  For completeness, the TX and RX lanes could also be laterally transposed such that it is:
RX1 RX2 …. RX8 TX8 … TX2 TX1.
 
But the assignment you stated below is consistent with the QSFP-DD, so is recommended. 
 
Paul
 
From: Brian Park [mailto:bpark@xxxxxxxxxx] 
Sent: Thursday, May 03, 2018 2:33 PM
To: Kolesar, Paul <PKOLESAR@xxxxxxxxxxxxx>
Cc: Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Chris Cole <chris.cole@xxxxxxxxxxx>; Jeffery Maki <jmaki@xxxxxxxxxxx>; STDS-802-3-NGMMF@xxxxxxxxxxxxxxxxx; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>; tommitcheltree@xxxxxxxxxxx; Steve Hanssen <shanssen@xxxxxxxxxx>; David Lai <davlai@xxxxxxxxxx>; Hong Wang <hwang@xxxxxxxxxx>; zshen@xxxxxxxxxx; Rothermel, Brent R <brent.r.rothermel@xxxxxxxxx>
Subject: Re: MPO-24 pin-out definition
 
Email Security Warning: 
The following message was sent from an external e-mail address. Exercise caution when opening attachments, clicking links, or exchanging information.
Hi All,
 
Regarding OSFP MSA specification at this moment, (OSFP MSA was under revision now)
 
I would like to add MPO 16, same as QSFP-DD to the OSFP MSA specification; but not specifying MPO24 at this moment yet.
<image009.png>
 
Thanks, Brian
 
** Resending without email footer which have confidentiality related statement and caused issue in the emailing.
 
 
 
On Thu, Apr 26, 2018 at 11:01 AM, Kolesar, Paul <PKOLESAR@xxxxxxxxxxxxx> wrote:
+ 802.3cm reflector
 
I am resending this thread to an expanded distribution list, per discussion on today’s task force call for 802.3cm. In this way I hope to draw out the pros and cons list for our alternatives.
 
Does anyone wish to bring a contribution to the May meeting that compiles this comparison for discussion?
 
Paul
 
From: Kolesar, Paul 
Sent: Wednesday, April 25, 2018 11:55 AM
To: 'Gary Nicholl (gnicholl)' <gnicholl@xxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Chris Cole <chris.cole@xxxxxxxxxxx>; Jeffery Maki <jmaki@xxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>
Cc: Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>; tommitcheltree@xxxxxxxxxxx; Steve Hanssen <shanssen@xxxxxxxxxx>; David Lai <davlai@xxxxxxxxxx>; Hong Wang <hwang@xxxxxxxxxx>; zshen@xxxxxxxxxx; Rothermel, Brent R <brent.r.rothermel@xxxxxxxxx>
Subject: RE: MPO-24 pin-out definition
 
Gary,
You’ve pointed out two lane assignment options for the 2x12MPO MDI.  Here are examples of both for applications that are not lane-number agnostic:
 
1) for optical engines that are like (2x) SR4, DR4:
T1 T2 T3 T4 o o o o R8 R7 R6 R5
T5 T6 T7 T8 o o o o R4 R3 R2 R1
 
2) for optical engines that are like SR16:
o o  T1 T2 T3 T4 T5 T6 T7 T8  o o
o o R8 R7 R6 R5 R4 R3 R2 R1 o o
 
where “o” means not used.
 
Not sure about the MIS advertising issue, but in general if there are options then they should be communicated. It will likely be important, especially for breakout and shuffle applications.  
 
Paul
 
From: Gary Nicholl (gnicholl) [mailto:gnicholl@xxxxxxxxx] 
Sent: Wednesday, April 25, 2018 9:52 AM
To: Kolesar, Paul <PKOLESAR@xxxxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Chris Cole <chris.cole@xxxxxxxxxxx>; Jeffery Maki <jmaki@xxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>
Cc: Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>; tommitcheltree@xxxxxxxxxxx; Steve Hanssen <shanssen@xxxxxxxxxx>; David Lai <davlai@xxxxxxxxxx>; Hong Wang <hwang@xxxxxxxxxx>; zshen@xxxxxxxxxx; Rothermel, Brent R <brent.r.rothermel@xxxxxxxxx>
Subject: Re: MPO-24 pin-out definition
Good summary Paul.
 
As you say it all comes down to whether 802.3cm defines a 2x12MPO MPI for 400G-SR8, and if so whether it goes with the current QSFP-DD lane assignment  (which was really only defined for a 2 x breakout application) or the more traditional lane assignment used by 100G-SR10, etc.
 
I agree that if the IEEE adopts the later then QSFP-DD, OSFP and COBO  need to define an alternative lane assignment for 2xMPO-12. 
 
If we do this then there is nothing to prevent a module from using this alternative mapping for “a module housing two transceivers (e.g. 2 x SR-4)”.
 
Does this mean  we potentially have to modify the MIS to allow a module to advertise which version of the lane mapping it is using ?  
 
Gary
 
 
 
From: "Kolesar, Paul" <PKOLESAR@xxxxxxxxxxxxx>
Date: Tuesday, April 24, 2018 at 5:01 PM
To: Brian Welch <bwelch@xxxxxxxxxxx>, Chris Cole <chris.cole@xxxxxxxxxxx>, Jeffery Maki <jmaki@xxxxxxxxxxx>, Brian Park <bpark@xxxxxxxxxx>
Cc: Gary Nicholl <gnicholl@xxxxxxxxx>, Mark Nowell <mnowell@xxxxxxxxx>, "Tiger Ninomiya (Takuya)" <Takuya.Ninomiya@xxxxxxxxx>, John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>, Tom Palkert <tom.palkert@xxxxxxxxx>, Scott Sommers <Scott.Sommers@xxxxxxxxx>, Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>, "tommitcheltree@xxxxxxxxxxx" <tommitcheltree@xxxxxxxxxxx>, Steve Hanssen <shanssen@xxxxxxxxxx>, David Lai <davlai@xxxxxxxxxx>, Hong Wang <hwang@xxxxxxxxxx>, "zshen@xxxxxxxxxx" <zshen@xxxxxxxxxx>
Subject: RE: MPO-24 pin-out definition
 
Thanks for chiming in.  I don’t think there is a difference in how the module form factors are viewed for SM vs MM. 
 
Double density modules can be seen as housing two transceivers, which are broken out before hitting permanent structured cabling at the patch panel.  That’s how the QSFP-DD MSA treats the 2x12MPO interface. 
 
However, the 400G-SR8 PMD is being defined as a 400G interface.  And although it will often be used for breakout or shuffle, it should operate over structured cabling intact.  It can do that for Ethernet with either the MPO16 or the 2x12MPO lane assignments of the QSFP-DD because Ethernet is lane-number agnostic.  So, at least as far as Ethernet is concerned, the double-module viewpoint does not seem to provide a reason to choose one MDI over the other.
 
What can be affected if Ethernet chooses the 2x12MPO interface is that the QSFP-DD MSA will need to further clarify that there are two cases for the 2x12MPO – one for a module housing two transceivers, and another for a module housing a single transceiver.  The former is what is handled now.  The latter is missing.  If the latter is added, and is permitted to be used for applications that are not lane-number agnostic, then the current lane assignment numberings will need to be defined with a second alternative that is compatible with structured cabling.
 
Paul
 
From: Brian Welch [mailto:bwelch@xxxxxxxxxxx] 
Sent: Tuesday, April 24, 2018 2:47 PM
To: Kolesar, Paul <
PKOLESAR@xxxxxxxxxxxxx>; Chris Cole <chris.cole@xxxxxxxxxxx>; Jeffery Maki <jmaki@xxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>
Cc: Gary Nicholl (gnicholl) <
gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>; tommitcheltree@xxxxxxxxxxx; Steve Hanssen <shanssen@xxxxxxxxxx>; David Lai <davlai@xxxxxxxxxx>; Hong Wang <hwang@xxxxxxxxxx>; zshen@xxxxxxxxxx
Subject: RE: MPO-24 pin-out definition
I see a difference between single density and double density modules. For the case being discussed imagine a 2x100G-PSM4 module, or in the future perhaps a 2x400G-DR4 module, the market views these differently than they would a 1x200G module or a 1x800G module insofar as they are essentially always used for breakout (ie, interface to two MPO12 based MDIs).
 
Not sure if it’s different for MMF solutions.
 
Brian
 
From: Kolesar, Paul [mailto:PKOLESAR@xxxxxxxxxxxxx] 
Sent: Tuesday, April 24, 2018 11:32 AM
To: Chris Cole <
chris.cole@xxxxxxxxxxx>; Jeffery Maki <jmaki@xxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>
Cc: Brian Welch <
bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>;tommitcheltree@xxxxxxxxxxx; Steve Hanssen <shanssen@xxxxxxxxxx>; David Lai <davlai@xxxxxxxxxx>; Hong Wang <hwang@xxxxxxxxxx>; zshen@xxxxxxxxxx
Subject: RE: MPO-24 pin-out definition
 
Chris,
I don’t see anyone on this thread proposing to discard MPO16.  But there was recognition that not everyone prefers that interface.  I know this from talking to people.  And that’s why I anticipate debate. 
 
You are right that in the past we have defined multiple MDIs.  Just look at 100G-SR10 for a place where three configurations were put into the standard. 
 
I think the main question is whether the proposed MPO16 interface, said to be supported by many companies, should be the only one in the standard.  If the 2x12MPO interface is proposed by someone, what advantage does it offer, and is that advantage worth putting only it or both in the standard.  To that end, a contribution citing some pros and cons for each alternative would be helpful.
 
Paul
 
From: Chris Cole [mailto:chris.cole@xxxxxxxxxxx] 
Sent: Tuesday, April 24, 2018 1:50 PM
To: Kolesar, Paul <
PKOLESAR@xxxxxxxxxxxxx>; Jeffery Maki <jmaki@xxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>
Cc: Brian Welch <
bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>;tommitcheltree@xxxxxxxxxxx; Steve Hanssen <shanssen@xxxxxxxxxx>; David Lai <davlai@xxxxxxxxxx>; Hong Wang <hwang@xxxxxxxxxx>; zshen@xxxxxxxxxx
Subject: RE: MPO-24 pin-out definition
 
MPO16 is a known application, supported by many companies, so we should not be casually proposing to discard it. This is not a way to build consensus.
 
 
If there is another application that requires MPO2x12, then the proponents need to put together a presentation showing the applications and lining up supporters. Right now I don’t see a real application for SR8 in MPO2x12. It’s just a theoretical possibility.
 
If we determine, based on supported contributions, that there is also broad market potential for MPO2x12 SR8, we will specify two connectors in the standard; MPO16 and MPO2x12. We have done that in the past when we had multiple connector requirements for the same PMD.
 
Chris
 
From: Kolesar, Paul [mailto:PKOLESAR@xxxxxxxxxxxxx] 
Sent: Monday, April 23, 2018 6:01 AM
To: Jeffery Maki <
jmaki@xxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>
Cc: Chris Cole <
chris.cole@xxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>; tommitcheltree@xxxxxxxxxxx; Steve Hanssen <shanssen@xxxxxxxxxx>; David Lai <davlai@xxxxxxxxxx>; Hong Wang <hwang@xxxxxxxxxx>
Subject: [EXTERNAL]: RE: MPO-24 pin-out definition
 
Jeff,
I agree.  The initial proposal for SR8 used the MPO16.  There are others who prefer the 2x12MPO.  I don’t know how it will shake out.
Paul
 
From: Jeffery Maki [mailto:jmaki@xxxxxxxxxxx] 
Sent: Monday, April 23, 2018 8:55 AM
To: Kolesar, Paul <
PKOLESAR@xxxxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>
Cc: Chris Cole <
chris.cole@xxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>; tommitcheltree@xxxxxxxxxxx; Steve Hanssen <shanssen@xxxxxxxxxx>; David Lai <davlai@xxxxxxxxxx>; Hong Wang <hwang@xxxxxxxxxx>
Subject: RE: MPO-24 pin-out definition
 
Email Security Warning:
The following message was sent from an external e-mail address. Exercise caution when opening attachments, clicking links, or exchanging information.
Paul,
 
Yes, so this shall likely have equal impact on QSFP-DD, OSFP, and COBO. A common module is likely going to be looked to function as 400GBASE-SR8, 2 x 200GBASE-SR4, 4 x 100GBASE-2, 8 x 50GBASE-SR.
 
Jeff
 
From: Kolesar, Paul <PKOLESAR@xxxxxxxxxxxxx> 
Sent: Monday, April 23, 2018 5:40 AM
To: Jeffery Maki <
jmaki@xxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>
Cc: Chris Cole <
chris.cole@xxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>; tommitcheltree@xxxxxxxxxxx; Steve Hanssen <shanssen@xxxxxxxxxx>; David Lai <davlai@xxxxxxxxxx>; Hong Wang <hwang@xxxxxxxxxx>
Subject: RE: MPO-24 pin-out definition
 
Jeff,
We are developing 400G-SR8 in 802.3cm.  I believe there is going to be debate on the MDI lane assignments.  
Paul
 
From: Jeffery Maki [mailto:jmaki@xxxxxxxxxxx] 
Sent: Monday, April 23, 2018 4:36 AM
To: Kolesar, Paul <
PKOLESAR@xxxxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>
Cc: Chris Cole <
chris.cole@xxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>; tommitcheltree@xxxxxxxxxxx; Steve Hanssen <shanssen@xxxxxxxxxx>; David Lai <davlai@xxxxxxxxxx>; Hong Wang <hwang@xxxxxxxxxx>
Subject: RE: MPO-24 pin-out definition
 
Email Security Warning:
The following message was sent from an external e-mail address. Exercise caution when opening attachments, clicking links, or exchanging information.
Paul,
 
QSFP-DD, COBO and OSFP are striving to be the same in terms of electrical pin to optical port mappings. Certainly, they are all striving to use a common management interface specification, The CMIS. If it were found to be of high merit for something new to be defined for OSFP, we should probably find that merit to extend to QSFP-DD and COBO too.
 
Is there something new emerging?
 
Jeff
 
From: Kolesar, Paul <PKOLESAR@xxxxxxxxxxxxx> 
Sent: Sunday, April 22, 2018 7:13 AM
To: Brian Park <
bpark@xxxxxxxxxx>; Jeffery Maki <jmaki@xxxxxxxxxxx>
Cc: Chris Cole <
chris.cole@xxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>; tommitcheltree@xxxxxxxxxxx; Steve Hanssen <shanssen@xxxxxxxxxx>; David Lai <davlai@xxxxxxxxxx>; Hong Wang <hwang@xxxxxxxxxx>
Subject: RE: MPO-24 pin-out definition
 
The below message was sent before complete.  I have now completed it below.
Paul
 
From: Kolesar, Paul 
Sent: Sunday, April 22, 2018 9:44 AM
To: Brian Park <
bpark@xxxxxxxxxx>; Jeffery Maki <jmaki@xxxxxxxxxxx>
Cc: Chris Cole <
chris.cole@xxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>; tommitcheltree@xxxxxxxxxxx; Steve Hanssen <shanssen@xxxxxxxxxx>; David Lai <davlai@xxxxxxxxxx>; Hong Wang <hwang@xxxxxxxxxx>
Subject: RE: MPO-24 pin-out definition
 
Brian,
I find it curiously restrictive of a transceiver with eight electrical inputs and eight electrical outputs to not have the option to use an optical interface that offers the capacity for each of those signals to be carried on its own fiber.  The MPO16 and 2x12MPO are the obvious choices to fill that vacancy.  
 
With these interfaces there is no advantage that I can see for straying from the lane assignments of the QSFP-DD for the MPO16.  However, there should be debate on the lane assignments for the 2x12MPO.  
 
As I understand the situation with the QSFP-DD, the lane assignments were selected to allow two optical engines, each with four Tx and four Rx, to be placed such that each one occupies a row of the MPO.  In effect this allows implementation by stacking two planar transceivers circuits, and was driven by how companies build 4-lane devices.
 
The question is whether that same mindset should be applied here. 
 
There is an alternative for modules with more than four Tx and Rx, which is exemplified by the lane assignments defined for 100G-SR10 and 400G-SR16.  For these there is a row dedicated to Tx and a row dedicated to Rx. 
 
The trouble with the QSFP-DD 2x12MPO assignments is that the two rows must each be broken out to be properly routed over standardized structured cabling.  This allows Tx1 to connect to Rx1.  If not broken out, that Tx1 will connect to Rx5 because standardized structured cabling applies a lateral signal transposition and row transposition.  This may be acceptable to protocols that are lane agnostic, such as Ethernet, but that cannot be said for all applications.
 
To be complete, the same transpositions occur for any lane assignment (e.g. upper left connects to lower right), so an existing alternative for a row of Tx over a row of Rx would need to consider that in its lane numbering for applications that are not lane-number agnostic.  That means, for example:
 
Tx1 Tx2 … Tx7 Tx8
Rx8 Rx7 … Rx2 Rx1
 
Regards,
Paul
 
From: Brian Park [mailto:bpark@xxxxxxxxxx] 
Sent: Saturday, April 21, 2018 2:02 PM
To: Jeffery Maki <
jmaki@xxxxxxxxxxx>
Cc: Chris Cole <
chris.cole@xxxxxxxxxxx>; Kolesar, Paul <PKOLESAR@xxxxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>; tommitcheltree@xxxxxxxxxxx; Steve Hanssen <shanssen@xxxxxxxxxx>; David Lai <davlai@xxxxxxxxxx>; Hong Wang <hwang@xxxxxxxxxx>
Subject: Re: MPO-24 pin-out definition
 
Email Security Warning:
The following message was sent from an external e-mail address. Exercise caution when opening attachments, clicking links, or exchanging information.
Hi All,
 
I am afraid that I need to revive this year-old email thread- on the OSFP MSA and MPO lane assignment.
 
Last time we had discussion on the MPO16 and MPO24 (MPO12 two row) lane assignment; and in the OSFP MSA, those has been not specified.
 
Senko (Tiger N.) commented to have MPO16 and MPO24 specification in OSFP MSA, same as QSFP-DD specification.
Below is latest QSFP-DD specification:
<image010.png>
in OSFP-MSA, there is no MPO16 or MPO24. Frankly saying I wished stay away from the issue until industry settles before next revision.
 
A year passed, and I would like hear the opinion on this matter.
 
Thanks, Brian
 
 
On Thu, Apr 20, 2017 at 5:17 PM, Jeffery Maki <jmaki@xxxxxxxxxxx> wrote:
Chris,
 
I’m not going to put this subject first on Wednesday. I thought I was being accommodating to provide means of earlier presentation by using remaining time on Tuesday, if any. I can put it on the Wednesday schedule if that is the preference.
 
Jeff
 
 
From: Chris Cole [mailto:chris.cole@xxxxxxxxxxx] 
Sent: Thursday, April 20, 2017 5:06 PM

To: Jeffery Maki <
jmaki@xxxxxxxxxxx>; Kolesar, Paul <PKOLESAR@xxxxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>; tommitcheltree@xxxxxxxxxxx
Subject: RE: MPO-24 pin-out definition
 
This makes it harder to plan attendance.
 
From: Jeffery Maki [mailto:jmaki@xxxxxxxxxxx] 
Sent: Thursday, April 20, 2017 4:57 PM
To: Chris Cole <
chris.cole@xxxxxxxxxxx>; Kolesar, Paul <PKOLESAR@xxxxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>;tommitcheltree@xxxxxxxxxxx
Subject: RE: MPO-24 pin-out definition
 
Chris,
 
If DCN begins on Tuesday owing to CohOBO finishing early with its agenda, then I may have this topic covered Tuesday so it can be discussed during the evening social and more definitive action/recommendations decided by Wednesday.
 
Jeffery Maki
COBO DCN Working Group Chairman
 
From: Chris Cole [mailto:chris.cole@xxxxxxxxxxx] 
Sent: Thursday, April 20, 2017 4:53 PM
To: Kolesar, Paul <
PKOLESAR@xxxxxxxxxxxxx>; Jeffery Maki <jmaki@xxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>;tommitcheltree@xxxxxxxxxxx
Subject: RE: MPO-24 pin-out definition
 
I assume this will be discussed in the DCN portion on Wednesday?
 
From: Kolesar, Paul [mailto:PKOLESAR@xxxxxxxxxxxxx] 
Sent: Thursday, April 20, 2017 4:24 PM
To: Jeffery Maki <
jmaki@xxxxxxxxxxx>; Chris Cole <chris.cole@xxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>; tommitcheltree@xxxxxxxxxxx
Subject: RE: MPO-24 pin-out definition
 
Jeff,
I am glad to assist.  Mitch is taking the lead with a contribution.  He may be able to run it past me for review.  If so, I will try to ensure the rules are well articulated in that contribution.  I hope that it suffices for whatever Tiger may also have in mind and therefore obviate the need for multiple contributions.
Paul
 
 
From: Jeffery Maki [mailto:jmaki@xxxxxxxxxxx] 
Sent: Thursday, April 20, 2017 6:14 PM
To: Kolesar, Paul <
PKOLESAR@xxxxxxxxxxxxx>; Chris Cole <chris.cole@xxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>;tommitcheltree@xxxxxxxxxxx
Subject: RE: MPO-24 pin-out definition
 
Paul,
 
Can you help Tiger to present the “rules” presently in place for structured cabling and patchcording to the COBO membership? We are meeting Tuesday and Wednesday next week.
 
Jeff
 
From: Kolesar, Paul [mailto:PKOLESAR@xxxxxxxxxxxxx] 
Sent: Thursday, April 20, 2017 3:35 PM
To: Chris Cole <
chris.cole@xxxxxxxxxxx>; Jeffery Maki <jmaki@xxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>; tommitcheltree@xxxxxxxxxxx
Subject: RE: MPO-24 pin-out definition
 
Chris,
Because this choice affects cabling connectivity, true consensus on any new fiber routing requirements can only be achieved with the support of TIA TR-42.11.  This was true of 100G-SR10 and 400G-SR16.  
 
One major difference is that IEEE has liaisons with TIA TR-42, while COBO and the MSAs do not.  That communications channel must be established.  Tom Mitcheltree is working with TIA to open that communication.  He has gained permission to share parts of TIA-568.3-D with the groups.  I anticipate a contribution from him next week.  But written communications would serve to fully close the loops. 
 
Paul
 
From: Chris Cole [mailto:chris.cole@xxxxxxxxxxx] 
Sent: Thursday, April 20, 2017 4:52 PM
To: Jeffery Maki <
jmaki@xxxxxxxxxxx>; Kolesar, Paul <PKOLESAR@xxxxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>;tommitcheltree@xxxxxxxxxxx
Subject: RE: MPO-24 pin-out definition
 
Let’s try to reach some consensus on this at the COBO DNC meeting next week.

Chris
 
From: Jeffery Maki [mailto:jmaki@xxxxxxxxxxx] 
Sent: Monday, April 17, 2017 8:00 PM
To: Kolesar, Paul <
PKOLESAR@xxxxxxxxxxxxx>; Chris Cole <chris.cole@xxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>;tommitcheltree@xxxxxxxxxxx
Subject: RE: MPO-24 pin-out definition
 
Paul,
 
Parallel single mode optics are more likely to share a common laser with individual modulators for the lanes. This shared fate of the lanes in the event of laser failure prompts that one would not likely build an interface by selecting lanes from more than one of these shared risk groups. For VCSEL optics, each lane has its only laser and direct modulation.
 
Curiously, I am in the middle of consideration of how to devise multi-wavelength coherent transceivers such as the selection of the electrical pin map and optical port map. Beyond two wavelengths, the consideration is very confusing as to what should be the determining factor.
 
Jeff
 
From: Kolesar, Paul [mailto:PKOLESAR@xxxxxxxxxxxxx] 
Sent: Monday, April 17, 2017 7:10 PM
To: Jeffery Maki <
jmaki@xxxxxxxxxxx>; Chris Cole <chris.cole@xxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>; tommitcheltree@xxxxxxxxxxx
Subject: RE: MPO-24 pin-out definition
 
Jeff,
I suppose that potential future 8-pair applications are not included amongst those you have considered within the supported set.  If nothing else, I hope to make the complete MSA and COBO groups aware of this trade-off.  This must be an informed and conscious decision. 
 
Regarding your return to the issue of wanting to see differences between MM and SM cabling polarity, I will respond by pointing out that the purpose of having structure in structured cabling is two-fold:
1) to allow cabling to support a wide variety of applications,
2) to create cabling practices that have common themes to keep rules as simple as possible.
 
Specific to array connectivity, the current standards fulfilled the above criteria by applying consistent rules that evolved out of a need to support all the standard applications in existence at the time.  While most parallel applications were multimode-based, the HIPPI standard was also single-mode.  And the lane assignments of a QSFP are common to both media types.  That means we have succeeded in defining cabling that is media independent.  Diverging now would relinquish that unity and thereby drive substantial additional complexity. 
 
I am confused by your answer to “how will the user know?”. Why is it acceptable for the user to have to know what type of transceiver they purchased if it is single-mode, but that same logic fails for multimode?  Is it because of the types of transceivers already in existence, with SM devices being of smaller variety?  Or is it because of some reconfiguration capability that makes MM devices more flexible?   
 
Paul
 
From: Jeffery Maki [mailto:jmaki@xxxxxxxxxxx] 
Sent: Monday, April 17, 2017 7:47 PM
To: Kolesar, Paul <
PKOLESAR@xxxxxxxxxxxxx>; Chris Cole <chris.cole@xxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>;tommitcheltree@xxxxxxxxxxx
Subject: RE: MPO-24 pin-out definition
 
Paul,
 
All the applications we can think of are supported by the current QSFP-DD electrical pin map and optical port map given in the published QSFP-DD specification. None break the two rules I outlined. At Juniper, we can even support any application using one or more Tx/Rx SERDES within a group of eight. Most will also be able to support dual rate electrical lanes, 50G and 25G.
 
For parallel single mode applications, the end user ought to know what kind of module they purchased. For parallel multi-mode application, I agree they would not know and should be able to support all the applications with a common module. This is why I keep asking why SMF and MMF applications should be bound by the same requirements.
 
Jeff
 
From: Kolesar, Paul [mailto:PKOLESAR@xxxxxxxxxxxxx] 
Sent: Monday, April 17, 2017 4:08 PM
To: Jeffery Maki <
jmaki@xxxxxxxxxxx>; Chris Cole <chris.cole@xxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>; tommitcheltree@xxxxxxxxxxx
Subject: RE: MPO-24 pin-out definition
 
+ Tom Mitcheltree
 
Jeff,
Given restrictions on reconfiguration of lanes within the present MAC, I think you know it is not possible to reconfigure the interface for both dual-QSFP and 8-lane-aggregate interfaces that require a change to lane assignments among the groups of four. 
 
Ways around this are:
1) design MACs with such capability;
2) change equipment cords to suit the deployment configuration of the transceiver;
3) select a subset of possible transceiver utilities and live without support for other(s).
 
Item 2) and perhaps item 3) will require interaction with cabling standards groups.  I am aware of activity undertaken by Tom Mitcheltree to increase the MSA group’s understanding of array connectivity by presentation and most recently by formal request of TIA to share the 568 standard.  But while this may serve to inform, it is not a substitute for correspondence.  Such correspondence should become the norm for all connectivity concepts that aim to use structured cabling and are not already included in TIA-568.
 
To that end, I am seeking an answer to my question that I’ll repeat here.  From a user’s perspective, how are they to know whether the device is presenting a 2-row composite interface or two single-row interfaces?  Without this insight, selection of the proper equipment cord or deployment configuration seems like hit or miss. 
 
Regards,
Paul
 
 
From: Jeffery Maki [mailto:jmaki@xxxxxxxxxxx] 
Sent: Monday, April 17, 2017 4:00 PM
To: Kolesar, Paul <
PKOLESAR@xxxxxxxxxxxxx>; Chris Cole <chris.cole@xxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>
Subject: RE: MPO-24 pin-out definition
 
Paul,
 
You wrote:
The alternative I’ve suggested is a reassignment of the lane numbers.  I don’t know why this would affect the optical engines.  I think it just affects the electrical pin assignments associated with each engine.  If I am wrong, please tell me why.
 
Please proceed to make your electrical pin assignments of choice over all the various single and multiport (breakout) applications. Please be sure that at the host ASIC that a Tx/Rx SERDES pair can be used to support all the cases you propose. After that, please be sure that Tx/Rx SERDES in two groups of four at the host ASIC can also support all the necessary applications below 400GE in QSFP-DD. We cannot find we have to connect between the two groups of four Tx/Rx SERDES pairs to support some applications. Gary Nicholl can better represent the restrictions.
 
As I recall, your earlier ideas cause Tx/Rx pairs at the host ASIC needing to be different depending upon application.
 
Jeff
 
From: Kolesar, Paul [mailto:PKOLESAR@xxxxxxxxxxxxx] 
Sent: Monday, April 17, 2017 1:38 PM
To: Chris Cole <
chris.cole@xxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Jeffery Maki <jmaki@xxxxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>
Subject: RE: MPO-24 pin-out definition
 
Sorry for my tardy delay.  Last week was disrupted by meetings, then time off for the holiday. 
 
Chris,
My concern is for when the interface is used as a single entity.  The present structured cabling standard, ANSI/TIA 568.3-D provides connectivity details for four types of interfaces that operate over array-terminated cabling: 
1) Support for multi-duplex where the array-terminated trunk cable breaks out to multiple 2-fiber transceivers.
2) Support for single-row parallel transceiver arrays like the typical QSFP lane assignments.
3) Support for two-row parallel transceiver arrays over single-row cabling.  Each row travels over a separate single-row cabling infrastructure and gets row-transposed in the process.
4) Support for two-row parallel transceiver arrays over two-row cabling. 
 
While you may think that connectivity item 3) covers the break out scenario you have been describing, strictly speaking it does not because of the standard’s row transposition.  While it is possible to use the same equipment cords, these cords get attached to the patch panel differently than the standard method.  Here is a diagram that may help.
 
<image011.png>
 
In this diagram from TIA-568.3-D, the two equipment cords are deployed exactly the same way at both ends of the trunk which is composed of two single-row cables.  In this way the row transposition is achieved.  
 
In the break-out scenario you describe, one (and only one) of these cords must be plugged into the trunk ports in swapped locations.  This will remove the row transposition.  
 
While this latter construct can certainly be achieved, it is a new construct that is not represented in the cabling standard.  As such it requires correspondence with TIA TR-42 and, if accommodated, will require a revision of the cabling standard.  So I hope you appreciate the impact of your choices.  It is not simply one that affects the MSAs.  It affects the cabling industry too.   
 
The alternative I’ve suggested is a reassignment of the lane numbers.  I don’t know why this would affect the optical engines.  I think it just affects the electrical pin assignments associated with each engine.  If I am wrong, please tell me why.
 
I do appreciate the concept of packaging two QSFPs into one device.  But from a user’s perspective, how are they to know by looking at the transceiver receptacle whether the device is presenting a 2-row composite interface or two single-row interfaces? 
 
Paul
 
From: Chris Cole [mailto:chris.cole@xxxxxxxxxxx] 
Sent: Monday, April 17, 2017 11:54 AM
To: Kolesar, Paul <
PKOLESAR@xxxxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>; Jeffery Maki <jmaki@xxxxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>; John F Petrilla <john.petrilla@xxxxxxxxxxxxxxxx>; Brian Park <bpark@xxxxxxxxxx>; Tom Palkert <tom.palkert@xxxxxxxxx>; Sommers, Scott <Scott.Sommers@xxxxxxxxx>; Brian Kirk <brian.kirk@xxxxxxxxxxxxxxxx>
Subject: RE: MPO-24 pin-out definition
 
Paul
 
Can you let us know if your concerns extend to 2x12 connector breaking out to 1x12 cables.
 
If this is not a concern, then we may have a consensus position of restricting the definition to 2x100G and 2x200G break-out, and deferring definition of 8x applications, and we can move forward with a common definition for all MSAs.
 
Chris
 
From: Chris Cole 
Sent: Thursday, April 13, 2017 2:25 PM
To: 'Brian Welch' <
bwelch@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Kolesar, Paul <PKOLESAR@xxxxxxxxxxxxx>; Jeffery Maki <jmaki@xxxxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>
Cc: Mark Nowell (mnowell) <
mnowell@xxxxxxxxx>
Subject: RE: MPO-24 pin-out definition
 
Paul
 
As I understand your concerns, they have to do with running 2x12 cabling across a structured datacenter.
 
If the first thing that happens is the 2x12 MPO is broken out into two 1x12 cables, using conventional TxTxTxTxNcNcNcNcRxRxRxRx configuration, do your concerns go away?
 
Chris
 
From: Brian Welch [mailto:bwelch@xxxxxxxxxxx] 
Sent: Tuesday, April 11, 2017 9:08 AM
To: Gary Nicholl (gnicholl) <
gnicholl@xxxxxxxxx>; Kolesar, Paul <PKOLESAR@xxxxxxxxxxxxx>; Jeffery Maki <jmaki@xxxxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>
Cc: Chris Cole <
chris.cole@xxxxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>
Subject: RE: MPO-24 pin-out definition
 
I was asked to comment on the lane mapping Paul showed below…. I would not be able to do that without incredible difficulty/cost.
 
For context the discussion we had in QSFP-DD focused on the MPO24 for breakout, and the MPO16 for potential native eight lane standards (although none exist thus far). We have customers that use MPO24 in the manner currently described in QSFP-DD, and long term want to be able to scale up in rows if they are adding more density (ie, an MPO48 for a four port interface).
 
Brian
 
From: Gary Nicholl (gnicholl) [mailto:gnicholl@xxxxxxxxx] 
Sent: Monday, April 10, 2017 2:24 PM
To: Kolesar, Paul <
PKOLESAR@xxxxxxxxxxxxx>; Jeffery Maki <jmaki@xxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>
Cc: Chris Cole <
chris.cole@xxxxxxxxxxx>; Mark Nowell (mnowell) <mnowell@xxxxxxxxx>
Subject: Re: MPO-24 pin-out definition
 
Paul,
 
Thanks for the clarification. For my understanding can you explain how the pinout below is different from the one in the current QSFP-DD MSA document and why it is better (presumable for an 8-lane interface, because  in the case of breakout it doesn’t matter as the patch cord will breakout to 2 x standard 4-lane  MPO-12 connectors no matter how it is defined on the MPO-24 )?
 
<image012.png>
 
Obviously  one downside of your pinout below  for a 2 x 4-lane optical engine implementation is that it requires each optical engine to connect to both rows of the MPO-24, rather than each optical engine  connecting to a single row as would be the case for the optical engine in a standard 4-lane application. I am not sure if this is a big issue from a module implementation or not (perhaps Brian or Chris can comment here). 
 
Perhaps one advantage of your pinout is that the automatic flip which occurs with a 24 fiber ribbon would connect T0<>R0, T1<>R1, T2<>R2, etc … whereas if the current QSFP-DD pinout was used for a single (no breakout) 8-lane solution then T0<>R4, T1<>R5, T2<>R6, etc. At least for Ethernet this is not an issue as the PCS is designed to accommodate (and undo) such as cross-over.
 
I apologize in advance for any dumb questions as I am still new to all of this structured cabling stuff, and I always get a headache any time I work with (or think about)  ribbon fibers 
 
Gary
 
 
From: "Kolesar, Paul" <PKOLESAR@xxxxxxxxxxxxx>
Date: Monday, April 10, 2017 at 4:08 PM
To: Jeffery Maki <
jmaki@xxxxxxxxxxx>, Gary Nicholl <gnicholl@xxxxxxxxx>, Brian Welch <bwelch@xxxxxxxxxxx>, "Tiger Ninomiya (Takuya)" <Takuya.Ninomiya@xxxxxxxxx>
Cc: Chris Cole <
chris.cole@xxxxxxxxxxx>
Subject: RE: MPO-24 pin-out definition
 
Jeff,
I have not seen my message that analyzes the total situation being shared with the group.  But it does include a lane assignment option that allows integrated engines.  Here it is.  Each of the two engines can be across a row, but the lane pairs need to be split between rows.   That can be accommodated by choosing electrical lanes that correspond. 
<image013.png>
Paul
 
From: Jeffery Maki [mailto:jmaki@xxxxxxxxxxx] 
Sent: Monday, April 10, 2017 2:36 PM
To: Kolesar, Paul <
PKOLESAR@xxxxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>
Cc: Chris Cole <
chris.cole@xxxxxxxxxxx>
Subject: RE: MPO-24 pin-out definition
 
Paul,
 
My concern is that your point of view or the point of view of the TIA is unfriendly to SMF optics. As I see it, the TIA is presuming that the industry will be best served by making separate transmitter and receiver engines and structured cabling is forcing this point of view on module integrators.
 
Jeff
 
From: Kolesar, Paul [mailto:PKOLESAR@xxxxxxxxxxxxx] 
Sent: Monday, April 10, 2017 12:32 PM
To: Jeffery Maki <
jmaki@xxxxxxxxxxx>; Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>
Cc: Chris Cole <
chris.cole@xxxxxxxxxxx>
Subject: RE: MPO-24 pin-out definition
 
The discussion is fragmenting into private exchanges.  I just responded to Jeff’s concern.  Contrary to his perception that my view sees the lane assignments as unfriendly to MM optics, my actual concern is not related to a specific media at all.  It is simply trying to ensure the new interfaces work well over structured cabling regardless of fiber type.  My assessment does recognize the dual-QSFP breakout optimization of the assignments of the QSFP-DD, but it also points out that in trade the interface gives up compatibility with structured cabling as an 8-pair interface. 
 
 
Paul
 
From: Jeffery Maki [mailto:jmaki@xxxxxxxxxxx] 
Sent: Monday, April 10, 2017 2:03 PM
To: Gary Nicholl (gnicholl) <
gnicholl@xxxxxxxxx>; Kolesar, Paul <PKOLESAR@xxxxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>
Cc: Chris Cole <
chris.cole@xxxxxxxxxxx>
Subject: RE: MPO-24 pin-out definition
 
Gary,
 
Here is the note I just sent to Paul. His argument is that what we defined in QSFP-DD is breaking rules of structured cabling. He sees what QSFP-DD defined to be unfriendly to MMF optics. I’m trying first to understand where the rules came from, etc.
 
From: Jeffery Maki 
Sent: Monday, April 10, 2017 11:29 AM
To: 'Kolesar, Paul' <
PKOLESAR@xxxxxxxxxxxxx>; Chris Cole <chris.cole@xxxxxxxxxxx>
Subject: RE: QSFP-DD and OSPF lane assignment concerns
 
Paul,
 
Before I send this to the core group, which I think should happen before sending it to the respective MSA Groups, I think you should respond to my fundamental issue. Why should MMF structured cabling and SMF structured cabling follow the same prescription? Why do they have to follow the same rule? Seems like an arbitrary rule presuming such an arbitrary rule causes no burden. Implementation of the optical transceiver are different between VCSEL optics and silicon photonics that leads to a different sense of what is optimal or even necessary. You have used your perception of optimal MDI for MMF to take things forward. Why not start with the necessities of SMF optics and work forwards from there?
 
I think you should expand your response to address my concern or I believe others will just raise it.
 
Jeff
 
Jeff
 
From: Gary Nicholl (gnicholl) [mailto:gnicholl@xxxxxxxxx] 
Sent: Monday, April 10, 2017 11:47 AM
To: Jeffery Maki <
jmaki@xxxxxxxxxxx>; Kolesar, Paul <PKOLESAR@xxxxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>
Cc: Chris Cole <
chris.cole@xxxxxxxxxxx>
Subject: Re: MPO-24 pin-out definition
 
I agree that it would be good to review in a small group first, before opening the discussion to the world.
 
For background the current MPO-24 (really MPO-12 two row) pinout was defined to make it easy to support dual 4-lane 100G optics in a QSFP-DD and to connect to 2 x existing 4-lane 100G optical engines inside the module (e.g. 100G SR4 or 100G PSM4).  This is therefore a breakout application, with the assumption that there is a breakout cable that would convert from MPO-24 on one end to 2 x (standard) MPO-12 4-lane 100G pinouts.  (SR4 or PSM4) on the other end.  It is these standard MPO-12 dongles that would then connect into the structured cabling (just as they would if they came from a 100G SR4 or PSM4  QSFP28 module with an MPO-12 connector).  In my mind this is no different to a MPO to nx Duplex LC breakout application, where it is the Duplex LCs (and not the MPO) that is the interface to the structured cabling environment (at least that is my understanding, and someone can correct me if this is not the case)
 
Gary
 
From: Jeffery Maki <jmaki@xxxxxxxxxxx>
Date: Monday, April 10, 2017 at 1:52 PM
To: Gary Nicholl <
gnicholl@xxxxxxxxx>, "Kolesar, Paul" <PKOLESAR@xxxxxxxxxxxxx>, Brian Welch <bwelch@xxxxxxxxxxx>, "Tiger Ninomiya (Takuya)" <Takuya.Ninomiya@xxxxxxxxx>
Cc: Chris Cole <
chris.cole@xxxxxxxxxxx>
Subject: RE: MPO-24 pin-out definition
 
All,
 
I took the weekend off. I will work on this now. I need to work with Paul on the message before I send. I will only send to this core group first.
 
Jeff
 
From: Gary Nicholl (gnicholl) [mailto:gnicholl@xxxxxxxxx] 
Sent: Monday, April 10, 2017 10:27 AM
To: Kolesar, Paul <
PKOLESAR@xxxxxxxxxxxxx>; Jeffery Maki <jmaki@xxxxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Tiger Ninomiya (Takuya) <Takuya.Ninomiya@xxxxxxxxx>
Cc: Chris Cole <
chris.cole@xxxxxxxxxxx>
Subject: Re: MPO-24 pin-out definition
 
Paul,
 
I have not seen anything yet.
 
Gary
 
From: "Kolesar, Paul" <PKOLESAR@xxxxxxxxxxxxx>
Date: Sunday, April 9, 2017 at 6:43 AM
To: Jeffery Maki <
jmaki@xxxxxxxxxxx>, Gary Nicholl <gnicholl@xxxxxxxxx>, Brian Welch <bwelch@xxxxxxxxxxx>, "Tiger Ninomiya (Takuya)" <Takuya.Ninomiya@xxxxxxxxx>
Cc: Chris Cole <
chris.cole@xxxxxxxxxxx>
Subject: RE: MPO-24 pin-out definition
 
Jeff,
Thanks for reaching out to Gary, Brian and Tiger.
 
Gary, Brian, Tiger,
I’ve composed a detailed email that assesses the situation and makes proposals for several alternative lane assignments.  I’ve asked Jeff or Chris to distribute it to both MSAs and COBO.  Not being a member of any of those groups, I’m don’t know if that has yet happened.  Hopefully it will instill discussion among the groups to find a common assignment. 
 
Paul
 
From: Jeffery Maki [mailto:jmaki@xxxxxxxxxxx] 
Sent: Thursday, April 06, 2017 9:08 PM
To: Gary Nicholl (gnicholl) <
gnicholl@xxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>; Kolesar, Paul <PKOLESAR@xxxxxxxxxxxxx>
Cc: Tiger Ninomiya (Takuya) <
Takuya.Ninomiya@xxxxxxxxx>; Chris Cole <chris.cole@xxxxxxxxxxx>
Subject: FW: MPO-24 pin-out definition
 
Gary and Brian,
 
I’m hearing that the MPO-12, 2-row, lane assignment definition made in the QSFP-DD MSA in terms of polarity is seen as problematic by Paul Kolesar in relation to structured cabling. He also notes that there are problems with the OSFP choice as well, so both MSAs need to change or should change.
I have included Paul in this message. I will let him explain further. He is interested to help sort out the situation and make a definition that is friendly to structured cabling prescriptions that could be used for QSFP-DD, OSFP, and COBO. I have also included Tiger Ninomiya (Takuya) who is interested to help and describe the situation to the COBO membership. I have also included Chris Cole who first identified the conflicting definitions.
 
Nothing in this email is confidential IP since the artwork is all from published specifications.

o   QSFP-DD Rev. 2.0 specification published (see http://www.qsfp-dd.com/wp-content/uploads/2017/03/QSFP-DDrev2-0-Final.pdf)

o   OSFP Rev. 1.0 specification published (see http://osfpmsa.org/assets/pdf/OSFP_Module_Specification_Rev1.0.pdf)

 
If we can arrive at a good proposal, then we can bring a common proposal back to the respective MSAs/consortium.
 
Jeff
 
 
From: Chris Cole [mailto:chris.cole@xxxxxxxxxxx] 
Sent: Thursday, March 30, 2017 2:56 PM
Cc: Jeffery Maki <
jmaki@xxxxxxxxxxx>
Subject: MPO-24 pin-out definition
 
<stuff deleted>
 
Whatever the merits of various approaches, the industry will greatly benefit from a common MPO-24 pin-out definition across all the new form factors.
 
Chris
 
OSFP Fig. 53 assignments:
 
<image014.png>
 
 
QSFP-DD Figure 31 assignments:
 
<image015.png>
 
IEEE 802.3bs assignments:
 
<image016.png>
 
IEEE 802.3ba assignments:
<image017.png>
Figure 86–7—100GBASE-SR10 optical lane assignments
 
 


 
--
Brian Park
Mechanical Engineer
Arista Networks
5453 Great America Pkwy, Santa Clara, CA 95054
408-547-5703 (office)
408-582-8641 (cell)
 
 


 
--
Brian Park
Mechanical Engineer
Arista Networks
5453 Great America Pkwy, Santa Clara, CA 95054
408-547-5703 (office)
408-582-8641 (cell)
 
 

 
 

To unsubscribe from the STDS-802-3-NGMMF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGMMF&A=1


To unsubscribe from the STDS-802-3-NGMMF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGMMF&A=1