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

Re: [802.3_NGBASET] NGBASE-TSR



Hi Wayne,

Will respond in context below in GREEN.


On 11/16/12 6:14 AM, Larsen, Wayne wrote:

Hi Dan,

I believe I did have this mis-understanding, and I believe this helps.
DD: Sorry if I wasn't clear.
Still wondering, perhaps the name could be different.  SR for short reach implies limited capability.  Perhaps it could be called HE for high efficiency, or LP for low power, thereby emphasizing its positives instead of its negatives.
DD: The thing we are specifying is the channel. I don't really see SR as a negative, but as a clear indicator of what it does. One suggestion I heard was to use MR for mid-reach applications. The problem with referencing HE or LP is that we don't specify either efficiency or power, and depending on implementation one could build a higher power device than someone else. But both should operate on the SR or MR defined channels.


Also, you explained before to me, that if a TSR PHY was matched with a non-TSR PHY at a longer distance, they would link up at 1G instead of at 10G.  Is this still your vision?  Or would the TSR PHY include the circuitry, not normally energized, to allow it to communicate over the full length at normal speed?
DD: The ability to signal (via Auto-Negotiation) a desire to drop speed, and the reason why to your link-partner is a value add proposition. For NGBASE-TSR, its a strong recommendation. To explain why this is important, imagine attaching two 10GBASE-T devices at 75m of CAT6. With today's AN, the link would come up, go down, come up, go down ad infinitum. The new approach would be much better for the IT manager as it would a) link up (lower speed) and b) communicate the reason for the lower speed link.

To your second question, if someone built a very low cost TSR top-of-rack switch with high density (say, 48 ports, 1U) you would not want it to link up on a longer cable. This would create a potential reliability issue because that switch was designed for TOR applications. The customer would know this because it would be a TSR switch, lower cost, and higher density.

The idea of having flexible reach ports is a *product decision* that one could take, but they would have to sacrifice some cost/density to make that practical, and then have to deal with communicating to their customer how it works. I could see someone might do it, but they wouldn't be doing 48 ports in a 1U box at low cost.

Like I said, I plan to provide a higher level, market focused presentation at the next meeting. But your questions and comments are valuable as they provide guidance on the where the presentation can focus.

Thanks,

Dan

Wayne
11/16/12




-----Original Message-----
From: Daniel Dove [mailto:ddove@xxxxxxx] 
Sent: Thursday, November 15, 2012 5:15 PM
To: STDS-802-3-NGBASET@xxxxxxxxxxxxxxxxx
Subject: [802.3_NGBASET] NGBASE-TSR

Dear Study Group Participants;

I have received some feedback that my promotion of NGBASE-TSR has been 
received as a "multi-PHY" proposal.

This may be due to the structure of my presentations, the language used, 
or graphics used to represent the proposal. It may also be due to my 
lack of time in the group, due to my responsibilities in P802.3bm. If 
so, I apologize.

My proposal is for a single PHY (at each speed) that can operate in 
different modes. Much like 10GBASE-T has a "30m mode".

The key difference, is that for 10GBASE-T, we didn't sufficiently 
provide for the Auto-Negotiation functionality to make it work properly. 
In addition, I think having a naming mechanism for the different modes 
enables appropriate market separation for products that choose to use 
that PHY in particular modes.

I plan to bring in a presentation in January that comes in at a 
higher-level, explaining the market benefits rather than diving into the 
technical benefits as I have done so far.

In the mean time, I just wanted to make it very clear. Its a single PHY 
(per speed) that operates in different modes.

This is part-and-parcel to the argument I have been making that a PHY in 
short-reach mode PHY must inter-operate with a PHY in long-reach mode 
when operating on a cable that meets the short-reach parameters.

If you wish to discuss this further, provide feedback, and/or 
suggestions, please feel free to contact me. I would appreciate the input.

Best Regards,

Dan Dove
dan_dove@xxxxxxxx