Re: Interface reality check
Rich,
Rich Taborek wrote:
>
> > Page 1: I agree with everything here except perhaps the /O/.
> > I'd like to understand more about why this is needed.
>
> I've included the /O/, representing "other" in support of other standards such
> as Fibre Channel and InfiniBand with common parts, for other OAM&P functions for
> Ethernet WAN access and WAN applications, and for other unforeseen extensions to
> 10 GbE since I believe that we shouldn't assume that we have all link control
> functions covered. Both 8B/10B and 64B/66B proposals currently support
> additional control codes which may be required to provide /O/ support for the
> purposes described above.
I agree the code space is available and that it should be held
reserved. I think a healthy debate is yet to be waged on the virtues
or follies of explicitly supporting other standards (Fibre Channel
and Infiniband) within "ae".
>
> > Page 2: I agree with everything here except the following:
> > This applies for any serial PCS, 64b/66b or other. I think
> > this is the picture that I envisioned when I started this
> > thread and what I understand is the picture that Mr. Rick
> > Walker is in support of based on his most recent comments.
> > The WWDM encoding may be identical to XAUI or may be
> > something else completely. Either way, I'd like to
> > see this specified with the encodings supported/
> > required by RS only. Even XAUI is specified this way.
> > XAUI requires /A/K/R/ for a further encoding of the
> > IDLE stream but it takes /I/ as input (along with all
> > the others /S/T/d/E/RF/BL/). Our debate is where the
> > /A/K/R/ gets stripped off after XAUI.
>
> I'm not sure I understand exactly what you're disagreeing with on page 2 since
> its intention was to show your view: "Serial PHY, 64B/66B PCS, XGXS never
> forwards /A/K/R/." Page 2 clearly show /A/K/R/ being stripped off and translated
> back to /I/ by the XGXS adjacent to the PCS in Device A.
>
> Our debate has also focused on only the Serial PHY and only on 64B/66B coding.
> I'd like to keep our debate focused on these elements only. I believe that this
> coding debate is applicable to and independent of other PHY's and encodings, but
> I'd like to focus on the PHY/PMD we started with, especially since it is
> endorsed by a significant cross section of IEEE 802.3ae Task Force members.
>
> Can you please explain your disagreement with page 2 with respect only to the
> Serial PHY with a 64B/66B PCS.
With respect to a Serial PHY using 64b/66b, I am in full agreement
with page 2. I was merely pointing out that this can also apply to
other serial PCS proposals in addition to 64b/66b and that WWDM is
a bit off the beaten path. These discussions probably deserve their
own thread.
>
> > Page 3: I think that this is the picture you've been in
> > support of and the one that the current 64b/66b proposal
> > describes. I don't agree with this picture.
>
> If you'll allow me to twist your words: I believe that you agree that the
> picture accurately represents my previous view of XAUI/XGXS and PCS operation
> for the Serial LAN PHY with 64B/66B encoding. Your disagreement is with this
> mode of operation, not the picture. I know it's a minor point, but I am trying
> to accurately portray our debate in pictures since words are apparently not
> working.
Again, you are absolutely correct. I disagree with this mode
of operation. Because this picture represents this mode of
operation, I don't particularly like it but my distaste is
based solely on the mode of operation that it represents, not
the picture itself. I think it is a great picture to describe
your previous view of XAUI/XGXS and PCS operation.
>
> > Page 4: A minor twist to page 3.
>
> Wow! This comment boggles my mind!
>
> This picture is the heart of the presentation and illustrates a solution to
> problems exemplified in page 2, call it Ben's picture, and page 3, call that one
> Rich's picture. I must not have done a good job on the picture in page 4 or
> maybe they all look too similar.
>
> This page shows control codes being generated by the transmitting RS and
> modified by the transmitting XGXS, if present. Control codes are then
> transparently transported by the PCS and over the medium. All control codes not
> specified by 10 GbE are translated to Idles by the RS. The latter translation
> occurs in a manner analogous to that of the 1000BASE-X PCS Receiver.
Again, the picture is a fine one that, I believe, accurately
represents your current view of XAUI/XGXS and PCS operation.
I guess I should have been more explicit. I'm not against the
incremental step that this page shows. This incremental step
of having the RS treat everything it doesn't recognize as an
/I/ is fine. I merely disagree with the base content that was
carried forth from page 3.
>
> > Page 5 & 6: I don't see any difference between these 2 pages.
> > I agree with this.
>
> I included these for completeness. They illustrate the "reverse" or Device B to
> Device A path analogy to Pages 2 and 3, respectively.
>
> > Page 7: A minor twist to 6 & 7. Though subtle, I don't like
> > this but I could probably be convinced by using the same
> > arguement that allows the 1000Base-X receive state machine
> > to treat "everything else" as /I/.
>
> I'm still surprised by your comment on page 4 since Page 7 illustrate the
> "reverse" or Device B to Device A path analogy to Page 4. Your statement that
> "to treat "everything else" as /I/" is exactly what I had in mind. I'm offering
> this as the solution to our debate. I'm open to other solutions which can
> resolve our debate in a simple manner.
As I tried to clean up earlier, I agree that this incremental
step is a good one (having the RS treat everything it doesn't
recognize as an /I/). I simply disagree with carrying /A/K/R/
outside the boundary of the XGXS blocks.
The bottom line is that we're still in disagreement with the
fundamental aspect of this proposal. The pictures are great,
the addition to the RS is great. I simply don't think /A/K/R/
should be carried outside the boundaries of the XGXS blocks
and you think that it's okay if it does. I don't seem to have
changed your mind and you don't seem to have changed mine.
I think we could have gotten to this point about a month
faster if we were drawing on napkins, sitting in nice comfy
chairs drinking Guiness.
>
> > I don't think any of my responses have surprised you. At this
> > point in the thread, I think we know where each other stands.
> > It would be interesting to hear a few others weigh in on this.
> >
> > Thanks for the nice pictures. This should make involvement by
> > the rest of the group much easier.
>
> That was the intention. Anyone else out there want to offer their opinions?
Please, let's get some new blood in on this discussion! I feel
like we're in a vacuum.
Ben
--
-----------------------------------------
Benjamin Brown
Router Products Division
Nortel Networks
1 Bedford Farms,
Kilton Road
Bedford, NH 03110
603-629-3027 - Work
603-624-4382 - Fax
603-798-4115 - Home
bebrown@xxxxxxxxxxxxxxxxxx
-----------------------------------------