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, 04 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
- [Ips] iSCSI-specific unit attention conditions Black_David
- Re: [Ips] iSCSI-specific unit attention conditions Paul Koning
- Re: [Ips] iSCSI-specific unit attention conditions Black_David
- Re: [Ips] iSCSI-specific unit attention conditions Paul Koning
- Re: [Ips] iSCSI-specific unit attention conditions Paul Koning
- Re: [Ips] iSCSI-specific unit attention conditions brown_David1
- Re: [Ips] iSCSI-specific unit attention conditions Knight, Frederick
- Re: [Ips] iSCSI-specific unit attention conditions Knight, Frederick
- Re: [Ips] iSCSI-specific unit attention conditions dcuddihy
- Re: [Ips] iSCSI-specific unit attention conditions Paul Koning
- Re: [Ips] iSCSI-specific unit attention conditions Knight, Frederick
- Re: [Ips] iSCSI-specific unit attention conditions Kevin_Marks
- Re: [Ips] iSCSI-specific unit attention conditions Black_David
- Re: [Ips] iSCSI-specific unit attention conditions Bill Galloway
- Re: [Ips] iSCSI-specific unit attention conditions Julian Satran
- Re: [Ips] iSCSI-specific unit attention conditions Ralph Weber