Subject: Re: [Ips] iSCSI-specific unit attention conditions

From: [email-masked]
Date: Wed, 1 Apr 2009 11:42:12 -0400

It seems to me that the more important question is how useful these unit 
attention codes are.  (For example, ATTO's Xtend San initiator doesn't 
make use of them.)  If initiators don't care about this information, 
precisely defining these unit attention codes (instead of depricating 
them) will be a change for the worse.

regards,

david

For every action there is an equal and opposite malfunction...

David J Cuddihy
Principal Engineer
ATTO Technology, Inc.
(716) 691-1999 x157 

www.attotech.com
Power Behind the Storage

"Knight, Frederick" <[email-masked]> 
Sent by: [email-masked]
03/31/2009 05:39 PM

To
<[email-masked]>, <[email-masked]>
cc
[email-masked], [email-masked]
Subject
Re: [Ips] iSCSI-specific unit attention conditions

"No commands are affected."

The command which receives this response is NOT executed, and must be
reissued by the initiator.  True, no command other than the one that
receives this response is affected.

My guess from reading 05-406 is that the target is simply telling the
initiator that it is time to reissue a SendTargets (redo discovery).  My
guess is that all 3 ASC/Qs would be handled by the host in the same way
- something change (ala RSCN), so go find out what.  I can't tell from
the proposal why there needs to be 3 different reports
(add/remove/change); it seems that "change" is really all that might be
needed.  So, it's possible my guess about the original intent is missing
something.

                 Fred 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, March 31, 2009 4:12 PM
To: [email-masked]; Knight, Frederick
Cc: [email-masked]; [email-masked]
Subject: RE: [Ips] iSCSI-specific unit attention conditions

Maybe this is obvious to the T10 folks in the audience, but . . . Since
these unit attentions use an ASC of 3F, they indicate a change to the
operating state of the device.  No commands are affected.  From the
concise wording of the 05-406 proposal, it's hard to be sure what the
author intended, but it sounds to me like the target is telling the
initiator about a change in the membership of the portal group.

Might be caused by a configuration change, possibly by hot-plugging
another network interface card into the target system. 

DJ Brown

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Koning
Sent: Tuesday, March 31, 2009 3:32 PM
To: [email-masked]
Cc: [email-masked]; Black, David
Subject: Re: [Ips] iSCSI-specific unit attention conditions

>>>>> "Frederick" == Frederick Knight <Knight> writes:

 Frederick> My interpretation of the "update" part of the agenda was
Frederick> that SAM-4 was an example (and that we should also include
Frederick> SAM-3 and SAM-5 as part of the update list).  Therefore,
Frederick> to add SPC to the update list is (in my opinion) within
Frederick> the scope for the SCSI Update portion of this project.

 Frederick> Yes, it should be included in the charter (either
Frederick> specifically, or by making clear the broader  Frederick>
interpretation of the "update").

Ok, that sounds good.

 Frederick> There is no person advocating these ASC/Q codes.  These
Frederick> are ALREADY APPROVED ASC/Q codes, and the person that
Frederick> caused them to become approved is no longer part of T10,
Frederick> nor is that company a part of T10 at this time, so it will
Frederick> be hard to find them and get them to do anything.

 Frederick> In my opinion, we should define their use, and let the
Frederick> e-mail reviews make sure we get it right (or as good as we
Frederick> can).  Partly because, contrary to the statement below,
Frederick> the causes of all unit attention conditions are not
Frederick> "clearly defined".

I was assuming the person doing the advocating would be the appropriate
one to do the defining.  If that person isn't around but someone else
wants to do the defining, that is fine, too.

Part of what bothers me is that I can't fathom what these codes are
intended for, or what the scenarios are when they might be generated, or
what conclusion an initiator is supposed to draw when it sees one.

The names vaguely suggest that they have something to do with
asynchronous logout, but that is already fully covered in the iSCSI
spec.  Itdoesn't require any unit attentions in the first place,
certainly not any iSCSI specific ones.

I would rather see these things go away, unless there is a good argument
made that there is something missing in iSCSI that needs to be added,
and these codes are part of the solution.  The fact that T10 already
approved them isn't a reason to add them to iSCSI.

                 paul

