[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Google
  Web www.spinics.net

iSCSI Implementer's Guide - WG Last Call status, 2nd try



Your WG chair has resurfaced and apologizes for being
incommunicado these past few weeks (took a badly needed
vacation for a couple of weeks, including from email,
and have been digging out ever since).  In the time since
my previous WG Last Call status message, three things
appear to have happened:

a) Issue (2) has been resolved on the list with new text
	in the -04 version of the draft.  I thank everyone
	involved.
b) There was some discussion of behavior of task management
	functions that affect more than one initiator when
	not all the initiators have the TaskReporting key
	set to FastAbort.
c) There was some discussion of the Response Fence.

--- b) Task management when not all initiators use FastAbort.

I believe the rough consensus of the WG is that FastAbort
can only be used on a session that has negotiated its use
(i.e., the new TaskReporting key was negotiated to FastAbort).
This has a couple of implications:

b1) This means that if the session that sent the TMF uses
FastAbort but some other affected iSCSI session doesn't,
FastAbort MUST NOT be used with that other affected session.

b2) In the reverse direction, if the session that sent the TMF
does not use FastAbort, but some other affected session does,
FastAbort could be used with that other affected session.

Each of these raises an issue:
o This text in Section 4.1.3 on target behavior violates b1):

     d. MUST generate an Asynchronous Message PDU with AsyncEvent=5 
          (section 8.1) on: 
          i)  each connection of each third-party session to which at 
            least one affected task is allegiant, and 

--> The target has to first check whether the third-party session
	uses FastAbort, otherwise the AsyncEvent=5 message will be
	rather unexpected (e.g., by a 3720-only initiator).  This
	text needs to be corrected.

o The text in Section 4.1.2 currently prohibits FastAbort on
	third party sessions when FastAbort is not used on the
	session that sent the TMF (i.e., the "could" in b2 above
	is a "MUST NOT" with the current text).

--> Any requirement option (MUST/SHOULD/MAY/MUST NOT/SHOULD NOT)
	appears to work here, but we need to consciously make a
	decision.  I lean towards "SHOULD" instead of "MUST NOT".
	Keep in mind that this is for a session for which usage
	of FastAbort has been negotiated.  Any change from the
	current "MUST NOT" will entail a fair amount of editing
	work.

--- c) The Response Fence

I believe that the WG rough consensus of the discussion about
the Response Fence functionality is that the functionality is
needed to deal with the ordering issues in the cases called
out in Section 3.3.3 of the -04 version of the draft (note
that the Initiator MUST negotiate TaskReporting=ResponseFence
or TaskReporting=FastAbort before relying on response fence
behavior).

Unfortunately, I have to object to Section 3.3.1, which appears
to be trying to modify SAM-2 to add the Response Fence flag.
That can't be done in IETF, and any T10 modification would be
to SAM-4, whereas iSCSI is still based on SAM-2.  I think the
mention of SAM-2 and model of the interface between SCSI and
a SCSI transport needs to be removed from Section 3.3.1.  The
items numbered (1) and (2) in that section look ok (and in
fact useful to keep) - the problematic text is that which
suggests the existence of a "Response Fence flag" in the
abstract interface between SCSI and the SCSI transport (e.g.,
iSCSI) along with the mention of "SCSI protocol interface
model" in Section 3.3.  The upshot will be that Response
Fence behavior will be specified in a fashion that makes it
only applicable to the cases spelled out in Section 3.3.3.

------------------

So, I think we need further list discussion of the b) and c)
issues, including what the b2) requirement level should be.

I will monitor this discussion on at least a daily basis in
the hope of driving it to a relatively prompt conclusion, and
I will carefully read the -04 version of the draft in the
interim to see if I turn up anything else that may need
attention.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@xxxxxxx        Mobile: +1 (978) 394-7754
----------------------------------------------------

-----Original Message-----
From: Black_David@xxxxxxx [mailto:Black_David@xxxxxxx] 
Sent: Thursday, December 28, 2006 3:27 PM
To: ips@xxxxxxxx
Subject:  iSCSI Implementer's Guide - WG Last Call status

The Working Group Last Call on this draft nominally ended on
December 18th, but there was no reason to treat that as a hard
cutoff.  I am now ending the WG Last Call on this draft, although
list discussion of issues should be continued.

There have been two issues raised during this WGLC:
(1) Task Management - how to deal with uncooperative third-
	party initiators.  This issue has been resolved
	on the list.
(2) Target checks - whether to discourage targets from
	checking for initiator mistakes that the target can
	tolerate.  At the moment, I think the "rough consensus"
	of the WG is not to do this - if anyone other than
	Eddy thinks this is important to clarify, they need
	to speak up promptly after the holidays.

The process from here is that Mallikarjun will submit a
revised version of the draft in the near future (there are
still some details to be worked out on the list).  I will
be completely out of action (no email) the first two weeks
of January, so there will be time for people to check for
problems/issues/etc.  I will check the revised draft and
send it to Lars with a request for RFC publication sometime
in the second half of January (probably during the week of
January 22nd).

Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@xxxxxxx        Mobile: +1 (978) 394-7754
----------------------------------------------------


_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips


_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips


[IETF]     [Linux iSCSI]     [Linux SCSI]     [Linux Resources]     [Yosemite News]     [IETF Announcements]     [IETF Discussion]     [SCSI]

Add to Google Powered by Linux