IPS: (very) DRAFT(y) London Minutes

[Black_David@emc.com]

Apologies for some glitches in taking these minutes -
there are some areas in which they're less than complete
(noted with double square brackets [[..]] below).  Please
send additions/corrections/etc. to me and/or the list.

Presenters - please send me the slides used in London
if you have not already done so.

Thanks,
--David

IP Storage (IPS) Working Group
DRAFT Minutes
London Meeting - August 6 and 7, 2001
-------------------------------------

-----> Monday, August 6 <---------

Administrivia and Agenda Bash - see bashed agenda.

Discussion of IETF last call.  Process will involve emailed comments
directly to authors, so draft editors need to make sure author addresses
(including email) are up to date.  There is no formal process akin to a
T10 or T11 letter ballot and comment resolution.

-- Plugfest - Robert Russell, UNH

Testing of implementations against each other, a reference implementation,
and a conformance test suite (latter two focused on Login).

Many implementations did not do any Login, most who did only implemented 2
or 3 keys, DataPDULength, InitialR2T, ImmediateData were the most common.

Login was a disaster - all kinds of things not done right, ignored,
instability.  Most systems wanted to go to full feature phase based on
default login values rather than actually engage in negotiation.

Set of 20 points were posted to mailing list, most have been dealt with
(e.g., strings are null-terminated, not null-separated).

CmdSN/StatSN increment at once, not after completion of Login.
[[NOTE: There may have been other items that are missing from my notes.]]

Resolved on list - can Initiator stop short of max amount of unsolicited
data?
	A: Initiator can do what it wants.

Open Issue - Simplification of Login.  Separate security sub-phase,
OpParamReset.
	Can operational parameters be exchanged before security phase?

[[ There may be some things missing here. ]]

Login needs state diagram, specification of legal combinations and
sequences.

At least one implementation did perform error recovery.

-- iSCSI Login - Julian Satran, IBM

Login Structure: Lots of parameters.  List request for two phases - the two
phases
	are currently implicit, separated by SecurityContextComplete.

Design concern is minimizing number of handshakes, not minimizing
programming
	complexity.
Comments from audience that simpler is better.  Complex things tend to have
complex
	failure modes.  Need to be careful about adding too many new
handshakes.

Julian's Proposals:  (1) SecurityContextComplete by itself in message
exchange.
		         (2) Should always have a security exchange.
                     (3) Both phases explicit but optional.

Discussion: Need a much more structured description.  Has too much branching
	complexity at the moment.  Two separate phases with defined
transitions
	between them would help greatly.

Discussion of whether to use SecurityContextComplete key to indicate end of
	security phase vs. a byte in the command.  Direction is to keep
using the
	key.

The spec needs to include a state machine (and transition table), and a much
	more organized (e.g., in one place) description of the login
process.

State in the command would help make it clear.  The WG sense of the room was
that
	explicitly indicating the login state (e.g., in security or
operational
	negotiation phase) via state in the command was preferred to
requiring
	the participants to implicitly track the state (provides a check
that
	things are where the participant thinks they are).

-- iSCSI Security - David Black

I noted two important questions and answers:

(1) What about corporate firewalls?  Will they block ESP traffic.
A: If they do, have to sent iSCSI without ESP to the firewall.

(2) How does one get SPI values and keys from iSCSI negotiation into ESP?
A: Manual key interface, which most IPsec implementations have.

[[Notes are sketchy on this because I have a hard time taking notes and
	presenting at the same time.  Please add anything important.]]

-- IKE and IPsec - William Dixon, Microsoft

Preview of draft-aboba-ips-iscsi-security-00.txt.  See that draft (now
available).

-- Framing - Steph Bailey, Sandburst

All specification of framing mechanisms is being taken out of the main
	iSCSI draft and will reside in
draft-ietf-tsvwg-tcp-ulp-frame-00.txt.
	A -01 version should be coming in the near future.

