IPS Working Group R. Weber
INTERNET-DRAFT
<draft-ietf-ips-fcencap-wglc-00.txt>
(Expires September, 2002)
FC Frame Encapsulation WG Last Call
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as Reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This ips (IP Storage) working group draft contains all the working
group last call comments received regarding:
draft-ietf-ips-fcencapsulation-06.txt
The proposed disposition of each comment also is recorded in this
draft.
Summary of Comments
Technical: 17 Comments, resulting in about 12 Changes
Editorial: 60 Comments, resulting in about 41 Changes
-------------------------------------------------------
Totals: 77 Comments, resulting in about 53 Changes
Ralph Weber [Page 1]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Table Of Contents
1. Comments from David Black . . . . . . . . . . . . . . . . . . . 2
2. Comments from Mallikarjun Chadalapaka . . . . . . . . . . . . . 19
3. Comments from Rob Elliott . . . . . . . . . . . . . . . . . . . 23
4. Additional Changes Discovered After WG Last Call . . . . . . . 32
1. Comments from David Black
=========================
Comment 1
-- Section 1 - Scope
The organization responsible for the Fibre Channel standards (NCITS
Technical Committee T11) has determined that some functions and
modes of operation are not interoperable to the degree required by
the IETF. This draft includes applicable T11 interoperability
determinations in the form of restrictions on the use of this
encapsulation mechanism.
[E] Is there an official citation for this statement? It really needs
one to be published in an archival unchangeable format such as an RFC.
Accepted resulting in the following changes
Add reference to FC-MI. Change "NCITS" to "INCITS".
Comment 2
-- Section 2 - Encapsulation Concepts
FC frames have several possible lengths.
[E] Should read "variable length" or something like that - this
implies several possible choices of fixed length, which is incorrect.
Accepted as follows
Replace the sentence with: "FC frames are variable length."
Ralph Weber [Page 2]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 3
-- Section 2 - Encapsulation Concepts
To facilitate transporting FC frames over TCP the native FC frame
needs to be contained in (encapsulated in) a slightly larger
structure as shown in figure 1.
[E] The use of TCP in this context is overly restrictive. This
encapsulation is in principle applicable to any means of transport
over IP, including TCP, SCTP, UDP, and carrier pigeon :-), even though
in practice all the initial uses will use TCP.
Accepted as follows
Change "over TCP" to "over an IP based transport such as TCP".
Comment 4
-- Section 2 - Encapsulation Concepts
The format and content of an FC frame is described in the FC
[E] "is" --> "are"
Accepted
Comment 5 Technical
-- Section 3 - The FC Encapsulation Header
-- Section 3.1 - FC Encapsulation Header Format
The values in the Protocol# field are assigned by
IANA [8]. The following values are known to be in use:
- FCIP -- TO BE ASSIGNED by IANA
- iFCP -- TO BE ASSIGNED by IANA
[T] Delete the text starting with "The following values" and insert
a forward reference to the IANA Consideration section.
Accepted as written.
Ralph Weber [Page 3]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 6 Technical
-- Section 3 - The FC Encapsulation Header
-- Section 3.1 - FC Encapsulation Header Format
FC Encapsulation receivers may compare the Protocol# and -Protocol#
fields as an additional verification that an FC Encapsulation
Header is being processed.
FC Encapsulation receivers may compare the Version and -Version
fields as an additional verification that an FC Encapsulation
Header is being processed.
[T] Those "may"s are misleading. I think "SHOULD" is appropriate, but
I could accept "SHOULD"s that only applied when the CRC is not valid.
Accepted as follows
Replace the two cited sentences with:
FC Encapsulation receivers SHOULD either validate the CRC or
compare the Protocol# and -Protocol# fields to verify that an
FC Encapsulation Header is being processed according to a
policy defined by the encapsulating protocol.
FC Encapsulation receivers SHOULD either validate the CRC or
compare the Version and -Version fields to verify that an
FC Encapsulation Header is being processed according to a
policy defined by the encapsulating protocol.
As per comment 8, sentences similar to those shown above will be
added to the -Flags and -Frame Length descriptions.
Ralph Weber [Page 4]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 7 Technical
-- Section 3 - The FC Encapsulation Header
-- Section 3.1 - FC Encapsulation Header Format
Flags (bits 31-26 in word 3): The Flags bits provide information
about the usage of the FC Encapsulation Header as shown in figure
3.
Note: Implementers are advised to consult the specifications of
protocols that use this header to determine how each individual
protocol uses the bits in the Flags field.
[T] The "Note:" paragraph is part of the CRCV issue (see below), and
probably needs to be deleted as part of resolving that issue. This
paragraph also has the additional problem in that it implies that
protocol specific uses of the reserved flags are allowed, which is not
the case.
Accepted
Comment 8 Technical
-- Section 3 - The FC Encapsulation Header
-- Section 3.1 - FC Encapsulation Header Format
Reserved (Flags, bits 31-27 in word 3): These bits are reserved for
use by future versions of the FC Encapsulation and SHALL be set to
zero on send. Protocols employing this encapsulation MAY require
checking for zero on receive, however doing so has the potential to
create incompatibilities with future versions of this
encapsulation.
[E] Second sentence is poorly worded. Suggested rewrite: Protocols
employing this encapsulation SHOULD ignore the Reserved bits on
receive in order to avoid creating incompatibilities with possible
future versions of this encapsulation. I believe this change is
editorial, and it also applies to the -Flags and -Frame Length fields.
Rejected
This change is not editorial. It is technical and specifically
recommends against some of the validity checking described in FCIP.
The working group argued this issue several times and (I thought)
agreed that checking the version number was sufficient to know that
the reserved flags must be zero.
Ralph Weber [Page 5]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
The last sentence of the comment is a misnomer with respect to the
rest of the comment, however it makes sense when applied to comment 6.
Comment 9 Technical
-- Section 3 - The FC Encapsulation Header
-- Section 3.1 - FC Encapsulation Header Format
CRCV (CRC Valid Flag, bit 26 in word 3): A CRCV bit value of one
indicates that the contents of the CRC field are valid. A CRCV bit
value of zero indicates that CRC are invalid. Some protocols may
always check the CRC without regard for the state of this bit. The
value of the CRCV bit SHALL be constant for all FC Encapsulation
Headers sent on a given TCP connection.
[T] The "Some protocols may always check the CRC ..." is the CRCV
issue that Mallikarjun also found and that has been problematic in the
past. I believe that what's going on here is that all protocols have
to check the Protocol#, and once that's been checked, the
implementation knows whether there's supposed to be a CRC there and
hence doesn't need to look at CRCV. In practice this won't cause
problems, as including the CRC when it's not supposed to be there is
harmless, and failing to include it when it should be there will
almost certainly cause a CRC check failure.
I offer a proposal to resolve this by expanding the Protocol#
registry that IANA will create so that each registered protocol
must supply not only its name and an RFC reference, but also whether
the protocol uses (Yes) or does not use (No) the CRC in this header.
The above text could then be revised to make the CRCV check at the
receiver OPTIONAL in all cases because its value can be inferred
from the protocol#.
Rejected in principle, with some changes required
At the Nashua interim, someone wanted a client protocol to be free
to use CRC or not according to operating environments (e.g., lab-
local vs. network attachment). The proposed definition of usage by
IANA based on protocol would eliminate this option.
It must be noted that the content of Annex A also conflicts with
this result from the Nashua interim. To correct that, the following
text from Annex A must be replaced:
"CRC
"Protocols employing this encapsulation SHALL either:
Ralph Weber [Page 6]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
"1) Require a valid CRC to be sent and the CRCV Flag bit to be
sent as one, or
"2) Require the CRC field to be sent as zero and the CRCV Flag
bit to be sent as zero."
The Annex A CRC discussion (shown above) will be replaced with:
"Protocols employing this encapsulation SHALL define the
procedures and policies necessary for verifying that an
FC Encapsulation Header is being processed."
Also, make the change described in the response to comment 35.
Comment 10
-- Section 3 - The FC Encapsulation Header
-- Section 3.1 - FC Encapsulation Header Format
[E] Also need to generalize away from TCP connection to allow possible
future use with other transports.
Accepted, resulting in the following changes
1) In the description of CRCV: change "TCP connection" to
"connection";
2) In Section 4:
- change "TCP-connected elements" to IP-connected elements";
- change "traverse the TCP connection" to "traverse the
connection";
- change "injected into a TCP connection" to "injected into
a connection"; and
3) In Section 5.3: change "transmission over TCP" to "transmission
over an IP Network";
Ralph Weber [Page 7]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 11 Technical
-- Section 3 - The FC Encapsulation Header
-- Section 3.1 - FC Encapsulation Header Format
[T] Here or in the description of the Protocol Specific fields, a
warning to implementers is needed says some sort of error checking
redundancy (e.g., the ones complements found elsewhere in the header)
SHOULD (or MUST) be used when the CRC is not used. This warning
should be duplicated in Section 3.2.1. This is a technical comment,
but should not be controversial.
Rejected
Specific statements of action have been added to each applicable
field as per comment 6.
Comment 12 Technical
-- Section 3 - The FC Encapsulation Header
-- Section 3.1 - FC Encapsulation Header Format
Time Stamp [integer] and Time Stamp [fraction] (words 4 and 5): The
two Time Stamp fields contain time at which the FC Encapsulated
frame was sent as known to the sender. The format of integer and
fraction Time Stamp word values is specified in Simple Network Time
Protocol (SNTP) Version 4 [9]. The contents of the Time Stamp
[integer] and Time Stamp [fraction] words SHALL be set as described
in section 4.
[E] For convenience, it might be good to summarize those formats here
with an indication that [9] is the normative authority. I don't feel
strongly about this, though.
[T] We have a problem here - RFC 2030 is Informational, and hence
can't be referenced in a normative fashion from a standards track
document. I'll talk to Ralph offline about how to get around this.
Accepted resulting in the following changes
1) Copy the definitions of the two time stamp words from RFC 2030
to this draft (estimated to be 2 paragraphs);
2) Copy any necessary ancillary definition text from RFC 2030 to
this draft (estimated to be no more than 5 paragraphs); and
3) Make the reference to RFC 2030 information, both in the body
text and in a Informative References section (which will have
to be added).
Ralph Weber [Page 8]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 13
-- Section 3 - The FC Encapsulation Header
-- Section 3.1 - FC Encapsulation Header Format
CRC (word 6): When the CRCV Flag bit is zero, the CRC field SHALL
contain zero. When the CRCV Flag bit is one, the CRC field SHALL
contain a CRC for words 0 to 5 of the FC Encapsulation Header
computed using the polynomial, initial value, and bit order defined
for Fibre Channel in FC-FS [3]. Using this algorithm, the bit order
of the resulting CRC corresponds to that of FC-1 layer. The CRC
transmitted over the IP network shall correspond to the equivalent
value converted to FC-2 format as specified in FC-FS.
[E] I realize that FC-FS is the latest and greatest version of the FC
frame standard, BUT, referencing a project in progress for this sort
of basic CRC mechanism is an invitation to procedural problems. Can
this reference be changed to FC-PH accompanied by a note that FC-FS is
supplanting FC-PH, but will make *no* changes in this area? Note that
I'm comfortable with the earlier reference to FC-FS for frame
contents.
Accepted (Partially)
T11 has clearly stated that FC-PI and FC-FS are the preferred
documents over FC-PH. The statement takes the form of a refusal to
process FC-PH for international standardization, with the preferred
recourse being to process FC-PI and FC-FS when they are available.
Furthermore, referencing FC-PH really requires references to FC-PH-2
and FC-PH-3, since FC-PH is not a fully correct document in and of
itself. In other words, there is a rats nest here.
It is not a matter of FC-FS being the latest and greatest. T11 has
unambiguously stated that FC-PI and FC-FS are the only true path
with very clear reasons for that decision.
Action to be taken:
In the References section, the note will be added following the
FC-FS reference: "Note: The Fibre Channel frame structure and CRC
features referenced by this draft, while formally described in
FC-FS, are substantially unchanged from similar features described
in Fibre Channel Physical and Signaling Interface (FC-PH), ANSI
X3.290-1994, June 1, 1994."
Ralph Weber [Page 9]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 14 Technical
-- Section 3.2.1
[T] The warning that the protocol-specific fields SHOULD (or MUST) be
protected by redundancy needs to go here.
Accepted.
Comment 15
-- Section 3.2.1
Redundancy based header validation can be built from simple logic
(e.g., XORs and comparisons). Header validation based on redundancy
also is a step wise process in that the first word is validated,
then the second, then the third and so on. A decision that a
candidate header is not valid may be reached before the complete
header is available.
[E] First sentence is superfluous and probably should be deleted as
it's rather hardware-oriented.
Accepted with the following results
Replace the cited paragraph with: "Header validation based on
redundancy is a step wise process in that the first word is
validated, then the second, then the third and so on. A decision
that a candidate header is not valid may be reached before the
complete header is available."
Ralph Weber [Page 10]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 16
-- Section 3.2.2
CRC based header validation employs a straight forward algorithm
(e.g., compute the CRC for all bytes preceding the CRC word and
compare the results to the CRC word's contents). The number of
comparisons required to perform CRC validation is exactly one and
the method for computing the CRC is well known with proven
implementations.
[E] Last sentence is superfluous and probably should be deleted as
it's rather hardware-oriented.
Accepted with the following results
Replace the cited paragraph with: "Header validation based on the
CRC defined in section 3.1 requires computing the CRC for all bytes
preceding the CRC word, and comparing the results to the CRC word's
contents."
Comment 17
-- Section 4 - Measuring Fibre Channel frame transit time
To comply with FC-FS [3], an FC Fabric must specify and limit the
lifetime of a frame.
[E] Same comment as before about referencing FC-FS. Can this be
changed to reference FC-PH with a note that FC-FS won't change this
... or is FC-FS tinkering with things here?
Rejected see response to comment 13.
Ralph Weber [Page 11]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 18 Technical
-- Section 4 - Measuring Fibre Channel frame transit time
When originating an encapsulated frame, an entity that does not
support transit time calculation SHALL always set the Time Stamp
[integer] and Time Stamp [fraction] fields to zero. When receiving
an encapsulated frame, an entity that does not support transit time
calculation SHALL ignore the contents of the Time Stamp words. The
protocol SHALL specify whether or not implementation support is
required.
[T] This is about "MUST/SHOULD/MAY implement". Need a similar
requirement on the protocol to specify "MUST/SHOULD/MAY use" and under
what conditions.
Accepted with the following results
Add the following sentence: "The protocol SHALL specify those
conditions under which a received encapsulated frame MUST have
its transit time checked before forwarding."
Comment 19 Technical
-- Section 4 - Measuring Fibre Channel frame transit time
The policy for processing frames while in the Unsynchronized state
SHALL be defined by the protocol specification, including whether
or not the entity may continue to send and receive frames from the
IP network.
[T] On the receive side, this condition appears to be specified in the
wrong direction. Receiving frames from the IP network cannot possibly
cause problems, the issues are in forwarding (stale) frames into FC.
Accepted resulting in the following changes
1) Change "processing" to "forwarding"; and
2) Remove "including whether ..." to the end of the sentence.
Ralph Weber [Page 12]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 20
-- Section 4 - Measuring Fibre Channel frame transit time
When de-encapsulating a frame, an entity in the Synchronized state
SHALL:
[E] While the sub-bullets are correct, they leave a reader unfamiliar
with FC somewhat high and dry. I would include a "for example" in
both a) and b), along the lines of:
a) For example, if a calculated transit time exceeds a value
that could cause the frame to violate FC maximum time in
transit limits (Time Out Values), the protocol may specify
that the frame is to be discarded.
b) For example, a protocol may specify that frames for which
transit time cannot be determined are never to be forwarded
over FC.
Accepted with changes
Everything except he phrase "(Time Out Values)" will be incorporated
as written.
Comment 21
-- Section 4 - Measuring Fibre Channel frame transit time
[T] At the end of this section, it would be good to warn protocol
designers that well-designed protocols are unlikely to accomplish
useful communication when the communicating entities are in different
states, and hence protocol designers need to consider how to
coordinate state transitions, especially the Unsynchronized to
Synchronized transition on startup and an unexpected Synchronized to
Unsynchronized transition (e.g., caused by loss of contact with an
external time service). This is related to some issues that
Mallikarjun found.
Accepted but only in principle
The problem is not coordinating states between the two entities. The
problem is keeping both entities in the Synchronized state as much
of the time as possible.
Little, if anything, is accomplished by adding protocol overhead to
coordinate state transitions.
This is not to say that the comment lacks merit.
Ralph Weber [Page 13]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Action to be taken:
Add the following note at the end of the section: "Note: For most
purposes, communication between entities is possible only while in
the Synchronized state."
Comment 22
-- Section 5 - The FC frame
-- Section 5.1 - FC frame content
As shown in figure 4, the FC frame content is defined as the data
between the EOF and SOF delimiters (including the FC CRC) after
conversion from FC-1 to FC-2 format as specified by FC-FS [3].
[E] This needs some more explanation. The important things that need
to be said are:
- FC uses the same 8b/10b encoding as Gigabit Ethernet in
which each 8 bit byte is transmitted using 10 bits on the
wire for reasons that include redundancy and low level
timing synchronization between sender and receiver.
- All discussion of FC frame content in this draft is at the
8b level prior to 8b->10b expansion on send or after 10b->8b
reduction on receive.
The Gigabit Ethernet reference is particularly important in increasing
accessibility of this document to a network-savvy, but new to FC
audience.
Accepted but only in principle
The 8b/10b statement is no more accurate for Fibre Channel than
it is for Ethernet. Ten Gigabit Fibre Channel will use 64b/66b
encoding, the same as ten Gigabit Ethernet. Such a statement must
be worded as an example.
Action to be taken:
Add the following paragraph at the end of the section: "In the
conversion to the FC-0 physical transport, an encoding is applied to
the FC frame content (e.g., 8b/10b encoding like that used in Gigbit
Ethernet) for reasons that include redundancy and low level timing
synchronization between sender and receiver. All discussion of FC
frame content in this document is at the 8-bit byte level, prior to
the application of any such encoding."
Ralph Weber [Page 14]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 23
-- Section 5.3 - FC SOF and EOF
The FC frame content is composed of 8-bit bytes that can be
translated directly for transmission over TCP. The FC SOF and EOF
[3] require 8b/10b special characters that cannot be translated
directly to 8-bit bytes, encoded values are required.
[E] I think this paragraph needs to be moved to Section 5.1, and
replaced with a sentence here that refers back to it. One important
editorial change is "8b/10b special characters that cannot be
translated directly to 8-bit bytes" should be changed to "10b special
characters that have no 8b equivalents" or something like that.
Accepted
Comment 24 Technical
-- Section 5.3 - FC SOF and EOF
SOF (bits 31-24 and bits 23-16 in word 0): The SOF fields contain
the encoded SOF value selected from table 1.
[T] As we've learned from the Class 4 adventure, this table is subject
to change/extension. IANA will need to manage it, and will need some
sort of allocation guidelines to remain consistent with whatever
mechanism produced this peculiar set of values. While we probably
don't want to allow value recycling, we may want to write some text
dealing with retiring values (making them no longer usable). This
also applies to the EOF values in Table 2.
Rejected
The SOF/EOF codes are stable and have not changed for at least three
years. They have been implemented in numerous products for tunneling
FC over ATM and SONET. The only instability is the editor's lack of
understanding about which SOF/EOF codes are required for FC Class 4
operation.
The codes are assigned by T11 and involving IANA in there assignment
would constitute a conflict of jurisdictions.
Ralph Weber [Page 15]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 25
-- Section 5.3 - FC SOF and EOF
Note: FC-BB-2 [6] lists SOF and EOF codes not shown in table 1 and
table 2 (e.g., SOFi1 and SOFn1). However, FC-MI [7] identifies
these codes as not interoperable, so they are not listed in this
specification.
[T] There are a couple of problems here. If FC-BB-2 has assigned
values to SOF and EOF encodings that MUST NOT be used with FCIP, then
we need to instruct IANA to reserve and not allocate those values. As
part of allocating future values in this table, we need to (1)
instruct the author(s) of the draft/RFC doing the allocation to ensure
that T11.3 review of the proposed allocation is obtained (2) that the
IPS WG chair(s) (if the IPS WG still exists) and the Transport ADs are
informed of this review, and (3) that IANA allocates the values
approved by T11.3 as opposed to choosing values. Since Murali's been
appointed as T11's official liaison to IETF, I think it's his
responsibility to suggest a coordination process.
Accepted only because a platform is needed for an editorial change
As per the response to comment 25, IANA must not be involved in
assigning SOF/EOF codes.
Actions to be taken
The SOF and EOF tables will be modified to add a column for "Class"
and each SOF or EOF value will have one of the following entered in
the new column: "2", "3", "2 & 3", "2, 3 & 4", or "4".
The new column will allow FCIP and iFCP to reference Class 2,
Class 3, and Class 4 SOF/EOF values in their statements of what
the protocol supports.
Ralph Weber [Page 16]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 26
-- Section 7 - Normative References
I would really like to remove the normative reference to FC-FS,
substituting FC-PH with a note that FC-FS will replace FC-PH. I don't
object to an FC-FS reference where it's really needed, but the
portions of FC-FS that this draft relies on are sufficiently basic and
stable that an FC-PH reference will make their stability clear. The
FC-BB-2 and FC-MI references for SOF and EOF codes need to become non-
normative as part of setting up the IANA registry and management
process. The FC-SW-2 reference may not need to be normative here.
Rejected see response to comment 13.
Comment 27
-- Section 7 - Normative References
RFC 1700 is almost certainly the wrong reference to instruct IANA on
what procedures to follow. See RFC 2434 for guidance on this topic,
although it may not be necessary to reference it.
Accepted
Comment 28
-- ANNEX A - Protocol Requirements
[E] I think this should be an Appendix, rather than an Annex. Some
changes may be in order here based on the above comments.
Accepted resulting in the following changes
1) Change "Annex A" to "Appendix A" and "Annex B" to "Appendix B",
while remembering to correct the Table of Contents too;
2) Add discussion of IANA assignment of CRC usage, per the
resolution of comment 9; and
3) In item d) change "processing" to "forwarding".
Ralph Weber [Page 17]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 29
-- ANNEX B - IANA Considerations
[T] This needs to be made somewhat more explicit and direct. IANA is
looking for simple straightforward instructions roughly of the form
"IANA is instructed to do <X>". in particular, the following sentence
is a problem:
Standards action on this RFC should be accompanied by IANA
assignment of the following two Protocol# values:
It should read something like:
In addition to creating the FC Encapsulation Protocol Number
Registry, the standards action of this RFC allocates the following
two values from this registry:
While one normally asks IANA to allocate values, the exception is that
when creating a registry, one can instruct IANA as to what the initial
contents are (i.e., a new registry does not have to be created empty).
Accepted
Comment 30
-- ANNEX B - IANA Considerations
[T] Also, earlier comments suggest that the Protocol# registry needs
to be expanded with a CRC field (Yes/No) and that registries need to
be created for the SOF and EOF values.
Rejected See comment 9 and comment 24.
Ralph Weber [Page 18]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 31
-- ANNEX B - IANA Considerations
It is requested that the ips working group chairs or the Transport
Services area directors be notified when any new Protocol# value
assignment is requested.
[T] Given that an approved RFC is required, this sentence seems
redundant. If the intent was notification of the IPS WG chairs and/or
ADs when a an I-D draft is submitted that will cause a Protocol#
assignment if/when approved as an RFC, the language needs to say that
and should be rephrased to require notification of the IP Storage WG
chairs (don't use WG acronyms here) and notification of the Transport
ADs instead in the case that the IPS WG does not exist or is not
active.
Accepted, delete the sentence
Comment 32
-- ANNEX B - IANA Considerations
[T] Also see previous comments about needing to set up an IANA
registry for SOF and EOF values. I'll work with Ralph on crafting the
right IANA instructions.
Rejected see comment 24.
2. Comments from Mallikarjun Chadalapaka
=====================================
Comment 33 Technical
- Section 3.1, page 4. For the Protocol# values for FCIP and iFCP,
the Annex B should instead be referred.
Accepted see comment 5.
Ralph Weber [Page 19]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 34 Technical
- Section 3.1, pages 4 & 5. I notice that all the ones complement
fields (-Protocol#, -Version etc.) are described as "contains the
ones complement" as opposed to "SHALL contain ones complement",
whereas the corresponding non-1's complement fields have the SHALL
wording. Any reasons for this distinction?
Accepted
Change -xxx descriptions to use SHALL.
Comment 35 Technical
- Section 3.1, page 5, CRCV bit description.
"Some protocols may always check the CRC without regard for
the state of this bit."
I am troubled by the literal implication of this sentence. Why
would that be so?
Would the encapsulating protocol not mandate CRCV to be set to
valid always instead? It seems like the purpose of defining a
common encapsulation format and associated semantics is watered
down for no stated reason...
Accepted
Delete the cited sentence.
The following response is provided in response to the question asked
in the last paragraph of the comment. FCIP mandates that CRCV be
zero. iFCP mandates that CRCV be one.
Comment 36
- Section 3.2.1, page 7. S/b "step wise" w/ "stepwise".
Accepted
Ralph Weber [Page 20]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 37
- Section 4, page 7.
"The protocol SHALL specify whether or not implementation
support is required."
A general comment on usage of the term "protocol" here and in other
areas - I would recommend using "encapsulating protocol" instead to
make it easier (or perhaps use "Protocol" may be...) for the reader
to follow the usage.
Accepted, use "encapsulating protocol"
Comment 38
- Section 4, page 8. Since there is no mention of a notification
frame to announce an entity's transition into/out of the
Synchronized state, I assume it's possible and even anticipated that
there may be times when one of the two entities may be in
Unsynchronized state even while the operational encapsulating
protocol requires Synchronized operation. The expectation is that
the state rules (and encapsulating protocol-specified rules) should
cause this type of start-up/transient scenario to be correctly
sorted out. Is that right?
Inquiry
Yes it is anticipated that one entity may be in the Unsynchronized
state and thus discarding some FC frames. Presumably, the entity
will return to the Synchronized state quickly or close the connection.
It is not clear that any requirements need to be state for
interoperability. It is definitely undesirable to add protocol
overhead to coordinate the synch/unsynch state without there being
a well demonstrated need.
Comment 39 Technical
- I think it might be useful to add a statement in this section along
the lines of - If the encapsulating protocol mandates Synchronized
operation, the entity MUST NOT accept TCP connections on the well-
known port(s) unless the entity is in the Synchronized state.
Rejected
Since encapsulating protocols are allowed to specify operation in
the Unsynchronized state, specifying this level of detail about how
Synchronized operation is handled over reaches the bounds of this
specification.
Ralph Weber [Page 21]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 40 Technical
- Section 4, page 9, Synchronized state rules. I think this should
also address what is to be done in case there's a case of "bad
synchronization" when Time Stamp words are valid. For ex., when the
received value is smaller than the received entity's timebase, I
assume it would result in arriving at a huge transit time. While
the huge transit time may cause the frame to be discarded, it isn't
clear to me what may cause the TCP connection drop and a re-synch.
Accepted with the following results
Change the recommended transit time evaluation to use the absolute
value of the time difference.
Comment 41
- Section 4, page9, Synchronized state rules.
"If both Time Stamp words have a value of zero, the receiving
entity SHALL process the de-encapsulated frame without computing
the transit time. The disposition of the frame and any other
actions by the recipient SHALL be defined by the protocol
specification."
I am rather perplexed by the usage of the words here. While saying
that the frame shall be "processed", this also seems to leave it up
to the encapsulating protocol to define if it needs to be processed
(as reaffirmed by rule (e) in Annex A). One change that makes it
clear to me is:
S/b "SHALL process the de-encapsulated frame"
w/ "SHALL de-encapsulate the frame".
Accepted
Comment 42
- Section 7
It may be useful to add informative references to FCIP and iFCP.
Rejected
Adding such references seems ill advised for the following reasons:
1) Their presence will delay publication of this draft until both
FCIP and iFCP have cleared the last call process; and
2) Such references will be less than informative in the specific
event that this document was commissioned to serve, the case
Ralph Weber [Page 22]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
where a third FC encapsulation protocol is defined, after which
this document would mislead readers into believing that only two
"encapsulating protocols" exist.
Comment 43
- Section 9, page 13. S/b "no long working" w/ "no longer working".
Accepted
Comment 44
- Annex B, page 15. It isn't clear to me from this sentence if the
Protocol# values (1 & 2) are temporarily assigned by this draft for
now.
"Standards action on this RFC should be accompanied by IANA
assignment of the following two Protocol# values:"
Inquiry
It is said that IANA will not assign the Protocol# values until
presented with an RFC (not an internet draft) that instructs them to
do so. Therefore, the current Protocol# values are requests to IANA
(or perhaps instructions to IANA).
3. Comments from Rob Elliott
=========================
Comment 45
Title page
I assume change bars will be gone from the final version.
Inquiry
The change bars appear only in the PDF file. The normative document
in IETF terms is the TXT file, where there are no change bars.
Comment 46
Abstract
"common encapsulation" s/b "common Fibre Channel encapsulation"
Accepted
Ralph Weber [Page 23]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 47
1 Scope
"NCITS" s/b "INCITS"
Accepted
Comment 48
All section headers
Should each word in a section header be capitalized or not? This
document has a mix.
(3.2.2 doesn't capitalize validation, 4 doesn't capitalized frame
transmit time, etc.)
Accepted as follows
All section headers will be modified to follow the capitalization in
the header for section 3.1.
Comment 49
2. Encapsulation Concepts
"The Fibre Channel frame has a CRC that provides error detection..."
s/b "The Fibre Channel frame includes a Cyclic Redundancy Check (CRC)
code that provides error detection..."
Accepted
Comment 50
Figure 1 Title
"FC frame Encapsulation" s/b "Encapsulated FC Frame"
Response
This figure and the text describing it are concerned with how a FC
frame is encapsulated. Thus the figure title. The fact that the
result is an Encapsulated FC Frame should not be introduced in a
figure title.
Ralph Weber [Page 24]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 51
3.1 Figure 2
Where is word defined as 32 bits?
Response
This figure seems to define that concept clearly. It would be a
shame to add a glossary to the draft simply to contain this one
definition.
Comment 52
3.1 FC Encapsulation Header Format
"Protocol (bits 31-24 in word 0):" s/b "Protocol# (bits 31-24 in word
0):"
Accepted
Comment 53
3.1 FC Encapsulation Header Format
RE: "TO BE ASSIGNED by IANA"
When are these protocol values filled in?
Inquiry
See the response to comment 44.
Comment 54
3.1 FC Encapsulation Header Format
"The Version field SHALL contain 0x1 ..." s/b "The Version field SHALL
contain 0x01 ..." since Version is an 8-bit field.
Accepted
Comment 55
All instances of "ones complement"
"ones complement" s/b "one's complement"
Google reports 10,000 "one's complement" vs 3700 "ones complement"
Accepted
Ralph Weber [Page 25]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 56
3.1 FC Encapsulation Header Format
"...i.e., the usage of this word is defined..." s/b "...i.e., the
usage of these words is defined..." because there are two protocol
specific words.
Accepted
Comment 57
3.1 FC Encapsulation Header Format
Regarding: "Protocols employing this encapsulation MUST NOT make use
of the Reserved Flags bits in any fashion other than that described
here." "here" s/b "by this encapsulation". "Here" implies that future
versions are excluded.
Accepted
Comment 58
3.1 FC Encapsulation Header Format
"A CRCV bit value of zero indicates that CRC are invalid." s/b "A CRCV
bit value of zero indicates that the contents of the CRC field are
invalid."
Accepted
Comment 59
3.1 FC Encapsulation Header Format
Frame Length is a greater than 1 byte quantity. Which bit is the MSB?
There's discussion later on page 9 inside the FC frame section, but
endianness should be covered before the encapsulation header is
described.
Rejected
Per http://www.ietf.org/ID-nits.html:
"Historically, RFCs have specified byte and bit order according
to a US DoD rule which made byte zero be the first byte in an
address range, and bit zero be the most significant bit in a
word or field. For example, you will find drawings like this
one (from RFC 791) in many RFCs: when you make drawings like
it, you should follow the same rule. Label your bit positions,
Ralph Weber [Page 26]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
bit zero is the most significant bit, and place the first
addressable byte at the upper left-hand corner."
Observance of these rules is enforced for all RFCs. Therefore,
additional specifics are unnecessary.
See also comment 77.
Comment 60
3.1 FC Encapsulation Header Format
Regarding: "...the FC Encapsulation Header SHALL always be word-
aligned;..."
Replace "SHALL" with "is".SHALL doesn't seem right here. There's no
option to not make it aligned, since the format is fixed length. We
don't say the CRC field shall be one word long - it just is one word
long.
Accepted
Comment 61
3.1 FC Encapsulation Header Format
"...contain time..." s/b "...contain the time..."
Accepted
Comment 62
3.1 FC Encapsulation Header Format
Should the field names in SNTP ("Seconds" and "Seconds fraction") be
referenced? It's not immediately obvious which words correspond.
Accepted as follows
Change all occurrences of "[integer]" to "[Seconds]" and all
occurrences of "[fraction]" to "[Seconds Fraction]".
Ralph Weber [Page 27]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 63
3.1 FC Encapsulation Header Format
SNTP describes its Seconds field formats with bit 0 on the left as the
MSB.
I assume FCencap wants to use bit 31 on the left as the MSB. How can
this be made clearer?
Rejected
MSB is always on the left and the bit numbering will be changed to
match SNTP as per comment 77.
Comment 64
3.1 FC Encapsulation Header Format
"...CRC for words 0 to 5 of the FC Encapsulation Header computed using
the polynomial, initial value, and bit order defined for Fibre Channel
in FC- FS..." s/b "...CRC for words 0 to 5 of the FC Encapsulation
Header computed using the equations, polynomial, initial value, and
bit order defined for Fibre Channel in FC-FS..."
As indicated by iSCSI CRC discussion, the FC "initial value" assumes a
certain implementation. I think if you add the word "equations" it
implies that the FC annex be followed more completely.
Accepted
Comment 65
3.2 FC Encapsulation Header Validation
I would include a hyphen in both Redundancy-based and CRC-based (since
they act as modifiers to "mechanism")
Rejected
Editor's prerogative.
Comment 66
3.2.2 CRC based FC Encapsulation Header validation
Straightforward is one word
Accepted
Ralph Weber [Page 28]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 67
4. Measuring Fibre Channel frame transit time
Is it worthy of a note that this field runs out of bits in 2036? SNTP
mentions the problems of zero. Using zeros to indicate invalid at the
FCencap level means any solution future SNTP's define will not work.
Rejected
The way to handle this problem is to change the Version field when
the SNTP rollover issue is resolved.
Comment 68
4. Measuring Fibre Channel frame transit time
"...accordance with the applicable protocol specification;..." s/b
"...accordance with the protocol specification;..."
Rejected
I see nothing gained by the removal of the work "applicable".
Comment 69
5.2 Bit and Byte Ordering
As mentioned before, description of ordering for the Encapsulation
Header needs to be before the Encapsulation Header section, not buried
in the FC frame chapter.
Rejected
As mentioned in comment 77 there is an enforced IETF depiction of
byte ordering that clarifies this issue by having all IETF documents
follow the same rules.
Comment 70
5.3 FC SOF and EOF
Somewhere it should be noted that FC frame content is always 32-bit
aligned. Otherwise, FC encap would need insert pad bytes to keep EOFs
as shown in figure 5.
Accepted as follows:
Add a the following sentence after this one: "The number of 8-bit
bytes in the FC frame content is always a multiple of four."
Ralph Weber [Page 29]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 71
5.3 FC SOF and EOF
"...bytes," s/b "bytes;"
Accepted
Comment 72
5.3 FC SOF and EOF
How were the SOF and EOF codes chosen?
It seems like the SOF codes should be chosen to increase the Hamming
distance between each other. 0x28 is only one bit different from
0x29, so four bit errors could change SOFf into SOFi4 undetected.
With only 8 values to encode in 32 bits, it seems like better Hamming
distance could be provided.
Rejected
The SOF and EOF code values are defined in FC-BB. They are already
implemented in products based on FC-BB and are not open to changes.
Comment 73
5.3 FC SOF and EOF
what is the rule about checking the redundant SOF, -SOF, EOF, and -EOF
fields? Same as the FCencap rules or different?
Rejected
There is no rule.
Ralph Weber [Page 30]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
Comment 74
7. Normative References
Is it ok to reference a draft standard in this "normative references"
section?
A link to a page that points to how to buy a copy of the official
standard would be appropriate for [5] and any other completed T11
standards.
Accepted (Partially)
Yes, it is okay to reference draft standards in normative
references. This assurance was provided by a Transport Area
Director during the Minneapolis IETF meeting.
A clone of the ANSI web URL from a T10 or T11 standard will be add.
Comment 75
9. Acknowledgements
"...no long..." s/b "...no longer..."
Accepted
Comment 76
10. Full Copyright Statement
"2001" s/b "2002"
Accepted
Ralph Weber [Page 31]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
4. Additional Changes Discovered After WG Last Call
================================================
Comment 77 Technical
The draft fails to conform to the following requirement stated in
http://www.ietf.org/ID-nits.html.
Historically, RFCs have specified byte and bit order according
to a US DoD rule which made byte zero be the first byte in an
address range, and bit zero be the most significant bit in a
word or field. For example, you will find drawings like this
one (from RFC 791) in many RFCs: when you make drawings like
it, you should follow the same rule. Label your bit positions,
bit zero is the most significant bit, and place the first
addressable byte at the upper left-hand corner.
3.1. Internet Header Format
A summary of the contents of the Internet header follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Accepted with the following results
1) Add the following paragraph immediately following the Table Of
Contents: "Warning to Readers Familiar With Fibre Channel: Both
Fibre Channel and IETF standards use the same byte transmission
order. However, the bit and byte numbering is different. See
Appendix A for guidance."
2) Change figures 2, 3, and 5 to conform to the IETF bit and byte
numbering;
3) Remove bit and byte numbers wherever they appear in the text; and
4) Insert Appendix A with the following text:
Ralph Weber [Page 32]
Internet-Draft FC Frame Encapsulation WG Last Call March, 2002
"Appendix A - Fibre Channel Bit and Byte Numbering Guidance
"Both Fibre Channel and IETF standards use the same byte
transmission order. However, the bit and byte numbering is
different.
"Fibre Channel bit and byte numbering can be observed if the
data structure heading shown in figure 6, is cut and pasted
at the top of figure 2 and figure 5.
W|------------------------------Bit------------------------------|
o| |
r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 |
d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0|
Fig. 6 - Fibre Channel Data Structure Bit and Byte Numbering
"Fibre Channel bit numbering for the Flags field can be observed
if the data structure heading shown in figure 7, is cut and
pasted at the top of figure 3.
|------------------------Bit--------------------------|
| |
| 31 30 29 28 27 26 |
Fig. 7 - Fibre Channel Flags Bit Numbering"
Ralph Weber [Page 33]