RE: FC Encapsulation WG Last Call comments

["Elizabeth G. Rodriguez" <Elizabeth.G.Rodriguez@123mail.net>]

Hi David,

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

I think there is a misconception with the EOF/SOF encodings.
The encodings themselves have been fairly stable for some time. 
The issues that came about recently is identifying which encodings
pertained to Class 4 specifically -- that was not obvious.

In any case, even if the encodings were not stable, SOF/EOF encodings
are in the domain of INCITS and the FC-FS/FC-BB/2 documents.  I do not
see how we can have IANA govern these encodings.

Thanks,

Elizabeth

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of
Black_David@emc.com
Sent: Sunday, March 17, 2002 11:31 PM
To: ips@ece.cmu.edu
Subject: FC Encapsulation WG Last Call comments

Comments flagged with [E] for editorial, [T] for technical.

----- FC Encapsulation -06 -----

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

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

   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.

   The format and content of an FC frame is described in the FC

[E] "is" --> "are"

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

   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.

   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.

   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.

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

[E] Also need to generalize away from TCP connection to allow possible
future
use with other transports.

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

   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.

   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.

-- Section 3.2.1

[T] The warning that the protocol-specific fields SHOULD (or MUST) be
protected
by redundancy needs to go here.

   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.

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

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

   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.

   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.

   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.


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

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

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

   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.

   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.

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

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.

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

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

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

   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.

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

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------