Two framing mechanisms are described in that draft:

(1) Periodic Markers - modified receivers, but no modifications to sender's
	TCP stack.  Probabilistic bound on required buffering, but much less
than
	a window per active connection.  Hardware will be complex.

(2) PDU Alignment - modified receivers, modified senders to align PDUs to
TCP
	segments.  Cleanly bounded buffering, unless alignment fails.
Modifications
	to TCP are needed to detect a middlebox that has resegmented and
destroyed
	alignment.

Each mechanism is applicable to different situations, hence both are in the
	tsvwg draft.  Common interface to both mechanisms.

iSCSI recommendations:
	- Remove marker annex and refer to tsvwg draft
	- Define negotiation for PDU alignment
	- Strongly encourage PDU alignment implementation (SHOULD).

Summary of proposal on what iSCSI should require for framing:
	- Receivers can do nothing, PDU alignment, or all 3.  Marker impl.
requires
		PDU alignment framing
	- Senders should implement all 3, MUST implement markers.

	These don't match because want receivers to call the shots.  Markers
are
	easy to implement on send, hard to implement on receive.

It was not possible to obtain rough consensus in the room on this proposal
or
a revised version of it presented the following day.  Will have to be
resolved
on list starting from a reasonably detailed explanation of the rationale for
these requirements from the framing folks.

-- Error Recovery - Mallikarjun, HP

Reality is somewhere between "Trust but verify" and "can't trust transport".

Four levels of recovery - within-command, -connection, -session, and full
session
	recovery.  Only the last is required, others are options.

Command counting is needed for both ordering AND flow control.

Error recovery tools:
	- Header and Data digests
	- SNACK
	- Recovery R2T (negotiable)
	- Unsolicited NOP-IN (e.g., sequence fixup)
	- Retry (command replay, failover, and hole-plugging)

Topic 1: SNACK issues (slide 8)  Alternatives
	- Assign a CmdSN (deadlock issues)
	- Accept non-determinism [e.g., lost SNACK] (odds of loss are low)
	- Allow SNACK retransmit (may get data retransmit)
	- Define timer-based SNACK retransmit (Ouch!)
	- Drop SNACK
Seems to be important for tapes (partial I/O recovery).

Proposal: Keep SNACK, if we drop it we're betting on the TCP checksum
	(or the ESP MAC).  Problem with moderate rate of checksum failure
	to detect errors

------> Tuesday <---------

SNACK discussion centered on the need for iSCSI error recovery for
existing tape.  Some current tape devices do things that make SCSI
level recovery from a failed command impossible (e.g., send successful
completion to write command before actually writing to the tape).
There is a new tape command set in the works that will improve this
situation by using absolute block addressing for tapes rather than
the current relative addressing, but there's a need to deal with
existing tape devices.

Sense of the room - keep SNACK, keep it optional, keep it for existing
	tape because consequences of not having it are horrendous.

Topic 2 - Error Recovery levels, one key to say which level rather than
	key per type of recovery.  0 would be required recovery, 1-4 are
options
	up to command replay.

Sense of the room - Adopt hierarchical approach to error recovery
specification.
	Number of levels and order thereof to be worked out on list.

Mallikarjun will send paragraphs to list describing each level, what it does
over and above the one below it, and what features of iSCSI that it uses.
There was a comment that level 1 in Mallikarjun's chart may need to be a
MUST
to provide effective support for tape.  Needs to be discussed on the list.

--- Main Document - Julian Satran, IBM

NOP issue - NOP may close command window.  Proposed changes:
	- Remove P bit.  If there's data, DataSegment length indicates.
	- If task tag is valid, response is required (ITT valid = Initiator
		wants answer, TTT valid = Target wants answer, NOP-In cannot
		have both tags valid).
In addition, the I bit must be set when immediate data is present

Sense of room is to make these changes - objections should be sent to the
list.

