Re: [Ips] iSCSI-specific unit attention conditions

[Julian Satran <Julian_Satran at il.ibm.com>]

ips-bounces at ietf.org wrote on 04/04/2009 09:29:03:

> From:
> 
> "Bill Galloway" <BillG at breatech.com>
> 
> To:
> 
> <ips at ietf.org>
> 
> Date:
> 
> 04/04/2009 20:39
> 
> Subject:
> 
> Re: [Ips] iSCSI-specific unit attention conditions
> 
> Sent by:
> 
> ips-bounces at ietf.org
> 
> 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
> 
> _______________________________________________
> Ips mailing list
> Ips at ietf.org
> https://www.ietf.org/mailman/listinfo/ips

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