DRAFT Minneapolis Minutes

[Black_David@emc.com]

Many thanks to Mark Carlson and Elizabeth Rodriguez for
taking the minutes.  Please send corrections to the list,
as well as any objections to rough consensus decisions
reached in the meeting.  The deadline for changes to
get incorporated in the official minutes is the end of
the day on Wednesday, April 11th.  Thanks, --David

IPS WG Meeting Minutes - DRAFT
IETF #50
Minneapolis MN


Interim Meeting - There will be an interim meeting for the IPS working
group. 
It will be co-located with T10 in Nashua, NH on April 30 & May 1.  
FC related topics will be covered on Monday, April 30.  
SCSI related documents will be covered on Tuesday, May 1.
In addition to the IPS meetings, on Wednesday, May 2, during the
T10 CAP meeting, a discussion of a SCSI MIB will be held. 
Details of this meeting, including location and hotel room information,
have been sent to the IPS mailing list.

TCP framing discussion will be in TSVWG WG meeting the evening of Monday,
March 19.
IPS working group attendees are encouraged to attend, be familiar with the
draft,
and ask questions. The draft was cross-posted to both IPS and TSVWG mailing
lists.
To subscribe to the TSVWG mailing list or to view the archive, see
www.ietf.org/mailman/listinfo/tsvwg

RDMA - RDMA is a separate effort from the framing discussion.
A separate mailing list has been formed to address RDMA
To join, send an email to rdma-subscribe@yahoogroups.com .
***NOTE***: This address has been corrected from the one discussed in the
meeting.

T10 is considering a new SCSI model.  T10 participants agreed that it may
have
advantages but will be very different from current SCSI model.  Therefore it
is currently deferred to SAM-3.
This model may be of interested to iSCSI, as it will have advantages for
iSCSI.

-- iSCSI Requirements --

iSCSI requirements - document is almost complete.
draft-ietf-ips-iscsi-rqmts-01.txt.
1 more draft will be sent out, and then a last call will occur in
approximately 1 month
with the hope of submitted the result as an informational RFC around the
time of the
interim meeting (end of April).  Everyone should review the draft on the
list and
especially check that the MUSTs and SHOULDs are correct and nothing is
missing.

-- iSCSI specification - draft-ietf-ips-iscsi-05.txt --

- CRCs for iSCSI.  Two presentations made with respect to CRC vs checksum
usage in iSCSI.
Recommendation was to use a 32 bit CRC; three mentioned as candidates -
CRC-32C; CRC-32Q and CCITT-CRC32.  Reported that there really is no need for
a 64 bit CRC.
Consensus call on use of CRC instead of checksum. Loud CRC hum; no hum for
checksum,
	so use of CRC rather than checksums is the rough consensus of this
meeting.
Consensus call will be taken on which CRC to use at interim meeting, so that
WG has
more time to investigate and understand the options presented.

Request made for a single mandatory to implement CRC algorithm as opposed
to making the CRC algorithm selection negotiable.

- iSCSI Digests.  Current draft has multiple digests.  
3 proposals presented for digest and related header formats.
Request made for use of TLV format in whatever solution is finalized on.  
Consensus call made to have 1 header digest instead of multiple.  
Barry Reinhold and Julian Satran were asked to work and come back with a
single
proposed format at the Wed  meeting.  The rough consensus of the meeting was
that
the data length should always be in the same place in the header.

Consensus call - descriptors and diagrams should always be kept together in
the document.
	This is the rough consensus of the meeting.

Error Recovery will be addressed at the interim meeting


- Security
Public Key and TLS were removed in version 05 of the iSCSI draft.
Public Key will be reinstated in the 06 draft.
MUST provide authentication and data integrity.
MAY provide data privacy (encryption).

Need to have at least 1 mandatory to implement security protocol.
IPSec seems to be the selection in current draft.
Consensus call - Make IPSec mandatory to implement?  Arguments against, no
consensus.
Consensus call - mandatory to implement SRP?  Hum against.  Will be taken to
interim meeting.
Both Public Key and Radius authentication mechanisms will be added to the
next version
of the draft.

- SCSI ACA discussion

ACA (Auto Contingent Allegiance) is an optional SCSI mechanism that stops
execution
of a sequence of dependent SCSI commands when one of them fails.  The
situation
surrounding it is complex - T10 specifies ACA in SAM2, and hence iSCSI has
to
specify it and endeavor to make sure that ACA gets implemented sufficiently 
(two independent interoperable implementations) to avoid dropping ACA in the
transition from Proposed Standard to Draft Standard.  On the list David
Black
noted that this would make ACA implementation at least a "SHOULD" rather
than a "MAY".

The current iSCSI draft has language requiring use of ACA rather than
implementation;
that's overspecified (it's ok for cooperating iSCSI nodes to decide not to
use ACA),
and will be changed.

In practice, ACA is not a complete solution (e.g., if a Fibre Channel switch
drops
a frame due to a CRC error, ACA will not kick in).  T10 has been working on
other
mechanisms that address problems that ACA addresses in a more comprehensive
fashion,
but has not moved to drop ACA from SAM2, hence iSCSI has to deal with it.


-- iSCSI Boot presentation - draft-ietf-ips-iscsi-boot-02.txt

This draft is relatively stable - the bulk of this draft will become an
informational RFC rather than standards track.  David Black will figure
out whether some piece of it needs to be standards track.

-- iSCSI MIB work presented. - draft-bakke-iscsimib-02.txt

