Trying again after bouncing (>50KB), tail is now clipped....
----- Forwarded Message ----
From: Mallikarjun C. <cb_mallikarjun@xxxxxxxxx>
To: ips@xxxxxxxx
Sent: Friday, January 5, 2007 2:40:56 PM
Subject: Re: Response Fence Flag
Hi John,
As you correctly point out, there are two distinct but related
topics here.
(1) proper response ordering across participating connections in a
multi-connection session, for a handful of task/TMF responses
(2) proper way to terminate and signal tasks when actions on one
session can impact multiple initiators
(1) is all about response fence, it is covered separately in section
3.3 of IG draft. That's what this email thread started off with.
(2) covers cases that IG had called as as "multi-task abort" cases
that typically have a shared task set across sessions, or are the
result of a Logical Unit Reset TMF. Section 4.1 of IG adresses (2).
So how are (1) and (2) related?
- Some cases covered under (2) overlap with (1), but some cases in (2)
are for single connection sessions. E.g. LU Reset on a single
connection session impacting several 3rd party sessions
- Some cases under (1) overlap with (2), but some cases in (1) have
nothing to do with other sessions. E.g. establishment of ACA on a
non-shared task set
- Section 4.1 (i.e. text for (2)) uses response fence (i.e. text for
(1)) whenever multi-connection sessions are involved in multi-task
abort situations.
I hope that clarifies it. Feel free to ask if that is not clear. The
net is that the response fence is the underpinning notion to describe
the correct iSCSI behavior in a few cases and some of those cases are
about task terminations across third-party sessions.
Mallikarjun
----- Original Message ----
From: John Hufferd <jhufferd@xxxxxxxxxxx>
To: Mallikarjun C. <cb_mallikarjun@xxxxxxxxx>; ips@xxxxxxxx
Sent: Friday, January 5, 2007 1:01:06 PM
Subject: RE: Response Fence Flag
Mallikarjun,
I must admit, that I have been a bit confused with the direction of
the conversation here.
Therefore, I went back and reviewed the charts from Dallas . And as I
remembered, the initial focus was to address the issue of Multiple
Connections per Session (MC/S) (as stated on chart 4 – “Non-issue for
single-connection iSCSI sessions”). So I think I have missed the step
where we have morphed the discussion into one dealing with multiple
sessions. (I am not sure how that happened, or if I miss-read the
charts from Dallas , or have not followed the discussion adequately.)
If we are attempting to define two different issues, one with MC/S and
one with Multiple Session from different Initiators, I think it would
be useful to break down the conversation into Topic A – MC/S and Topic
B Multiple Sessions. It is possible that one solution will addresses
both, but I for one think I am hearing arguments that might be
appropriate for Topic B, while I am thinking about its applicability
to Topic A.
Perhaps, you could address the issue as either being all about MC/S or
explicitly state that it is intended to affect Multiple Sessions also,
and then address the issues and solution for each separately. For
example, I believe Robert was addressing the issue from a view of
Multiple Sessions and if we only intended to address MC/S then I
expect the response might be somewhat different.
Anyway, if you could clear-up some of this, I think it would be useful
(at least to me).
.
.
.
John L Hufferd
Sr. Executive Director of Technology
Brocade Communications Systems, Inc
jhufferd@xxxxxxxxxxx <mailto:jhufferd@xxxxxxxxxxx>
Office Phone: (408) 333-5244; eFAX: (408) 904-4688
Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606
------------------------------------------------------------------------
*From:* Mallikarjun C. [mailto:cb_mallikarjun@xxxxxxxxx]
*Sent:* Friday, January 05, 2007 10:08 AM
*To:* ips@xxxxxxxx
*Subject:* Re: Response Fence Flag
Not really. Current draft text is intentionally written to not have
any dependencies on T10 dynamics. The point is that iSCSI needs such
a notion for succinctly describing the proper iSCSI protocol actions
in a few places - ACA, TMF, Persistent reserve/Abort to name a few.
We certainly hope it will be approved by T10 and be a part of SAM-4
soon, but that isn't required per se for describing what iSCSI needs
for its correct behavior.
IPS WG has adopted what it needs in the past - staying ahead of T10
review/approval cycle if necessary. I_T nexus loss notification,
iSCSI target/port naming, clearing effects are a few I recall.
Mallikarjun
----- Original Message ----
From: Eddy Quicksall <Quicksall_iSCSI@xxxxxxxxxxxxx>
To: Robert Snively <rsnively@xxxxxxxxxxx>; "Elliott, Robert (Server
Storage)" <Elliott@xxxxxx>; ips@xxxxxxxx
Sent: Friday, January 5, 2007 8:58:47 AM
Subject: Re: Response Fence Flag
From an earlier email I think that Response Fence is only a proposal
in T10 (http://www.t10.org:80/doc06.htm
<http://www.t10.org/doc06.htm>). If so shouldn't iSCSI wait a bit
until this has been ratified?
Eddy
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
------------------------------------------------------------------------
_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips
