Re: [Ips] iSCSI-specific unit attention conditions

Julian Satran <Julian_Satran@il.ibm.com> Sat, 04 April 2009 18:15 UTC

Return-Path: <Julian_Satran@il.ibm.com>
X-Original-To: ips@core3.amsl.com
Delivered-To: ips@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62E953A6A6D; Sat, 4 Apr 2009 11:15:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.44
X-Spam-Level:
X-Spam-Status: No, score=-5.44 tagged_above=-999 required=5 tests=[AWL=1.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sCCyM7OjRBC; Sat, 4 Apr 2009 11:15:32 -0700 (PDT)
Received: from mtagate1.de.ibm.com (mtagate1.de.ibm.com [195.212.17.161]) by core3.amsl.com (Postfix) with ESMTP id 484DD3A6A06; Sat, 4 Apr 2009 11:15:31 -0700 (PDT)
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.1/8.13.1) with ESMTP id n34IGVtI010369; Sat, 4 Apr 2009 18:16:31 GMT
Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n34IGVi83076342; Sat, 4 Apr 2009 20:16:31 +0200
Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n34IGVkL013433; Sat, 4 Apr 2009 20:16:31 +0200
Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n34IGVqP013430; Sat, 4 Apr 2009 20:16:31 +0200
In-Reply-To: <000001c9b4ee$a73e3da0$f5bab8e0$@com>
References: <18899.36208.525150.683459@pkoning-laptop.equallogic.com> <AC32D7C72530234288643DD5F1435D530445C9AB@RTPMVEXC1-PRD.hq.netapp.com> <948E73819E6E494394157AD8A890E8774E3A3054@saturn.p3corpnet.pivot3.com> <948E73819E6E494394157AD8A890E877405C31C1@saturn.p3corpnet.pivot3.com> <000001c9b4ee$a73e3da0$f5bab8e0$@com>
To: BillG@breatech.com
MIME-Version: 1.0
X-KeepSent: 02E6844A:960EF36C-C225758E:0062068D; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5 December 05, 2008
From: Julian Satran <Julian_Satran@il.ibm.com>
Message-ID: <OF02E6844A.960EF36C-ONC225758E.0062068D-C225758E.006462F4@il.ibm.com>
Date: Sat, 4 Apr 2009 21:16:29 +0300
X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.0.1|February 07, 2008) at 04/04/2009 21:16:30, Serialize complete at 04/04/2009 21:16:30
Content-Type: multipart/alternative; boundary="=_alternative 0064605FC225758E_="
Cc: ips@ietf.org, ips-bounces@ietf.org
Subject: Re: [Ips] iSCSI-specific unit attention conditions
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ips>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Apr 2009 18:15:34 -0000

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

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