FCIP - Orlando Interim Summary

[Black_David@emc.com]

With profuse apologies for the delays in getting this
out, here's the summary of the FCIP portion of the
Orlando interim meeting in January.  If anyone objects
to any of the conclusions here, please do so quickly
so that the official minutes that will be sent to
the IETF Secretariat early next week will reflect
the current state of the WG.  Thanks, --David


1) Ralph Weber verbally presented some changes to the FCIP draft,
specifically dealing with framing, header and timestamps. A formal proposal,
in the form of a draft, will be submitted in February.

2) SOF/EOF encodings.  The current draft uses the same SOF/EOF encodings as
are in the FC-BB specification.  While that draft lists a number of
encodings, only a subset are required by that document.  Discussions about
the various encodings have lead to the conclusion that the subset should be
the only SOF/EOF encodings specified in the FCIP document.  That subset is
restricted to class 2 and class 3 support.  The other encodings are either
not defined in FC-FS (framing and signaling), are Class 1 specific (which is
not currently used in the industry) or class 4 (which is not yet defined).

3) Figure 4 in the document needs to be updated.  It currently implies that
the FC header will immediately follow the TCP header.  Misleading, in that
it appears to be at a fixed offset and does not indicate that optional TCP
headers may be in place between the TCP and FC headers.  In particular, put
a box with ellipses in it to make this clearer.

4) David provided input on QoS.  Need to avoid specifying a specific code
point and instead specify expected performance criteria.

5) Error recovery is still a major issue in the current specification, in
particular the handling of the FC and TCP timeouts and their correlation.
Ralph Weber's discussion earlier in the session applicable here.  Really
need more input on this from the FC switch vendors.  To be discussed at the
T11 meeting, to see how this can be addressed.

6) Security -- Authentication a must.  IPSec and TLS the logical choices
here.  TLS may be the better choice of the two.  iSCSI facing the same
issues.  FCIP should take iSCSI decisions/considerations into account and
try to align with iSCSI if possible.

7) Clarification needed to the document indicating that E_Ports are
supported by this document.  While not prohibited by the current document,
not clear that this is supported either.


---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------