Official IPS Orlando interim minutes

[Black_David@emc.com]

IPW Working Group
Orlando Interim Meeting Minutes, January 16-17, 2001
----------------------------------------------------

These minutes report conclusions reached at the meeting with comments
on subsequent action on the mailing list where appropriate.

-- iSCSI and related items (January 16th, plus about an hour on
	the morning of January 17th)

(1) Framing
- The iSCSI draft will be revised to add a formal iSCSI interface
	to framing
	- This will support the current marker approach, SCTP, and
		SCTP-like chunking for TCP.
	- The existing description of markers will be moved to an
		appendix as an example.
-The WARP group working on RDMA will write a draft on using SCTP-like
	chunking for iSCSI without RDMA

(2) Error Recovery
- Terminology Changes
	- "Reference Number" and "RN" are used only for SCSI
		-iSCSI uses "Sequence Number" and "SN" instead
	- "AER" is used only for SCSI
		- iSCSI communication of asynchronous events is through
			a mechanism that is now called "Asynchronous
Messages"
			- iSCSI uses these to implement AER
		- If a SCSI initiator has disabled AER, iSCSI does not
			send the corresponding Asynchronous Messages, but
may
			still send iSCSI to iSCSI Asynchronous Messages that
			do not cause AER events visible to SCSI.
- CmdSN (formerly CmdRN) is mandatory in all cases to simplify things.
	- This includes single connection sessions
- SCSI has defined a new (optional) SCSI Command Ref Number
	- iSCSI will use byte #2 in the iSCSI header (currently Reserved)
		to transport the SCSI CRN when it is present.
	- This is not the ideal solution, but matches the level of
		support in FCP.
	- SCSI uses a transport-specific mode page to negotiate CRN
		usage, therefore iSCSI will use a text key to handle
		this negotiation (updated based on investigation after
		the meeting).
- DataSN (formerly DataRN) functionality will be removed.  Error
	recovery is now at the granularity of commands, not within a
	command.
- There will be a significant connection recovery write-up,
	including details, procedures and examples added to the draft.
- Ping/NOP issues
	- A description of intended usage will be added to the draft
		as advice to implementers.
		- A ping is intended to check whether the corresponding
			protocol is alive
	- NOP responses are not permitted to request further responses
		in order to avoid NOP loops
- Abort WARNING will be added to the draft.
	- Immediate Delivery of Aborts and similar task management
		commands may have unexpected results when multiple TCP
		connections are in use in a single iSCSI session because
		Abort, Clear Task Set, etc. may bypass command(s) to be
		aborted/cleared on other TCP connections.
	- Ordered Delivery should be used instead when this is a concern.
(3) CRC
	- [[iSCSI will use separate CRCs on header and data to make
		header modification easier for systems that need to do
that.]]
		NOTE: This meeting conclusion was *rejected* on the mailing
		list and hence remains an open issue.
		- Using the same CRC algorithm on header and data is
			simpler - in particular the idea of using a 16-bit
			CRC on the header was discarded.  
			NOTE: This conclusion to not use 16-bit CRC
algorithms
				remains the WG consensus. 
		- One CRC should cover both the fixed header and optional
			extensions.
			NOTE: This is part of the separate CRCs conclusion
that
				was rejected on the list, and hence this
issue is
				open.
	- Sense of the room on CRC Algorithms
		- CRC-32 is the obvious first/default choice.
		- There is some interest in investigating both weaker
			(Adler-32) and stronger (CRC-64) CRCs (CRC-64
			may not be appropriate for header,
			and is still a research topic).
	- CRCs are MUST implement
		- Open issue: whether CRC use is negotiable
		- Default: Use CRCs
	- Limiting the amount of data per CRC
		- Probability of undetected error rises with amount of
			data covered by one CRC.
		- There will be at most one data CRC per PDU
		- This limit SHOULD be enforced limit by fragmenting
			large data blocks into Multiple Data PDUs
		- Julian Satran will look for the reference that
			suggests CRC-32 should not be used on data blocks
			significantly larger than about 8-10k.
(4) Security
	- Current iSCSI security digests will be removed in favor of
		IPsec and/or TLS
		- Only reason for digests is data integrity (i.e., CRCs)
		- Open issue: How does iSCSI negotiate or detect presence
			of lower level security?
		- Open issue: What is minimum security required to be used
			(authentication/integrity) by IETF?
			Resolution: IETF requires implementation of strong
				security sufficient for public networks, but
				permits negotiation down to weaker (or even
				no security), *provided that* the
