[RPRWG] [Fwd: BOUNCE stds-802-17@xxxxxxxxxxxxxxxxxx: Non-member submission from ["Grow, Bob" <bob.grow@xxxxxxxxx>]]
Forwarded from Bob since he is not on the reflector.
mike
Thread-Index: AcLDWpSZL7vzQy9NEde/HABQi2jWFgAkGVNw
From: "Grow, Bob" <bob.grow@xxxxxxxxx>
To: "Raj Sharma" <raj@xxxxxxxxxxxx>, "Robert D. Love" <rdlove@xxxxxxxx>,
"802.17" <stds-802-17@xxxxxxxx>
Cc: "Thompson, Geoff O" <thompson@xxxxxxxx>, "Grow, Bob"
<bob.grow@xxxxxxxxx>
X-OriginalArrivalTime: 24 Jan 2003 21:16:16.0395 (UTC)
FILETIME=[D4C215B0:01C2C3ED]
Raj:
=20
My message was that this is the type of question 802.17 has to answer =
itself. Every question that both Geoff and I have been copied on is =
very general. It isn't our job to design 802.17 (I have more than =
enough 802.3 work on my plate already and for some reason, my boss wants
=
me to do some work related to his projects/products also).
=20
You'll get no more answers from me on general questions. For example, =
1000BASE-T is that it is a GbE PHY and we were asked about 1 and 10 GbE
=
PHYs in general. 802.17 people have to decide the relevance.
=20
Your more specific question about auto-negotiation, it is a mandatory =
GbE function. One of its characteristics (and not necessarily the only =
relevant characteristic) is it assumes that its transmit path and =
receive path connect to the same remote PHY. It is 802.17 that knows =
if such a restriction is embodied in your specifications.
=20
Your last question is an example of one unlikely to get answered by =
802.3 folk ("What in RPR. . ."). To put Bob Love's point into different
=
words, my job is Ethernet (so I also have to understand FDDI TP-PMD and
=
FDDI PMD which are encorporated by reference in 802.3). Your job =
presumably is RPR, therefore, it is your job to know RPR operation and =
anything it incorporates by reference (e.g., the referenced set of GbE =
and 10GbE PHYs).
=20
Bob Grow=20
-----Original Message-----
From: Raj Sharma [mailto:raj@xxxxxxxxxxxx]
Sent: Thursday, January 23, 2003 7:42 PM
To: Robert D. Love; 802.17
Cc: Thompson, Geoff O; Grow, Bob
Subject: RE: [RPRWG] Careful Use of the 802.3 PHY
Bob,
=20
You have bought forth some intriguing remarks and rationale
responses to a very specific question dealing with less than 64 byte =
frames
on 802.3 PHYs. Thanks for the delving into this. BTW, I do believe =
careful (safe)
PHY use is always a wise thing:)
=20
Geoff/Bob, (or anyone who know more in this area) could you elaborate=20
on what exactly are Ethernet PHY's limitations specifically related to =
frame size?
Apparently, reading the 802.3 specifications it does not jump across
that any limitation is implied.
Are there upper limits on ordered_set code densities?
Even non-standard Jumbo frames use standard Ethernet PHYs and that seems
=
to work
(at least at the PHY level) implying no lower limit on ordered_set code
=
densities.
=20
I also don't understand the following and its relationship to 802.17:
1. The relevance of 1000BaseT (i.e. use of 4 pairs of twisted wires =
between adjacent stations) in RPR
2. Why a standard PHY that has auto-negotiation cannot be used.
3. Finally there is mention that 802.3 PHYs have not been characterized
=
when the transmit
and the receive path delays are different.
What in RPR gives rise to the delay difference on spans connecting two =
adjacent RPR stations
that has implications that off beyond Ethernet?
=20
raj
=20
=20
-----Original Message-----
From: Robert D. Love [mailto:rdlove@xxxxxxxxx]
Sent: Thursday, January 23, 2003 2:43 PM
To: 802.17
Cc: Thompson, Geoff O; Grow, Bob
Subject: [RPRWG] Careful Use of the 802.3 PHY
In order to look at possible stumbling blocks ahead of us at Sponsor =
Ballot time, I sent a note to Geoff Thompson and to Bob Grow with the =
following query:
=20
Do either of you see any problem with 802.17 using a "standard 802.3 =
PHY" and supporting frame sizes less than 64 Bytes", especially if the =
data rates of interest are 1 and 10 Gbits/s? Would you expect anyone in
=
802.3 to be upset with 802.17 requiring the PHY to support the small =
frame sizes? (I realize that you can't know for sure how everyone will
=
respond to this question. I am just looking for your gut reaction here.
=
Thanks.) =20
As I look ahead at the Sponsor level ballot, I want to steer around =
stumbling blocks and want to get an early peek at whether there is any =
reasonable standards conformance based reason to want to avoid requiring
=
802.17 PHYs from supporting these small frame sizes. I expect that we =
will have a fair number of 802.3 voters in our sponsor ballot pool.=20
=20
As it turns out, both Bob and Geoff have strong concerns with what we =
are doing. =20
=20
Geoff's has kindly given me permission to post his reply which was:
"A "standard" 802.3 PHY can not be used unaltered if it has =
Auto-Negotiation.=20
(i.e. you can't just buy Ethernet chips and use them in
=
802.17 applications)=20
We haven't even looked at the ramifications of having radically
=
different path lengths between transmit and receive=20
You lose a great deal of your resiliency if you use 1000BASE-T
=
links in an RPR ring.
Basically, I have grave reservations about using Ethernet chips in an =
application where you are throwing out a significant number of the basic
=
design assumptions that were in hand when the PHYs were designed. These
=
assumptions are not necessarily documented in any other fashion than =
that it was an Ethernet chip being designed. That, in and of itself, =
sets a large number of conditions. I don't think you get to use an =
Ethernet chip without examining each and every departure from Ethernet =
assumptions on an engineering basis at the detail level.
Do I know off the top of my head what ALL of the considerations are? No
=
way! I haven't ever had the occasion to look at the appropriate level of
=
depth that is required to develop product. I'm probably not even the =
right guy to do it as I am not a PHY designer at this point in my life.
=
Can I think of a few off the top of my head? Yup, see above."
=20
Bob Grow's reservations were even stronger. There are two conclusions =
we should draw from Geoff's remarks.
(1) We should be studying very carefully, not only the requirements that
=
we get from reading the specifications for the PHYs that we pick up, but
=
the assumptions that went into the development of those PHYs
(2) We need to do comprehensive analysis to justify any change to the =
assumptions used in developing those PHYs.
=20
The second conclusion implies that we need to do a great deal of work =
before assuming that the PHYs can be used for small frame size (less =
than 64 Bytes). We may also want to ask the question as to whether the
=
use of short frames is worth the risk of breaking Ethernet PHYs, =
especially is we are unable to do a comprehensive review of the Ethernet
=
PHY requirements. We should also look at the implications of large =
frame size, even though large frame sizes are used in proprietary =
products today. =20
=20
Note that problems uncovered during Sponsor Ballot can completely derail
=
the standard and the schedule. We don't want to be making any =
significant changes to the draft at sponsor ballot time. Certainly =
changing the length of control frames would be highly significant. We =
have work to do. Let's decide how to best address it early enough to =
stay within our present schedule.
=20
=20
Best regards,
=20
Robert D. Love
President, Resilient Packet Ring Alliance
President, LAN Connect Consultants
7105 Leveret Circle Raleigh, NC 27615
Phone: 919 848-6773 Mobile: 919 810-7816
email: rdlove@xxxxxxxx Fax: 208 978-1187
------_=_NextPart_001_01C2C3ED.D4884F55
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.00.3504.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D257505520-24012003>Raj:</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D257505520-24012003></SPAN></FONT> </DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D257505520-24012003>My=20
message was that this is the type of question 802.17 has to answer =
itself. =20
Every question that both Geoff and I have been copied on is very =
general. =20
It isn't our job to design 802.17 (I have more than enough 802.3 work on
=
my=20
plate already and for some reason, my boss wants me to do some work =
related to=20
his projects/products also).</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D257505520-24012003></SPAN></FONT> </DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D257505520-24012003>You'll=20
get no more answers from me on general questions. For example, =
1000BASE-T=20
is that it is a GbE PHY and we were asked about 1 and 10 GbE PHYs in=20
general. 802.17 people have to decide the =
relevance.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D257505520-24012003></SPAN></FONT> </DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D257505520-24012003>Your=20
more specific question about auto-negotiation, it is a mandatory GbE =
function.=20
One of its characteristics (and not necessarily the only relevant=20
characteristic) is it assumes that its transmit path and receive path =
connect to=20
the same remote PHY. It is 802.17 that knows if such a =
restriction=20
is embodied in your specifications.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D257505520-24012003></SPAN></FONT> </DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D257505520-24012003>Your=20
last question is an example of one unlikely to get answered by 802.3 =
folk ("What=20
in RPR. . ."). To put Bob Love's point into different words, my =
job is=20
Ethernet (so I also have to understand FDDI TP-PMD and FDDI PMD which =
are=20
encorporated by reference in 802.3). Your job presumably is =
RPR,=20
therefore, it is your job to know RPR operation and anything it =
incorporates by=20
reference (e.g., the referenced set of GbE and 10GbE =
PHYs).</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D257505520-24012003></SPAN></FONT> </DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D257505520-24012003>
<P><FONT face=3DArial size=3D2>Bob Grow</FONT> <BR></SPAN></FONT><FONT =
color=3D#0000ff=20
face=3DArial size=3D2><SPAN =
class=3D257505520-24012003></SPAN></FONT></P></DIV>
<DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> Raj Sharma=20
[mailto:raj@xxxxxxxxxxxx]<BR><B>Sent:</B> Thursday, January 23, 2003 =
7:42=20
PM<BR><B>To:</B> Robert D. Love; 802.17<BR><B>Cc:</B> Thompson, Geoff O;
=
Grow,=20
Bob<BR><B>Subject:</B> RE: [RPRWG] Careful Use of the 802.3=20
PHY<BR><BR></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D978251003-24012003>Bob,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D978251003-24012003></SPAN></FONT> </DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D978251003-24012003>You=20
have bought forth some intriguing remarks and =
rationale</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D978251003-24012003>responses to a very specific question dealing
=
with less=20
than 64 byte frames</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D978251003-24012003>on=20
802.3 PHYs. Thanks for the delving into this. BTW, I do believe
careful=20
(safe)</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D978251003-24012003>PHY=20
use is always a wise thing:)</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D978251003-24012003></SPAN></FONT> </DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D978251003-24012003>Geoff/Bob, (or anyone who know more in this =
area) could=20
you elaborate </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D978251003-24012003>on=20
what exactly </SPAN></FONT><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D978251003-24012003>are Ethernet PHY's limitations specifically =
related to=20
frame size?</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D978251003-24012003>Apparently, reading the 802.3 specifications
=
it does=20
not jump across</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D978251003-24012003>that=20
any limitation is implied.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D978251003-24012003>Are=20
there upper limits on ordered_set code =
densities?</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D978251003-24012003>Even=20
non-standard Jumbo frames use standard Ethernet PHYs and that seems
to=20
work</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D978251003-24012003>(at=20
least at the PHY level) implying no lower limit on ordered_set code=20
densities.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D978251003-24012003></SPAN></FONT> </DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D978251003-24012003>I also=20
don't understand the following and its relationship to=20
802.17:</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D978251003-24012003>1. The=20
relevance of 1000BaseT (i.e. use of 4 pairs of twisted wires between =
adjacent=20
stations) in RPR</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D978251003-24012003>2. Why=20
a standard PHY that has auto-negotiation cannot be =
used.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D978251003-24012003>3.=20
Finally there is mention that 802.3 PHYs have not been characterized =
when the=20
transmit</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D978251003-24012003>and=20
the receive path delays are different.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D978251003-24012003>What=20
in RPR gives rise to the delay difference on spans connecting two =
adjacent RPR=20
stations</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D978251003-24012003>that=20
has implications that off beyond Ethernet?</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D978251003-24012003></SPAN></FONT> </DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D978251003-24012003>raj</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D978251003-24012003></SPAN></FONT> </DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D978251003-24012003></SPAN></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT:
=
0px; PADDING-LEFT: 5px">
<DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> Robert D. Love=20
[mailto:rdlove@xxxxxxxxx]<BR><B>Sent:</B> Thursday, January 23, 2003 =
2:43=20
PM<BR><B>To:</B> 802.17<BR><B>Cc:</B> Thompson, Geoff O; Grow,=20
Bob<BR><B>Subject:</B> [RPRWG] Careful Use of the 802.3=20
PHY<BR><BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>In order to look at possible =
stumbling blocks=20
ahead of us at Sponsor Ballot time, I sent a note to Geoff Thompson =
and to Bob=20
Grow with the following query:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>
<DD>Do either of you see any problem with 802.17 using a "standard =
802.3 PHY"=20
and supporting frame sizes less than 64 Bytes", especially if the data
=
rates=20
of interest are 1 and 10 Gbits/s? Would you expect anyone in =
802.3 to be=20
upset with 802.17 requiring the PHY to support the small frame =
sizes? (I=20
realize that you can't know for sure how everyone will respond to this
=
question. I am just looking for your gut reaction here. =20
Thanks.) =20
<DD>As I look ahead at the Sponsor level ballot, I want to steer =
around=20
stumbling blocks and want to get an early peek at whether there is any
=
reasonable standards conformance based reason to want to avoid =
requiring=20
802.17 PHYs from supporting these small frame sizes. I expect =
that we=20
will have a fair number of 802.3 voters in our sponsor ballot pool.=20
</DD></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial><FONT size=3D2>As it turns out, both Bob and =
Geoff have=20
strong concerns with what we are doing. </FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2></FONT></FONT> </DIV>
<DIV><FONT face=3DArial><FONT size=3D2>Geoff's has kindly given me =
permission to=20
post his reply which was:</FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2>"<FONT face=3D"Times New Roman"
=
size=3D3>A=20
"standard" 802.3 PHY can not be used unaltered if it has =
Auto-Negotiation.=20
</FONT>
=
<DD><X-TAB> </X-TAB><X-TAB=
> </X-TAB>(i.e.=20
you can't just buy Ethernet chips and use them in 802.17 applications)
=
<DD><X-TAB> </X-TAB>We
=
haven't=20
even looked at the ramifications of having radically different path =
lengths=20
between transmit and receive=20
<DD><X-TAB> </X-TAB>You
=
lose a=20
great deal of your resiliency if you use 1000BASE-T links in an
=
RPR=20
ring.<BR><BR>
<DD>Basically, I have grave reservations about using Ethernet chips in
=
an=20
application where you are throwing out a significant number of the =
basic=20
design assumptions that were in hand when the PHYs were designed. =
These=20
assumptions are not necessarily documented in any other fashion than =
that it=20
was an Ethernet chip being designed. That, in and of itself, sets a =
large=20
number of conditions. I don't think you get to use an Ethernet chip =
without=20
examining each and every departure from Ethernet assumptions on an =
engineering=20
basis at the detail level.<BR><BR>
<DD>Do I know off the top of my head what ALL of the considerations =
are? No=20
way! I haven't ever had the occasion to look at the appropriate level
=
of depth=20
that is required to develop product. I'm probably not even the right =
guy to do=20
it as I am not a PHY designer at this point in my life. Can I think of
=
a few=20
off the top of my head? Yup, see above."</DD></DIV>
<DIV> </DIV>
<DIV>Bob Grow's reservations were even stronger. There are
two=20
conclusions we should draw from Geoff's remarks.</DIV>
<DIV>(1) We should be studying very carefully, not only the =
requirements that=20
we get from reading the specifications for the PHYs that we pick up, =
but the=20
assumptions that went into the development of those PHYs</DIV>
<DIV>(2) We need to do comprehensive analysis to justify any change to
=
the=20
assumptions used in developing those PHYs.</DIV>
<DIV> </DIV>
<DIV>The second conclusion implies that we need to do a great deal of
=
work=20
before assuming that the PHYs can be used for small frame size (less =
than 64=20
Bytes). We may also want to ask the question as to whether
=
the use=20
of short frames is worth the risk of breaking Ethernet PHYs, =
especially is we=20
are unable to do a comprehensive review of the Ethernet PHY=20
requirements. We should also look at the implications of large =
frame=20
size, even though large frame sizes are used in proprietary
products=20
today. </DIV>
<DIV> </DIV>
<DIV>Note that problems uncovered during Sponsor Ballot can completely
=
derail=20
the standard and the schedule. We don't want to be making any=20
significant changes to the draft at sponsor ballot time. =
Certainly=20
changing the length of control frames would be highly =
significant. We=20
have work to do. Let's decide how to best address it early =
enough to=20
stay within our present schedule.</DIV>
<DIV> </DIV>
<DIV> </DIV></FONT></FONT>
<DIV><FONT face=3DArial size=3D2>Best regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Robert D. Love<BR>President, =
Resilient Packet=20
Ring Alliance<BR>President, LAN Connect Consultants<BR>7105 Leveret=20
Circle Raleigh, NC 27615<BR>Phone: 919=20
848-6773 Mobile: 919 =
810-7816<BR>email: <A=20
=
href=3D"mailto:rdlove@xxxxxxxx";>rdlove@xxxxxxxx</A> &nbs=
p; =20
Fax: 208 978-1187</FONT></DIV></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C2C3ED.D4884F55--