Subject: [Ips] target portal discovery using iSNS versus SendTargets

From: "Paul Hughes" <[email-masked]>
Date: Tue, 5 Jun 2007 11:26:02 -0600

I am concerned that an iSCSI initiator that uses iSNS might not discover
all portals of an iSCSI target in some situations.  For example, if the
target has registered for ESI monitoring of its portals and the iSNS
server loses access to one portal the iSNS server will de-register the
inaccessible portal.  During this time if an SCSI initiator queries the
iSNS database for the target's portal addresses it will see only those
portals that are accessible to the iSNS server even though the initiator
may have access to all portals.
 
On the other hand, if the iSCSI initiator used iSNS to obtain one target
portal address and then issues SendTargets it would discover all of the
portals.  This of course assumes that an iSCSI target should report all
of its portals in the SendTargets response regardless of whether the
target has knowledge that one of its portals is inaccessible due to a
portal hardware failure.
 
I guess what I'm trying to determine is whether iSCSI initiators are
expected to query the iSNS database to detect the addition of target
portals or whether they only query the iSNS database once during boot or
driver initialization.  Does anyone have any experience with some of the
more popular iSCSI initiators to comment on this?
 
Thanks,
Paul
 
_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: Joe Souza <[email-masked]>
Date: Thu, 7 Jun 2007 16:27:30 -0700 (PDT)

Hi Paul,

I see one flaw with your proposed method.  As you know, if an iSNS server does not receive a response to a certain number of ESI requests, that ESI-registered Portal will be deregistered from the iSNS database.  If, however, that Portal was the last remaining Portal in a given Entity (or i.e. the only Portal in that Entity), then the entire Entity will be deregistered.  In that case, you would want to specify more than just the affected Portal's attributes in the DevAttrReg message, as the other objects and related attributes of that Entity may have already been deregistered from the iSNS server.  A better approach, if your ESI-registered Portal has not received an ESI request from the iSNS server in a time period greater than the ESI Interval (or has not been able to successfully respond to such requests), would be to reissue the complete registration request for the entire Entity.  Of course, if you know that you have at least one additional ESI-registered Portal in that
 Entity that has been receiving and responding to ESI requests on a regular basis, then you can assume that the registration for the Entity is still active, and then your approach of reregistering just the Portal in that Entity (specifying the EID as the registration key) should work for you.

-Joe

----- Original Message ----
From: Paul Hughes <[email-masked]>
To: Joe Souza <[email-masked]>; [email-masked]
Sent: Thursday, June 7, 2007 7:51:52 AM
Subject: RE: [Ips] target portal discovery using iSNS versus SendTargets

DIV {
MARGIN:0px;}

Thanks Joe.

Your comment about the initiator being prudent and 
registering for SCNs makes sense.  I assume that an initiator that 
uses iSNS to discover targets will register for 
target-related SCNs.

By the way, what is the preferred method for a 
target to re-register a portal that has been de-registered by the server due 
to ESI failures?  I was thinking the target could periodically 
send a DevAttrReg message from the portal that has lost access to the 
server until the registration succeeds.  This DevAttrReg 
message would contain only the 
inaccessible portal's attributes and have the replace flag set to 
false.  This seems to be more reasonable than having some other target 
portal re-register the inaccessible portal only to have it de-registered again 
when ESI fails (assuming that access has not been 
restored).

Thanks,

Paul

From: Joe Souza [mailto:[email-masked]] 

Sent: Tuesday, June 05, 2007 1:19 PM
To: Paul Hughes; 
[email-masked]
Subject: Re: [Ips] target portal discovery using iSNS 
versus SendTargets

One 
question I have is that if the iSNS server is likely to lose access to a portal 
on an iSCSI target, isn't it also likely that an iSCSI initiator will also lose 
access to that same portal?  In that case, the iSNS server would be 
behaving correctly to deregister the unreachable portal.

Use of ESI by 
iSNS clients is optional.  If you don't wish the iSNS server to depend on 
your target portal's accessibility via ESI, you could instead proactively 
transact with the iSNS server before your Registration Period has expired.  
A transaction received by the iSNS server from a registered iSNS client will 
serve to refresh that client's registration.  You would of course need to 
repeatedly transact with the iSNS server at a time interval less than the 
client's Registration Period in order to maintain the client's registration in 
the database, unless you are using ESI instead (an ESI response received by an 
iSNS server from a registered iSNS client will also server to refresh that 
client's registration).

Finally, it would be considered prudent for iSNS 
clients to register for SCNs to be notified whenever there are changes made to 
registered iSNS clients that the iSNS client is interested in.  For 
example, an iSCSI client may wish to be notified whenever changes are made to 
iSCSI targets (which are registered with the iSNS server), and likewise, iSCSI 
targets may wish to be notified whenever changes are made to iSCSI clients 
(which are registered with the iSNS server).

----- 
Original Message ----
From: Paul Hughes <[email-masked]>
To: 
[email-masked]
Sent: Tuesday, June 5, 2007 10:26:02 AM
Subject: [Ips] target 
portal discovery using iSNS versus SendTargets

I am concerned that 
an iSCSI initiator that uses iSNS might not discover all portals of an 
iSCSI target in some situations.  For example, if the target 
has registered for ESI monitoring of its portals and the iSNS 
server loses access to one portal the iSNS 
server will de-register the inaccessible portal.  During 
this time if an SCSI initiator queries the iSNS database for the target's 
portal addresses it will see only those portals that are accessible to the 
iSNS server even though the initiator may have access to all 
portals.

On the other hand, 
if the iSCSI initiator used iSNS to obtain one target portal address and then 
issues SendTargets it would discover all of the portals.  This of 
course assumes that an iSCSI target should report all of its portals in the 
SendTargets response regardless of whether the target has knowledge that one of 
its portals is inaccessible due to a portal hardware 
failure.

I guess what I'm 
trying to determine is whether iSCSI initiators are expected to query the iSNS 
database to detect the addition of target portals or whether they only query the 
iSNS database once during boot or driver initialization.  Does anyone 
have any experience with some of the more popular iSCSI initiators to comment on 
this?

Thanks,

Paul

Ips mailing 
list