negotiation
				is secure (e.g., against man in the middle
				attack to force negotiation of "no
security".
			- SRP and Kerberos login authentication will remain
				in the iSCSI draft.
(5) Naming
	- UTF-8 will be used instead of ASCII for text strings in
		iSCSI login and text commands, naming, discovery, etc.
	- Binary values will be translated to text strings [further
		discussion on the list indicated a preference for
		hex (0xnnn format) and decimal representations] and
		encoded in UTF-8 rather than adding type/length support
		to send them natively.
	- Localization of iSCSI text is forbidden on the wire for
		interoperability reasons (e.g., keys/values in login
		and text commands are the same byte strings, no matter
		what the locale).

-- FCIP and related items (January 17th)

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, has been submitted in mid-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 Black provided input on QoS (David is a coauthor of the
Differentiated Services header and architecture RFCs).  The FCIP draft
should
be revised to avoid specifying a specific Differentiated Services Code Point
(DSCP) and should instead specify expected/required 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.  We really
need more input on this from the FC switch vendors.  This will be discussed
in the FC-BB2 meeting at T11 to solicit their input.

6) Security -- Authentication a must.  IPSec and TLS are 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.

IETF IP Storage (ips) WG
Interim Meeting Attendees
Orlando, Florida - January 16, 2001
-----------------------------------

David Black			black_david@emc.com
John Hufferd		hufferd@us.ibm.com
Jack Harwood		jharwood@emc.com
David Peterson		dap@cisco.com
Julian Satran		Julian_Satran@il.ibm.com
Costa Sapuntzakis		csapuntz@cisco.com
Steve DeGroote		sdegroote@cisco.com
Mark Bakke			mbakke@cisco.com
Naoki Watanabe		naoki.wtanabe@hds.com
Neil Wanamaker		ntw@crossroads.com
Donald Getty		donald_getty@ti.com
Larry Lamers		LJLAMERS@ieee.org
Jim Hafner			hafner@almaden.ibm.com
Bob Nixon			bob.nixon@emulex.com
Ken Moe			kenneth.moe@sun.com
Mark Edwards		medwards@eurologic.com
Wayland Jeong		wayland@troikanetworks.com
Bill Terrell		terrell@troikanetworks.com
Bob Snively			rsnively@brocade.com
Ralph Weber			roweber@acm.org
Stephen Ostrowski		sostrowski@giganet.com
Jim Williams		jimw@giganet.com
Mike Mesnier		michael.mesnier@intel.com
Randy Haagens		randy_haagens@hp.com
Bill Lynn			bill-lynn@corp.adaptec.com
Rob Haydt			robhay@microsoft.com
Vit Novak			vit.novak@sun.com
Albert Chang		albert.chang@compaq.com
Roger Cummings		roger.cummings@veritas.com
Howard Hall			howard@pirus.com
John Scheible
Dal Allan
Mike Fitzpatrick		mfitzpatrick@fcpa.fujitsu.com
Jon Sreekanth		jon.sreekanth@trebia.com
Elizabeth Rodriguez	egrodriguez@lucent.com
Joe Steinmetz		joe_steinmetz@agilent.com
Matt Wakeley		matt_wakeley@agilent.com
Luciano Dalle Ore		luciano.dalle.ore@quantum.com
Kevin Gibbons		kgibbons@nishansystems.com
Josh Tseng			jtseng@nishansystems.com
Charles Monia		cmonia@nishansystems.com
Henry Yang			Henry.Yang@mcdata.com
Paul Congdon		paul_congdon@hp.com
Vi Chau			vchau@gadzoox.com
Gaby Hecht			ghecht@gadzoox.com
Pierre Labat		pierre_labat@hp.com
James Pinkerton		jpink@microsoft.com
Terry Gibbons		terry.gibbons@lsil.com
Craig Carlson		cwc@ancor.com
John Vrabel			j.vrabel@san.com
Somesh Gupta		somesh_gupta@ieee.org

IETF IP Storage (ips) WG
Interim Meeting Attendees
Orlando, Florida - January 17, 2001
-----------------------------------

Elizabeth Rodriguez	egrodriguez@lucent.com
David Black			black_david@emc.com
Murali Rajgopal		muralir@lightsand.com
Craig Carlson		craig.carlson@qlogic.com
David Peterson		dap@cisco.com
Josh Tseng			jtseng@nishansystems.com
Kevin Gibbons		kgibbons@nishansystems.com
John Vrabel			j.vrabel@san.com
Albert Chang		albert.chang@compaq.com
Bob Nixon			bob.nixon@emulex.com
Jon Sreekanth		jon.sreekanth@trebia.com
Mike Fitzpatrick		mfitzpatrick@fcpa.fujitsu.com
Donald Getty		donald_getty@ti.com
Jack Harwood		jharwood@emc.com
Wayland Jeong		wayland@troikanetworks.com
Mark Edwards		medwards@eurologic.com
Henry Yang			Henry.Yang@mcdata.com
Paul Congdon		paul_congdon@hp.com
Steve Degroote		sdegroote@cisco.com
Vi Chau			vchau@gadzoox.com
Gaby Hecht			ghecht@gadzoox.com
Venkat Rangan		venkat@rhapsodynetworks.com
Howard Hall			howard@pirus.com
Larry Lamers		LJLAMERS@ieee.org
Lucian Dalle Ore		Luciano.Dalle.Ore@quantum.com