| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Chris, That is your interpretation. John From: Chris Cole <chris.cole@xxxxxxxxxxx> John, You are giving us a great example of the main problem with doing research in 802.3. What governs are the protocol rules, not the data or the established way of doing basic research. Chris From: jdambrosia@xxxxxxxxx <jdambrosia@xxxxxxxxx> Chris, While I respect your opinion on optics, I do want to be clear about something – there is nothing in the rules that requires the 10 citations that you are requesting. While this may be your bar to technical feasibility – I just want to be clear there is no such rules requirement in any of the rules. With that said, any future PAR would need to answer the CSD and the five critters. However, we are not a the position of the study group yet. Regards, John From: Chris Cole <chris.cole@xxxxxxxxxxx> Hi Rob, I did not propose to do logic and AUIs in an MSA. I was clear that these are to be done in 802.3. We worked together on multiple prior rates in 802.3 projects and the results were great. Let’s not change a winning formula. To avoid confusion, below is the entire proposal in chronological order of starts.
This proposal is exactly what we did at 100G, where the sequence was 40G lambda work, OIF CU I/O, .3ba, 3bj, .3bm, and 100G CWDM4 MSA (picking up where .3bm left off). If we keep the modulation order in the single digits, we may avoid having to follow the 200Gb/s per lambda Project with an MSA. It would be helpful to get more data behind your statement that “clearly time is short if we are to come close to this schedule, and I think we need to align with market prioritization [for 200Gb/s lane optical PMD standard in the IEEE].” Today, 25G lambdas are shipping in the millions, 50G lambdas are ramping at moderate volume, and 100G lambdas are shipping in lower volume. The 50G lambdas are primarily in 200GbE interfaces. 400GbE is shipping in very low volume, with a mix of 50G and some 100G lambdas, and won’t ramp to volume until after 200GbE ramps into the millions. Given that 50G and 100G lambda ramps and volume are still ahead of us, where is the urgent need for 200G lambdas? Can you share with us the split in shipments to Facebook between 25G, 50G, and 100G lambda optics? This way you won’t have to disclose actual numbers, which we all understand are highly sensitive. Cedric has done a great job of explaining why Google needs 200G lambdas for 800GbE. They interoperate 4 lambda optics at different rates. That is more compelling than observing general bandwidth growth. Industry must respond to this need and start working on 200G lambdas. The question is what is the most effective way to do it; 1) driven by 802.3, or 2) driven outside of 802.3. My argument is that we do well in 802.3 when there is an existing substantial body of knowledge when we start a Project. You maybe aware of research on 200Gb/s lambda optics for intra-datacenter applications. Can you cite 10 conference or refereed journal publications on the subject? Thank you Chris From: Rob Stone <00001210a8052f96-dmarc-request@xxxxxxxxxxxxxxxxx> Hi Chris Clearly there is a pressing need for a higher Ethernet port rate – and there have been presentations by at least a couple of hyperscalers (Google, Facebook) which indicate a requirement for 800GbE, as the next required optical PMD. On top of that, the NEA work John has been leading presents the underlying traffic growth data supporting the need for a higher rate. However, in terms of PMD prioritization, I don’t agree with your assertion that the next project should be a stand-alone 200G copper one (assuming you are referring to backplanes and DAC cables, not AUIs). In my view, that backplane and DAC project will of course be needed in due course, but it comes second in terms of industry need and BMP to the optical PMDs and associated AUIs. Based on projected growth rates, we need a power and cost effective 800G optical interface which runs over duplex SMF, and Cedric indicated in his NEA presentation a 2024 timeframe (or sooner if possible). Clearly time is short if we are to come close to this schedule, and I think we need to align with market prioritization. I hear you on the case to do this work in an MSA rather than the IEEE, but in terms of the complete solution including logic, and AUIs I think an MSA would struggle to deliver. I am looking forward to when the study group is chartered and we can have these and other discussions in a more structured way. Thanks Rob ______________________ From: Chris Cole <chris.cole@xxxxxxxxxxx> Sadly, the alure of the working on the bleeding edge is irresistible.
1) clean, with broad consensus on solutions, and predictable, or 2) messy, with no industry consensus, and inevitably contentious. The first choice is 800 (and optionally 1600) Gb/s logic layer, with PMDs based on 100Gb/s per lane. The second choice adds 200Gb/s per lane signaling. IEEE 802.3 is the wrong place to direct and report research. There is a pre-defined timeline, most industry technical experts do not participate and are unaware of what’s going on, and the format is not appropriate for reporting new discoveries. We know how research results are properly reported; in refereed papers and conferences. These force a level of detail and completeness which is impossible to have in PPT for 20 min presentation slots, where in depth technical discussion is limited, and questions get cut off to stay on schedule. We don’t need to reinvent the wheel here as the infrastructure already exists. 802.3 does not need to compete with OFC, ECOC, CIOE, JLT, OFT, JOFCR, OCRT/FO, and many others. Many are IEEE publications and all have strong IEEE involvement and member participation. There are also less formal ways to test the waters on standards like MSAs. The consequences of them getting it wrong are much lower. 802.3 needs to have the discipline to let academia, govt. and industry do the underlying work first, and then standardize results that have reached a level of consensus. Otherwise procedural and schedule considerations take precedence over data. My suggestion is that those interested in 800/1600G logic layer oppose 200Gb/s per lane signaling so that what’s needed for ASIC design gets done in a reasonable, predictable time frame. Those in 802.3ck should oppose 200Gb/s optical per lane signaling because the lead should be a stand-along 200Gb/s copper project. Chris From: John D'Ambrosia <jdambrosia@xxxxxxxxx> Gary, In the example I cited in the email – I pointed to DR, so let’s stay with that as an example. You are proposing that one 800 GbE PHY might be 800GBASE-DR8, and they might want to break out to lower ethernet speeds. Ok. First – as discussed – we are trying to move away from the breakout discussion. So let’s assume the 800GBASE-DR8, based on 100 Gb/s per lane (fiber), which I assume would be compatible with what we already have for 100GBASE-DR and 400GBASE-DR4. So developing 200GBASE-DR2 might be something the SG wants to discuss. However, we have had those conversations, so not sure how much people want to revisit the two lane approach. .3ck is already developing all of the 100 Gb/s electrical stuff for 100/200/400 – so wouldn’t 800 Gb/s leverage those electricals if it pursued 100 Gb/s signaling? And then we have .3db doing its things with MMF for 100/200/400. So what new 100 Gb/s signaling solutions can you see us developing that would then go down to 100/200/400. I just am not seeing any. However, the new SG might consider 200Gb/s signaling which would then be applicable to 200 and 400 PHYs. John From: Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx> John, I am not sure I fully understand the key point you are trying to make below ? However I do agree with moving away from the concept of breakout in this discussion and also that we can’t use an application that may require multiple implementations of 200GbE in one physical optical module and/or switch port (for example), as justification for an 800GbE project. Each rate should stand on it’s own (i.e. meet the 5 critters), though obviously having some degree of technology reuse will help in addressing the “economic feasibility” requirement for each individual rate. I am not sure I agree with your point “First, I don’t think this is really applicable to 100 Gb/s signaling…..” . If we do ultimately kick off an 800GbE project, then I can envisage that someone may want an 800GBASE-DR8 solution that would reuse the same 100Gb/s optical signaling technology as 100GBASE-DR, 200GBASE-DR2 and 400GABSE-DR4. Perhaps the following is now a moot point (depending on whether I have understood your email below or not), but I did have some issues with the use of ‘breakout’ in the CFI presentation from the other day. https://www.ieee802.org/3/ad_hoc/ngrates/public/calls/20_0824/dambrosia_nea_01b_200824.pdf The first comment is on slide 2. I have no idea what the term “Breakout Ethernet Rates” means ? In my opinion there are just “Ethernet rates”. <image001.jpg> The second comment is on slide 7 (though perhaps based on your comments below you are planning on removing this slide from the deck ?) . The comments in the slide that “32 400GbE ports break out into 128 100GbE ports” is technically incorrect. You cannot ‘breakout” a 400GbE PHY. A 400GbE PHY is a 400GbE PHY , and nothing else. I think what is meant here is that I can have a 32 port switch, where each port supports a maximum capacity of 400Gb/s (not 400GbE!) and each port can be configured to support either a 1x400GbE mode or a 2x200GbE mode or a 4x100GbE mode (and maybe other mixed modes such as 1x200GbE + 2x100GbE, etc). The same comment for the bottom half of the slide where it is impossible to breakout 800GbE to 4x200GbE, etc. <image002.jpg> If you want to keep this chart then I would modify it something along the lines of: <image003.jpg> From: John D'Ambrosia <jdambrosia@xxxxxxxxx> Matt et al, We need to move away from the concept of breakout in having this discussion. Why do I say that? Because the term itself is causing confusion. Last week’s reflector discussion highlighted that people have different concepts of what is meant by breakout – and then it is further complicated by port capacity and port speeds. First – I am going to restate again – this discussion is not about what goes into the project, but what would be in scope for the study group to explore. This is a key concept that I can’t reiterate enough. Furthermore, some individuals have expressed that developing a lower speed should not be the justification for the higher speed. I will remind people of the process and that anything going into the future project needs to be justified in the CSD – and we can’t just take bits and pieces from various part of the project to justify the entire project. So with that said – what am I trying to capture for the study group to consider? First, I don’t think this is really applicable to 100 Gb/s signaling as 802.3 is pretty much specifying all of the various 100 Gb/s signaling – the electrical interfaces, backplane phys, cu cable phys, and optics, and that has been filled in for 100 / 200 / 4000 GbE. If we look ahead and we envision that 200 Gb/s signaling might become part of the project – my first guess would be as part of an AUI or DR optics, to enable achieving getting to 800GbE or 1.6 TbE. Possibly as well as part of some -FR or LR variant. Backplane / Cu cable are possible, but based on history they are not usually part of the initial speed effort. Let’s make the assumption that 800GbE is selected and maybe we decide to pursue a 4 lane variant (based on 200G signaling assumption) of the AUI or DR optics. If that were the case then it is reasonable to assume that some might want a 200 GbE 1x200G or a 400 GbE based on 2x200G AUI using a derivative of the I/O specifications developed for a 4x200G 800 GbE AUI or they might want a 200 GbE physical layer specification for over a single SM fiber in each direction using a derivative of the PMD specification of the 800GBASE-DR4 physical layer specification or perhaps a 400 GbE physical layer specification for over two SM fibers in each direction using a derivative of the PMD specification of the 800GBASE-DR4 physical layer specification. I don’t believe the F or L variants are appropriate as the presence of the mux / demuxes would mean different Tx / Rxs. I think this is a fair discussion for this SG to consider and should be in its scope and the SG then would make the decision whether this makes sense or not to include as part of the project PAR, and if so those things would then need to addressed in the CSD additionally on their own merits, not as the basis for the higher speed. My $0.02 on what I plan to include in the CFI text. As you can see the terminology can become quite confusing, and I appreciate the thoughtful discussion we are having to help properly shape it. Regards, John From: Matt Brown <matt.brown@xxxxxxxxxx> John et al, I don’t think breakout should be or needs to be part of the IEEE 802.3 specifications. In fact, I think it would be a mistake as it can take a multitude of forms and we would be involved in an endless maintenance of these variants. However, breakout is a valid and perhaps a necessary consideration in supporting and validating this CFI. At the completion of 802.3ck with the introduction of 100 Gb/s (e.g., 400GAUI-4, 200GAUI-2, 100GAUI-1) we will be able to support 400 Gb/s on a QSFP form factor or 800 Gb/s on QSFP-DD or OSFP form factor. The latter can support a breakout of 2x 400GE, 4x 200GE, or 8x 100GE; perhaps using a different module for each or perhaps on a single module that can support any. One key point that is being repeated is that we’d like to see higher net throughput on a faceplate port and thus on any of the form factors. In order, to double the rate on each of the form factors the C2M electrical lane rate must double from 100 Gb/s to 200 Gb/s (e.g., 400GAUI-2, 200GAUI-1). This would enable QSFP FF to support 800 Gb/s and QSFP-DD/OSFP FF to support 1600 Gb/s. The latter can support a breakout of 4x400GE, 8x 200GE. If breakout of 1600 Tb/s to multiple existing PMDs is desired, then breakout is also justifying a new project to define 200 Gb/s per lane electrical, at least for the C2M case. Of course, the higher C2M electrical lane rates will be essential for 800GE and 1600GE PMDs (e.g., 800GAUI-4, 1600GAUI-8). BUT defining a higher Ethernet rate is not necessarily a prerequisite for defining a new AUI lane rate. So breakout is a valid consideration in starting this new project and might need to be considered in scoping out objectives in the ensuing study group. Matt Brown Huawei Technologies Canada Co Ltd. 303 Terry Fox Drive, Suite 400 Ottawa, Ontario, Canada K2K 3J1 Office: 613-595-1900 x 1766 From: John D'Ambrosia [mailto:jdambrosia@xxxxxxxxx] Mark Good – glad to hear this. I do want to comment on the thread that “breakout” justifies everything. When the CSD is filled out – every objective selected needs to be addressed via the responses. We don’t get to pick and choose. So whatever higher speed would be selected would need to be justified via the CSD responses and supporting material. For example, 400GbE was justified on 400GbE, not breakout of 100 GbE. But support for breakout is a market issue, as we are seeing now. But once again – this discussion is not really about breakout. It is about the chartering motion of the study group and what is within scope to be considered. Regards, john From: Mark Nowell (mnowell) <00000b59be7040a9-dmarc-request@xxxxxxxxxxxxxxxxx> I actually think we’re all saying the same thing. Breakout has become a increasingly popular deployment model in certain networks. It doesn’t necessarily affect the specific Task Force work in defining an interoperable specification for a PHY. It could however be a consideration in the Study Group phase to help the group figure out its objectives. If there is agreement on an objective for some higher speed PHY that could be broken out, then the potential lower speed PHYs that make up the subsets of the higher speed PHY could also be added as an objective. And the breakout deployment model can be used to help justify either or both PHY objectives. But a word of caution, “breakout” isn’t some magic bean that justifies everything, we would still need to have the usual technical and economic feasibility and broad market potential analysis on each PHY. Breakout deployment use cases could augment those justifications. This does create more complex projects though. A single rate project can be complex enough, but what I’m suggesting here means the scope of a new project touches across more clauses in our standard. While many people might not worry about that, editorial teams know this isn’t a trivial shift and it puts a lot of pressure on schedule and timely progress. I don’t think that should affect a SG selecting objectives, but it should be a consideration on people’s expectations for how quick things can get done. Mark From: Steve Trowbridge <steve.trowbridge@xxxxxxxxx> Hi John, No, Mark is right. This is a total distraction. Obviously something people love to talk about, but it doesn’t serve any purpose. If what you need is not 800GbE or 1.6TbE, but rather a dual or quad 400GbE module, great. Go build that. You don’t need any new 802.3 project or standard to allow you to do this. I think I can assert now that there will not be an 800GbE or 1.6TbE PHY type with broad market potential that uses the lane technology of today’s 200G and 400G PHYs. Sure, there might be one defined so people can debug their MAC/PCS (like the 400GBASE-SR16), but forget that from a broad market potential perspective. Will the lane technology (e.g., 200G lanes with a stronger FEC) that emerges from an 800GbE or 1.6TbE project be something you can leverage to do a later P802.3cd type project to define new 200G and 400G PHY types with fewer lanes? Possibly. Maybe even probably. So if and when that all happens, there emerges (whether you write it down or not), that people will build stuff that does breakout of these new 200G and 400G PHY types from the modules you built for 800GbE or 1.6TbE. That might be something that lets you claim broad market potential for your new 200G and 400G PHY types to justify the future P802.3cd type project but it is not something that establishes broad market potential for your 800GbE or 1.6TbE. So let’s not talk about it in the context of your new CFI or study group. I would not like to see this called out as something for the Study Group to talk about, because as this email thread proves, people have the capacity to spend infinite amounts of time talking about it, and it doesn’t help at all in establishing broad market potential for 800GbE or 1.6TbE. So yes, I think distraction is exactly the right word. Regards, Steve From: John D'Ambrosia <jdambrosia@xxxxxxxxx> Mark I am going to disagree with you. I don’t see this conversation as a distraction at all. The fact that we are having this conversation, which has been quite healthy and revealing, is a great reason for us to exercise it the form of a study group. Please note you state –
The discussion about what is breakout has been helpful As noted – one could note a single PHY consists of “n” lanes where “n” could be an existing lower ethernet speed. In this instance the physical lower speed specification would leverage quite heavily the existing “lane” specification of the higher speed port. The instance that you have noted – where an implementation has been broken up may or may not meet what I noted above. For example, the LR example noted earlier – where it is very clear the PMD specification would be quite different because of the obvious elimination of the mux / demux. So very good conversation. Now I note you state – Looking forward as we start considering new PHYs and possibly new lane rates, we may want to develop our set of objectives in a project so that the if a PHY is being proposed that could allow a breakout into another PHY then we might want to include all related PHYs into the same project. By separating 400GBASE-DR4 into .3bs and 100GBASE-DR into .3cd we caused ourselves some challenges. But by including 50GBASE-CR, 100GBASE-CR2 and 200GBASE-CR4 together into .3cd we avoided potential challenges. As I noted at beginning of thread – this conversation was started to help me define the chartering motion of the study group I am proposing. Based on what you have stated above, it appears you would support having the discussion in the study group, and letting the study group determine what objectives go in or not. This means I need to properly scope it, which means what is meant by “breakout” becomes very important. Regards, John From: Mark Nowell (mnowell) <00000b59be7040a9-dmarc-request@xxxxxxxxxxxxxxxxx> Late coming to the thread… I’ve thought through this many times over the many years that this discussion flares up in these forums. I have come to a fairly simple perspective in my mind:
I therefore think that from an IEEE standardization perspective that “breakout” is a bit of a distraction that causes these email threads but doesn’t really factor into the specifics of defining a single interoperable PHY specification. Looking forward as we start considering new PHYs and possibly new lane rates, we may want to develop our set of objectives in a project so that the if a PHY is being proposed that could allow a breakout into another PHY then we might want to include all related PHYs into the same project. By separating 400GBASE-DR4 into .3bs and 100GBASE-DR into .3cd we caused ourselves some challenges. But by including 50GBASE-CR, 100GBASE-CR2 and 200GBASE-CR4 together into .3cd we avoided potential challenges. Long winded way of saying that I don’t think there needs to be a formal definition of “breakout” in IEEE 802.3 as I don’t think it affects our work. We write these specs with the knowledge that we want to use these specs to build products in implementations that we know (or hope) the industry wants to use. If we did develop a formal definition of “breakout” I’m not sure where it would go and I can guarantee that once we write it down, we’ll come up with something that wants to violate it… Mark From: "Gary Nicholl (gnicholl)" <00000bb92642e11e-dmarc-request@xxxxxxxxxxxxxxxxx> Fixing my typo below 😊 From: Gary Nicholl (gnicholl) Let me add to my comment below to pick up on the point that I think Jeff may be making. If I implement a single 100GBASE-DR in a QSFP28 module, it is likely to be using a duplex LC connector as the MDI. If I implement four instances of 100GBASE-DR in a QSFP-DD module , it is likely to be using two lanes of an MPO-12 connector as the MDI. So the two cases are using different optical connectors. Now in the IEEE specification we don’t dictate a specific optical connector (as that is an implementation choice). However if you look at the 802.3cd spec below (section 140.10.3) , we do define the performance specifications that any optical connector has to meet. So irrespective of whether I am implementing a single 100GBASE-DR in a QSFP28 or four 100GBASE-DRs in a QSFP-DD , then in both cases whatever optical connector I decide to use has to meet the same performance specifications that are defined in 140.10.3. Gary … <image004.jpg> From: Gary Nicholl (gnicholl) I agree with Steve. To me “breakout” has always been an “implementation” decision, and is not something that should be part of an IEEE 802.3 PHY specification. I do agree that there has been a lot of confusion over the term in the industry. For example I have often heard people talk about “400GBASE-DR4 breakout”. There is technically no such thing. Now as an implementation choice a clever module designer might design a single 400G QSFP-DD module that can support either a single instance of a 400GBASE-DR4 PHY or four separate instances of a 100GBASE-DR PHY. Gary From: Trowbridge, Steve (Nokia - US) <steve.trowbridge@xxxxxxxxx> Hi John, I think you know my views on breakout, since I’ve expressed them when the discussion has come up at the start of previous projects. Breakout is something that the clever designer does opportunistically in the case where you have PHYs that operate over parallel physical lanes (e.g., different strands of fiber or traces), and you have different MAC rates that operate over the same lane rates & technologies that differ only in the number of lanes they use. So just as an example, you have your 400GBASE-DR4 which could be used as a quad 100GBASE-DR(1) if your chip supports that mode of operation. But that mode of operation is something that a designer chooses to put into their chip. It isn’t “free” other than possibly from a cabling perspective, since you need to build four clause 82 PCSs and clause 91 FEC sublayers into your chip as well as the clause 119 400G FEC/PCS. No standard tells you whether or how to do this. But from a project perspective, what you really need or want is a dual or quad 400G module and not an 800GbE or 1.6TbE PHY, then go build that dual or quad module. You don’t need any new 802.3 project to do this. Only do the new project if you need (have broad market potential for) the 800GbE or 1.6TbE PHY, and if such a thing has technical and economic feasibility. While you do that project, do you keep your eyes open for breakout opportunities? Sure, who wouldn’t? But to try to relate it to applications in the past: For 400GbE, there was ONE PHY type (400GBASE-SR16) which was based on previous generation lane technology, so sure, one might want to have built a chip that could also do a quad 100GBASE-SR4. But the lane rate isn’t even the same (since the 400GBASE-SR16 uses RS(544) FEC and 100GBASE-SR4 uses (RS528)), so not quite as simple as it sounds. Plus, 400GBASE-SR16 was just a super early adopter/lab type interface, never a widely deployed 400G interface. The way 400G was written for eventual high-volume applications was optimized for (choosing RS(544) FEC ubiquitously) 50G and 100G lanes, and not optimized for the previous generation lane technology. The 400GBASE-DR4/100GBASE-DR is probably a more widely used (or will be more widely used) breakout application, however, this was dependent on specifying a new 100G PHY type using the next gen lane technology in the P802.3cd project. So to muse about the future, one can assume that a future 800GbE or 1.6TbE standard isn’t going to be optimized for 100G lanes, as we historically don’t get to high volumes with 8 or 16 lane implementations. Surely, we’ll optimize around something like a 200G lane. Such a lane technology may well require more than RS(544) FEC. So if you posit that you want to use these future PHYs for breakout, this leads to some future project that will define 200G and 400G PHY types based on this new 200G per lane technology and new FEC, and you’ll break out to this new PHY type, not to any existing one. But that future project again is opportunistic, saying I can build a better 200G or 400G PHY because of the technology developed for 800GbE or 1.6TbE. So in summary, breakout should not be the consideration for why you do the next gen 800G or 1.6T rate project. Breakout may be the reason you do the next “802.3cd” type project, using the lane technology of your 800G or 1.6T PHYs to build better or smaller 200G or 400G PHYs. Regards, Steve From: John D'Ambrosia <jdambrosia@xxxxxxxxx> David – I don’t consider the second case breakout of an 800GbE PHY. Using prior standards as an example – one would expect 800GBASE-LRx to be a WDM solution, where “x” wavelengths are optically muxed / demuxed. What I believe you are proposing is an implementation where “x” # of the lower speed are packaged together. So the 800GbE PHY is not being broke out – the port implementation, which is not the focus of the standard, is. John From: David Ofelt <ofelt@xxxxxxxxxxx> I think there are two different concepts that end up being colloquially referred to as breakout. The first is that case you detaiil below- a set of parallel media lanes that can be grouped in various ways- either as a single unified PHY or as a number of slower PHYs. The other case is a module that happens to hold a number of PHYs that are completely independent- like a QSFP-DD/OSFP module that has 4 x 100GBASE-LR optics. I’m Ok with declaring that “breakout” just covers the first case and your list is a good start at scoping the definition, but if we do that, I’d like us to figure out a name for the other case. I find that when I talk to people about modules- it is important to clearly address both cases, since many folks have only one of the cases in mind and conversations can get confusing.
-- DaveO From: John D'Ambrosia <jdambrosia@xxxxxxxxx> [External Email. Be cautious of content] All, As I explore the scope for the Beyond 400 GbE effort, I have been having a number of conversations related to “breakout” While we all discuss it – I have never seen some actual formal definition that is agreed upon within 802.3. So I would like to get some input. I am going to start with breakout actually does and solicit input before proposing some definition to potentially use. I see break out of the following –
FR / LR / ER optics – I don’t see as being part of breakout. Thoughts? John To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 Rob Stone | Mobile: 408.202.6676 To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 |