_______________________________________________
Ips mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ips

---

From: Paul Koning <[email-masked]>
Date: Wed, 1 Apr 2009 11:51:12 -0400

>>>>> "dcuddihy" == dcuddihy  <[email-masked]> writes:

 dcuddihy> It seems to me that the more important question is how
 dcuddihy> useful these unit attention codes are.  (For example,
 dcuddihy> ATTO's Xtend San initiator doesn't make use of them.)  If
 dcuddihy> initiators don't care about this information, precisely
 dcuddihy> defining these unit attention codes (instead of depricating
 dcuddihy> them) will be a change for the worse.

That's one of my concerns.

It seems we're just speculating what purpose these codes were intended
to serve.  Not only don't we know for sure what that purpose was, we
also don't know if that purpose is actually achieved.

The other concern is that these codes could be interpreted to impose a
new requirement on targets to generate them in certain situations.  Of
course we don't know what those situations are, or why targets should
do this, but clearly someone could argue that those numbers exist and
therefore are supposed to be generated.

Unless there is a solid proposal that assigns a clear meaning, and
that meaning is valuable to initiators, I believe that the only
correct answer is to consider what happened as a glitch in the
standards process and remove, to the extent possible, the debris left
behind by that glitch.

I don't see anything in the recent discussion that gets us to this
clear meaning and useful purpose.  In particular, I see absolutely NO
trace of "rough consensus and running code" to support the notion that
the iSCSI standard should support these new codes.

David, can we put in motion the deprecation of these codes?

       paul

---

From: "Knight, Frederick" <[email-masked]>
Date: Wed, 1 Apr 2009 12:23:22 -0400

I've tracked down the people involved in the original 2005 T10 proposal,
and I will try to get them involved (if I can't, I'll at least share
what I discover).

T10 will be reluctant to retire these values if they are in use. 

As mentioned, the use we see for the "ADDRESS CHANGED" event is to cause
a new discovery process to be initiated (to go find any changes).

	Fred

-----Original Message-----
From: Paul Koning [mailto:[email-masked]] 
Sent: Wednesday, April 01, 2009 11:51 AM
To: [email-masked]
Cc: Knight, Frederick; [email-masked]
Subject: Re: [Ips] iSCSI-specific unit attention conditions

       paul

---

From: <[email-masked]>
Date: Fri, 3 Apr 2009 21:05:27 -0500

Fred, 

	Whether in use or not, in my ten years of doing T10, I have
never seen an ASC/Q go obsolete.

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Knight, Frederick
Sent: Wednesday, April 01, 2009 11:23 AM
To: Koning, Paul; [email-masked]
Cc: [email-masked]
Subject: Re: [Ips] iSCSI-specific unit attention conditions

	Fred

-----Original Message-----
From: Paul Koning [mailto:[email-masked]] 
Sent: Wednesday, April 01, 2009 11:51 AM
To: [email-masked]
Cc: Knight, Frederick; [email-masked]
Subject: Re: [Ips] iSCSI-specific unit attention conditions

       paul

---

From: [email-masked]
Date: Fri, 3 Apr 2009 23:19:26 -0400

If retirement is in order, renaming the to-be-retired codes as
vendor-specific to protect their existing usage may suffice.

I believe the original proposer of these codes will be sending
a message to this list to explain what the codes were intended
for and why.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Friday, April 03, 2009 10:05 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]

---

From: "Bill Galloway" <[email-masked]>
Date: Sat, 4 Apr 2009 01:29:03 -0500

This is a re-send from a different email.... 

I am the guilty party associated with these sense codes.  I have been
traveling for the last few days or I would have chimed in sooner.  My
original proposal was not iSCSI specific.  It added three ASC/ASCQs which
were DEVICE PORT ADDRESS ADDED/CHANGED/REMOVED. The original names actually
explain the intent better (IMHO).

