RE: Bit numbering I-D nit

[Robert Snively <rsnively@Brocade.COM>]

Note that the IETF mapping we are looking at is not an
Ethernet or an IP mapping, but rather a TCP mapping.  The
mapping from TCP to IP to Ethernet is fortunately not
relevant to this discussion.

The FC frames we are looking at are actually two mappings,
one being the memory mapping of the bytes in the payload,
the other being the related mapping of the bytes in the
headers and trailers and payload onto the FC wire stream.

A simple table structure can express all those relationships,
making it nice and clear for people.  Because it is
a mandatory convention, it must reside in the introductory
text of the FC Encapsulation.  It should be either referenced
or replicated in all protocols that derive from that
encapsulation so that people don't make any inadvertent
and incorrect simplifications based on IETF-only or FC-only
knowledge.

Bob Snively                        e-mail:    rsnively@brocade.com
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110



> -----Original Message-----
> From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
> Sent: Friday, March 22, 2002 3:26 PM
> To: hufferd@us.ibm.com; roweber@acm.org
> Cc: ips@ece.cmu.edu
> Subject: RE: Bit numbering I-D nit
> 
> 
> John,
> 
> The bits would be on the wire the same way we present the bit 
> numbering.
> Both specs use the same position in a word as the most 
> significant, but they
> name the bits differently. This can lead to human confusion and
> interoperabillity problems. It is important to let the reader 
> know that
> there are two different naming schemes applied to the bits by 
> the different
> standards they are dealing with. We have had to handle a very similar
> problem in mapping Ethernet payloads into a Sonet frame for the 10 Gig
> Ethernet work. 
> 
> We should let the reader know about the bit labeling with a brief
> description before the header diagrams. For instance, in the 
> iSCSI draft, we
> could add something like the following to the text of clause 9:
> 
> "Note that SCSI and IETF documents use different conventions 
> for labeling
> bits and bytes. SCSI documents label the bits of each byte 
> from 0 to 7 with
> 7 being the most significant bit. SCSI documents label the 
> bytes with byte 0
> being the first byte. IETF documents label the bits of each 
> word from 0 to
> 31 with 0 being the most significant bit. Therefore, SCSI 
> would label the
> first bit of the first word as bit 7 of byte 0 and IETF would 
> label the same
> bit as bit 0. This document labels bits following the IETF 
> conventions. This
> is a difference in labeling convention and does not represent 
> a difference
> in placement of bits or fields."
> 
> For the Fibre Channel related documents, the paragraph could be: 
> 
> "Note that Fibre Channel and IETF documents use different 
> conventions for
> labeling bits. Fibre channel documents label the bits of each 
> word from 0 to
> 31 with 31 being the most significant bit. IETF documents 
> label the bits of
> each word from 0 to 31 with 0 being the most significant bit. 
> Therefore,
> Fibre Channel would label the most significant bit of a word 
> as bit 31 and
> IETF would label the same bit as bit 0. This document labels 
> bits following
> the IETF conventions. This is a difference in labeling 
> convention and does
> not represent a difference in placement of bits or fields."
> 
> An alternative place for this would be under Conventions used in this
> document, but I think it is better to put the information in 
> the section
> with the headers. This could be in addition to an Annex if 
> people feel an
> Annex necessary.
> 
> Pat
> 
> 
> -----Original Message-----
> From: John Hufferd [mailto:hufferd@us.ibm.com]
> Sent: Thursday, March 21, 2002 8:04 AM
> To: roweber@acm.org
> Cc: IPS Reflector
> Subject: Re: Bit numbering I-D nit
> 
> 
> 
> Ralph,
> I may have looked at this wrong, but though we have to change 
> the way we
> present (print) the bit numbering, the bits on the link are 
> the same way it
> was, or at least that is the way I read the RFC requirement.  
> What do you
> think is the issue?
> 
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136, Cell: (408) 499-9702
> Internet address: hufferd@us.ibm.com
> 
> 
> Ralph Weber <ralphoweber@compuserve.com>@ece.cmu.edu on 
> 03/20/2002 08:34:57
> PM
> 
> Please respond to roweber@acm.org
> 
> Sent by:    owner-ips@ece.cmu.edu
> 
> 
> To:    IPS Reflector <ips@ece.cmu.edu>
> cc:
> Subject:    Bit numbering I-D nit
> 
> 
> 
> I am getting serious flack from the Fibre Channel
> community over the bit numbering requirement
> in http://www.ietf.org/ID-nits.html.
> 
> The problem is that Fibre Channel uses the
> other bit numbering scheme and interoperability
> woes seem certain unless something gets
> documented in the IETF RFCs.
> 
> Everybody agrees that the body of the FC
> Frame Encapsulation and FCIP drafts can
> have the IETF bit numbering in the figures.
> 
> What they all want is an appendix, or some
> such thing in the drafts/RFCs that translates
> it all back to the Fibre Channel view of
> reality.
> 
> Such a thing seems destined to make waves
> in the IETF review process, and possibly
> even be a target for the RFC Editor's ax.
> 
> Should I just jump of the top of the Hilton
> now, or is there a way out of this mess?
> 
> Thanks.
> 
> Ralph...
> 
> 
> 
> 
>