RE: iSCSI Naming and Discovery

["Douglas Otis" <dotis@sanlight.net>]

Costa,

You are inventing yet another server.  You already have DHCP that handles
such things. You broadcast the request, the routers help, and you get the
answer.  I doubt you will see such assistance for any new server that does
only some new protocol.  We should work at reducing the number of servers
that will need to be present within an enterprise.  DHCP is already present
and can handle this function.  Stop there.  Your done.

Doug

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> csapuntz@cisco.com
> Sent: Wednesday, October 04, 2000 10:03 AM
> To: Black_David@emc.com
> Cc: ips@ece.cmu.edu; csapuntz@cisco.com
> Subject: Re: iSCSI Naming and Discovery
>
>
>
> > - Scanning a range of possible locations of Targets has some attractive
> > 	properties, because it removes the obligation of a new target
> > 	to proactively make itself known to some iSCSI configuration
> > 	repository (such mechanisms do work, Fibre Channel is an example,
> > 	but the FC solution doesn't directly apply to iSCSI).  It seems
> > 	to me that wildcarding an IP address via a mask or range works
> > 	better than wildcarding some portion of a URL (e.g., if the
> > 	wildcard is xyz*.abc.com, there's a fair amount of work involved
> > 	in finding xyzf, xyz01, and xyz17a in the abc.com domain,
> > 	by comparison to finding things that match 192.48.27.128-191 or
> > 	equivalently 192.48.27.128/27).
>
> David,
>
> I do not believe that wildcarding is compelling.
>
> Scanning will be too slow. How many packets do you send to an IP
> address until you decide that it's not up? After how many seconds to
> you give up?
>
> If you want to discover who on your subnet speaks iSCSI, it'd be much
> better to use a subnet-local multicast (a multicast message that says:
> who speaks iSCSI?). If you're going across subnets, then it's probably
> time to use a directory service.
>
> -Costa
>