Difficulty in making this an iSCSI MIB only,
in that there is no SCSI MIB currently, but people want to see both iSCSI
and SCSI information addressed.
SCSI MIB will be a topic on the agenda at the next T10 CAP meeting, May 2.  
iSCSI MIB accepted as a WG item; next submission will be official WG item.

-- iSCSI naming and Discovery presented  -
draft-ietf-ips-iscsi-name-disc-00.txt

Two discovery methods presented - iSNS and SLP based.

iSNS is an new name server, specific to IPS.  Question raised as to why not
use SLP.  
Separate SLP presentation presented following; both iSNS and SLP can be
used.  
SLP works for basic discovery whereas iSNS provides additional
information/capabilities, 
including management functionality.

-- URN Namespace document presented - draft-bakke-iscsi-wwui-urn-00.txt

While the meeting consensus was to accept this as an official WG work item,
this was overridden by direction from the IESG subsequent to the meeting.

-- SLP document presented - draft-bakke-iscsi-slp-00.txt 

Meeting consensus was to accept this as an official WG item.

-- Back to iSCSI headers (first thing Wednesday)

Follow up from Monday:  Two header formats presented to WG for
consideration.   One has data length in fixed location, but limits size
of data.  Second more flexible, but data length field not in fixed location.
More details on each format to be written up and posted to list; 
decision on which header format to follow to be decided on list; 
Julian requests decision within 10 days.  The list subsequently
chose the "Format 2" prepared/proposed by Barry Reinhold.

-- iSNS draft presented - draft-ietf-ips-isns-01.txt

Primarily a status report and description of how iSNS applies to all three
protocols in the WG (iFCP, iSCSI, FCIP).  It's required by iFCP, but
optional
for the others.

Rationale for why SLP isn't enough and iSNS is needed will be sent to list.

A concern was raised about relying on iSNS for certificate distribution vs.
certificate exchange between the two ends of an IP Storage connection.  Not
resolved in the meeting and will need further consideration as part of
protocol
security work.

-- Fibre Channel related topics: --

Fibre Channel Common Encapsulation team being formed.  
Small team, with a target size of 6 people.  
Interested people to see David or Elizabeth (co-chairs) by Friday, March 23.

Three encapsulation presentations made: 
  Two had encapsulation format recommendations -
draft-weber-fcip-encaps-00.txt and
	a presentation from Vi Chau (FCIP draft co-author)
  Third consisted of requirements needed for iFCP -
draft-monia-ips-ifcpenc-00.txt

Discussions of expectations from common encapsulation format - 
should provide some means of data integrity & synchronization by 
guarding against accidental interpretation of encapsulated data as an FC
frame if framing synchronization to the data stream is lost and being
recovered;
this is not a requirement to provide a means of preventing intentional
hijacking;
simply a means of validation that what is seen is actually current and
valid.
The WG co-chair made it clear that the encapsulation design team must take
this
issue seriously.

FC Frames have CRC around them, so no CRC needed there, 
but what needs to be wrapped around the common encapsulation piece (header
and/or
header + SOF/EOF codes) to insure that data is correct?  
Statement of direction from WG, based on show of hands, is that CRC should
be used.
This is the rough consensus of the meeting.

One requirement of the draft was initially to make the common header
extensible - 
not needed by FCIP or iFCP.  Consensus call - remove this requirement.  This
is the
rough consensus of this meeting.

-- FCIP draft update discussed - draft-ietf-ips-fcovertcpip-01.txt

No draft submitted since Dec IETF meeting.  
Changes made and discussed by authors, but major pending changes did
not make updated the draft for this meeting reasonable.
Next draft will include changes recommended at both IETF-49 and the interim
meeting, 
as well as a better description of the FCIP port models, encapsulation, etc.

Next draft due April, prior to next interim meeting.

-- FCIP Model presentation - Mike O'Donnell

FCIP port model usage.  In current FCIP draft, unclear as to whether this is
following
a B-Port,  E-Port or some other kind of port model.  Presentation makes
clear that
both E-Ports and B-Ports  can be used by the FCIP device.  In the absence of
FCIP,
an inter-switch link in Fibre Channel connects two E-ports.  If FCIP is
implemented
in the Fibre Channel switch, the result is a logical E-port communicating
over FCIP.
If FCIP is implemented in an external bridge, a real E-port on the switch
communicates
with a B-port on the bridge and the result is still a logical E-port on the
FCIP
side of the switch.  These implementation structures will interoperate
(i.e.,
a logical E-port in a switch can communicate via FCIP with a logical E-port
implemented in a bridge that uses a B-port to talk to an E-port on a switch
- the
FCIP protocol is the same).

FC-BB2 meeting announced - during T11 week in Toronto, Canada on April 9.
Meeting is open to all.  FC-BB2 handles the aspects of FCIP usage that
require
Fibre Channel standards.


-- iFCP status - draft-ietf-ips-ifcp-00.txt

3 additional versions of the draft anticipated between now and August 2001.

Target is that this August draft will be complete, w/o any TBDs.

Noting that the draft contained a MIB lead to a more general discussion of
MIBs.
In general, MIBs should be advanced as separate documents, and authors need
to
look at the FC MIBs developed in the ipfc WG to avoid duplication.
The iSCSI MIB may provide a model for some of the iFCP MIB.

Final note - somehow, we managed to get 3 anagrammed acronyms.  FCIP and
iFCP are
protocols in this WG, and IPFC is the IP over Fibre Channel protocol done by
the
ipfc WG.