RE: iSCSI: Wrapping up SendTargets

[Black_David@emc.com]

> Before you or anyone calls consensus, I would like to see
> how SLP can solve the following issues:

Some of this was covered in:

http://ips.pdl.cs.cmu.edu/mail/msg04812.html

So, some short answers here ...

> 1)  Management of Discovery Domains.  You don't want
> incompatible file systems discovering each other, or
> very bad things will happen.  Say 'goodbye' to the Unix
> file system who's host is discovered by SLP....

Management at the DHCP server of which SLP
scope(s) each system gets configured with.

> 2)  Transfer of X.509 digital certificates.  SLP cannot
> easily transfer binary entities.  This affects the iSCSI
> target device's ability to enforce its access control list.

I'm not sure that having yet another protocol
and server involved in security administration
is a "feature", let alone a "requirement".

3)  Monitoring of available devices.  SLP relies upon
service agents re-registering periodically, in order to keep
the freshness of its database entries.  But this leads to a
dilemma: if SA's re-register too often, the DA will be
overwhelmed.  And if they register not often enough, then
you will have stale device entries.  The fact is, SLP was
not designed to be a real-time discovery protocol. But in
storage networks, real-time information is crucial, as even
slightly out-of-date information can lead to unnecessary
logins and other events that will seriously degrade the
performance of the storage network.

These time periods are measured in minutes,
which doesn't sound like a scaling issue.
I'm sceptical that this is actually a problem
in practice, as something doing failover
(e.g., cluster software) will tend to have
its own mechanism to detect failure (e.g.,
what if the storage fails, but the controller
is still happily responding to iSNS polls?).

4)  State Change Notifications.  This is important to
support failover and redundancy capabilities, and to
ensure that initiators can persistently maintain their
sessions with targets in the event of network topology
changes.

On this one, Josh is correct, especially about
discovery of new targets.  More and more OS's
can cope with this happening after boot, and
I believe HP-UX is among them ;-).  Being
able to hook up a new target and have it
automatically discovered by the corresponding
initiators could be very useful.

This is for further discussion.

Comments?,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------