We produce an iSCSI target with many "Portal Groups" and "Network Portals".
Portal Groups come and go dynamically. Within a Portal Group, Network
Portals come, go, or change dynamically.  The intent is for the initiator to
be connected to all Network Portals, on all Portal Groups, all of the time.
This is usually accomplished with some combination of MCS in the initiator
and a MPIO (multipath) layer above the initiator.  The initiator is
perfectly willing to make all of these connections but there is no way
specified in any standard to accomplish this task.  There is a mix of layers
here that makes for a messy solution.  I am certainly open to a better one.

The SCSI layer could care less about Network Portals coming, going, or
changing but something has to kick the initiator to do a new discovery and
make the appropriate connections.  This would have been better handled at
the iSCSI layer but I could find nothing available.  In our implementation
the MPIO layer traps these UAs and kicks the initiator.

The SCSI layer does have a legitimate need to know about Portal Groups
coming and going.  These map to SAM target ports and the SCSI layer may need
to know. The initiator also needs to know so that it can make the new
connections.  In our implementation the MPIO layer also traps these UAs and
kicks the initiator.

Why three codes? No good reason.  My first proposal was more generic than
iSCSI and there was a hope that it would be useful to other protocols.  To
get the proposal passed, I agreed to change the names to be iSCSI specific.
In retrospect when I made the name change, I could have dropped it to one
code.  In our current implementation we treat all codes the same.

I hope this explains the rational for these ASC/ASCQs.  I am not aware of
anything in the iSCSI spec that accomplishes these goals. I am certainly
willing to explain further and to work with STORM to document this better
and/or come up with a better solution.

Bill Galloway
Pivot3, Inc.
BillG[-at-]Pivot3.com

---

From: Julian Satran <[email-masked]>
Date: Sat, 4 Apr 2009 21:16:29 +0300

[email-masked] wrote on 04/04/2009 09:29:03:

> From:
> 
> "Bill Galloway" <[email-masked]>
> 
> To:
> 
> <[email-masked]>
> 
> Date:
> 
> 04/04/2009 20:39
> 
> Subject:
> 
> Sent by:
> [email-masked]

The first reaction to your note would be probably that you are right - 
SCSI is probably the wrong layer to make initiators aware of the existence 
of a new port.
On the other hand any transport than has no "permanent session" (in a 
generic sense) would have a hard time handling it.
And even worse - if the target is connected through different transport to 
the same or different initiators which one of the transports should carry 
it (think only about a FCP target that has an iSCSI backup - a not 
entirely imaginary scenario)?

And the ugly part about doing it with UA is that you kick in a recovery 
process that might be non-trivial.

The cleanest solution (for iSCSI) is to relegate the discovery (and 
change) to an out of band mechanism (as I have advocated for a long time). 
The drawback is that all the available out-of-band mechanisms are heavy 
and quite expensive (this is not to be considered a critique - it is just 
a statement of fact). Alternatively we could choose to handle the iSCSI 
case exclusively and use a version of one of our messages to convey the 
change. It will not handle all the cases (as the above FCP - iSCSI mix) 
but will perhaps solve Bill's problem.

Alternatively we might try and persuade T10 (SCSI) do adopt an "in-band" 
mechanism to prompt (re) discovery that should not carry the UA weight in 
most of the cases and then make the codes obsolete if the cease to be 
useful and/or extend them to other transports.

The last alternative is to mandate that configuration changes of this type 
can be made only outside a session - that will require us to use only a 
change bit from session to session (or login key) to indicate a change or 
unknown state since last discovery.

Julo

Julo

---

From: Ralph Weber <[email-masked]>
Date: Sat, 04 Apr 2009 17:25:13 -0500

Kevin,

I suspect you will not see any ASC/Q codes going Obsolete
(or Vendor Specific) this time either.

My opinion is that the original assertion (i.e., that the
definition of an ASC/Q in SPC-x somehow obliges some standard
to define a usage for that value) will not pass muster with
the majority of the CAP working group.

I would not be surprised to find that more than 25% of the
currently defined ASC/Q values have no explicit mention in
any existing standard or working draft. I do not recall
Bill's proposal promising any such in-standard definition.
At the time Bill presented his request, the sense of CAP
favored defining ASC/Q values to provide useful information
(within reason, of course).

Clearly, CAP felt that Bill's request had merit. As of
yet, I have not heard (or read) sufficient justification
for reversing that action.

All the best,

.Ralph