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

[RPRWG] [Fwd: BOUNCE stds-802-17@xxxxxxxxxxxxxxxxxx: Non-member submission from [Geoff Thompson <gthompso@xxxxxxxxxxxxxxxxxx>]]





Forwarded for Geoff who is not on the reflector.

mike

Date: Fri, 24 Jan 2003 17:43:48 -0800
To: "Raj Sharma" <raj@xxxxxxxxxxxx>
From: Geoff Thompson <gthompso@xxxxxxxxxxxxxxxxxx>
Subject: RE: [RPRWG] Careful Use of the 802.3 PHY
Cc: "Robert D. Love" <rdlove@xxxxxxxx>, "802.17" <stds-802-17@xxxxxxxx>,
   <thompson@xxxxxxxx>, "Grow, Bob" <bob.grow@xxxxxxxxx>
In-Reply-To: <3BF285C347DD274FB835A67133811D4F23CCB1@xxxxxxxxxxxxxxxxxxx
 com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_32029926==_.ALT"

--=====================_32029926==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed


>
>-----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
Raj-

NON-COMPREHENSIVE answer to your questions


>Bob,
>
>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:)
>
>Geoff/Bob, (or anyone who know more in this area) could you elaborate
>on what exactly are Ethernet PHY's limitations specifically related to 
>frame size?

No.
The limitations are what is specified.
There need be no reason other than that.
Implementors are entitle to depend on what is in the spec when they do 
their designs

>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.

"Seems to work" and specified to work by a standards committee consensus 
process "should" be tow different things. 802.3 certainly tries to build 
specs on more solid ground than just "seems to work". I would certainly 
hope 802.17 does too.
The judgement of the standards committee has nothing to say about "how 
well" jumbo frames "work". Investigation of that was beyond the scope of 
the Working Group.
You would have to ask PHY suppliers about that individually.

>
>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

You can't separate transmit and receive

>2. Why a standard PHY that has auto-negotiation cannot be used.

Because the Auto-Negotiation identifies the chip as speaking Ethernet.
If 
you lie then you break things!

>3. Finally there is mention that 802.3 PHYs have not been characterized 
>when the transmit
>and the receive path delays are different.

That is true, cause we don't support that.

>What in RPR gives rise to the delay difference on spans connecting two 
>adjacent RPR stations
>that has implications that off beyond Ethernet?

Going different directions around the ring and through a different
number 
of repeating stations.

>
>raj

--=====================_32029926==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<blockquote type=cite cite><br>
<font face="tahoma" size=2>-----Original Message-----<br>
<b>From:</b> Raj Sharma
[<a href="mailto:raj@xxxxxxxxxxxx";
eudora="autourl">mailto:raj@xxxxxxxxxxxx</a>]<br>
<b>Sent:</b> Thursday, January 23, 2003 7:42 PM<br>
<b>To:</b> Robert D. Love; 802.17<br>
<b>Cc:</b> Thompson, Geoff O; Grow, Bob<br>
<b>Subject:</b> RE: [RPRWG] Careful Use of the 802.3 PHY<br>
</font></blockquote>Raj-<br>
<br>
NON-COMPREHENSIVE answer to your questions<br>
<br>
<br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite
cite>Bob,</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">You have bought forth some
intriguing remarks and rationale</font><br>
responses to a very specific question dealing with less than 64 byte
frames<br>
on 802.3 PHYs. Thanks for the delving into this. BTW, I do believe
careful (safe)<br>
PHY use is always a wise thing:)<br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Geoff/Bob, (or anyone who know
more in this area) could you elaborate </font><br>
on what exactly are Ethernet PHY's limitations specifically related to
frame size?</blockquote><br>
No.<br>
The limitations are what is specified. <br>
There need be no reason other than that. <br>
Implementors are entitle to depend on what is in the spec when they do
their designs<br>
<br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite
cite>Apparently,
reading the 802.3 specifications it does not jump across</font><br>
that any limitation is implied.<br>
Are there upper limits on ordered_set code densities?<br>
Even non-standard Jumbo frames use standard Ethernet PHYs and that seems
to work<br>
(at least at the PHY level) implying no lower limit on ordered_set code
densities.</blockquote><br>
&quot;Seems to work&quot; and specified to work by a standards committee
consensus process &quot;should&quot; be tow different things. 802.3
certainly tries to build specs on more solid ground than just
&quot;seems
to work&quot;. I would certainly hope 802.17 does too.<br>
The judgement of the standards committee has nothing to say about
&quot;how well&quot; jumbo frames &quot;work&quot;. Investigation of
that
was beyond the scope of the Working Group.<br>
You would have to ask PHY suppliers about that individually.<br>
<br>
<blockquote type=cite cite>&nbsp;<br>
<font face="arial" size=2 color="#0000FF">I also don't understand the
following and its relationship to 802.17:</font><br>
1. The relevance of 1000BaseT (i.e. use of 4 pairs of twisted wires
between adjacent stations) in RPR</blockquote><br>
You can't separate transmit and receive<br>
<br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>2.
Why a standard PHY that has auto-negotiation cannot be
used.</font></blockquote><br>
Because the Auto-Negotiation identifies the chip as speaking Ethernet.
If
you lie then you break things!<br>
<br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>3.
Finally there is mention that 802.3 PHYs have not been characterized
when
the transmit</font><br>
and the receive path delays are different.</blockquote><br>
That is true, cause we don't support that.<br>
<br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite
cite>What
in RPR gives rise to the delay difference on spans connecting two
adjacent RPR stations</font><br>
that has implications that off beyond Ethernet?</blockquote><br>
Going different directions around the ring and through a different
number
of repeating stations.<br>
<br>
<blockquote type=cite cite>&nbsp;<br>
<font face="arial" size=2 color="#0000FF">raj</font></blockquote></html>

--=====================_32029926==_.ALT--