Serialization Interlock; this is about being able to preserve
command ordering in the presence of things like a CHECK CONDITION
caused by a temporary queue full situation.  The T10 advice that ACA is
not the right solution has been accepted.  Julian will follow this up
with T10 at their September meeting.  The alternative appears to be to
use Unit Attention (which has changed in the past year to have properties
more useful in this situation) as it only affects a single initiator.

-- Simplification Ideas - David Black

Four proposals resulting from a solicitation for "radical simplification"
ideas
on the list.

1] Eliminate Multiple Connection sessions - no real interest in pursuing
this.
2] Login Templates - take up on list as part of general discussion of Login.
	This is about organizing all the login keys into a small number of
sets
	where if one key from the set is present, all the keys must be
present,
	and possibly requiring the keys to appear in a particular order.
3] Eliminate CRCs in favor of MACs - take up at interim meeting.
4] Eliminate Immediate data - take to list, at a minimum consider removing
	the ability to use both immediate and unsolicited data in the same
command.

-- Naming and Discovery - John Hufferd, IBM

Specification pieces of N&D are now in main document.  Want N&D to
	become an informational RFC.
Sense of Room - approve this direction, N&D draft to become an informational
RFC.

IQN Uniqueness.  This is about making sure that the new holder of a domain
name
doesn't define any iSCSI names that match ones defined by the old holder.
	Two choices:
	- Enterprise Number
	- Date (yyyy-mm)

The Area Director commented that IANA is not set up to handle a large number
of enterprise number allocation requests, making the second approach
preferable.

Sense of room - use date of assignment of domain name to naming authority.
	Details to be worked out and posted to list.

Case Sensitivity
	- Currently case-sensitive.  Now recommend NAMEPREP
case-insensitivity,
	draft-ietf-idn-nameprep-05.txt.  Use NAMEPREP in admin tools,
byte-wise
	compare in implementations.

The Area Director noted that the right thing to do was to allow the IDN WG
to standardize NAMEPREP.  If they abandon it, IPS could pick it up.

Sense of room - Wire format is NAMEPREP'ed names, receivers do bytewise
compare,
	admin tools MUST ensure that all names are in NAMEPREP format (i.e.,
	iSCSI implementations don't have to check this).

Send Targets issues - Bookmarks vs. Option 5 issue will go to the list.  N&D
team
	(Mark Bakke?) needs to generate summary of current alternatives to
start
	discussion.

Sense of room - "iscsi" target canonical name MUST NOT be used (reserved).

Issue of whether to include Alias support in protocol.  Room was
approximately
	evenly split on this, hence the issue was taken to the list, where
the
	first attempt to resolve it subsequently failed.  

-- iSNS - Josh Tseng, Nishan

Relationship of SLP and iSNS: SLP for discovery, iSNS for active management.

iSNS + SLP is better than SLP alone (SLP to discover iSNS, use iSNS
services).
Will work with SLP community to improve SLP.  SLP DA integrates will with
iSNS
server, providing centralized management of SLP discovery (can still use SLP
on wire).  Full integration with iSNS client on each iSCSI device improves
further (e.g., access list configuration).

iSNS open source will integrate with other databases, e.g. LDAP, MS Active
Directory

Sense of room to approve iSNS MIB as an official IPS WG work item - next
version
	will be an official WG draft (draft-ietf-ips-...).

-- SLP Discovery for iSCSI - Marjorie Krueger, HP

Document is getting close to done.  Recent changes were to add portal group
tags
	and describe unicast SLP.  SLP is moving from proposed to draft
standard.
	 RFC 3082 provides SLP notification (currently Experimental).

-- iSCSI MIB - Marjorie Kreuger, HP

UML is done, lots of counters have been discarded.  Is mostly consistent
with -07.

Need to get work started on SCSI MIB - volunteers should see Marj.

NOTE: did not take up SCSI model mapping to iSCSI - Marj will post
recommended
	rules and pointer to presentation to list.