RE: target portal discovery using iSNS versus SendTargets

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 protected]] 
Sent: Tuesday, June 05, 2007 1:19 PM
To: Paul Hughes; [email protected]
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 protected]>
To: [email protected]
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
[email protected]
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips