RE: DRAFT Minneapolis Minutes -- ACA Discussion

[Charles Monia <cmonia@NishanSystems.com>]

> - 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".
> 
A point of clarification:

Without going into the gory details, the ACA mechanism has been suggested as
a way of avoiding the loss of strict ordering that occurs when a logical
unit completes a command with an error status.

Keeping in mind the underlying iSCSI issue, I assume the question here is
not support for the ACA function as a SCSI option but whether or not iSCSI
will MANDATE the implementation of ACA as a condition for iSCSI compliance.
In that context, "dropping ACA" would amount to not requiring a logical unit
to implement the feature.

A subsidiary issue, not discussed, was whether to request a T10 extension to
the ACA semantics to cover command processing errors other than those
represented by the CHECK CONDITION status (e.g., QUEUE_FULL). 

Charles
> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Friday, April 06, 2001 7:27 PM
> To: ips@ece.cmu.edu
> Subject: DRAFT Minneapolis Minutes
> 
> 
> 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.
>