Re: iSCSI Naming and Discovery

[David Robinson <David.Robinson@EBay.Sun.COM>]

[Be out sick for a day and see all the fun you miss! :-) ]

In reading through this thread I see arguments on both
sides that seem to muddle together the issues of establishing
connections versus using an existing connection.

1) I think that it is required that once a connection is established
there is no external service that is required to be operable in order
to allow commands and data to flow between target and initiator.
I hope there is universal agreement on that.

2) Naming once a connection is established is how to
name and access the subcomponents underneath the IP address port
number pair. I can see two approaches to this, the first is to
keep the information local to the target and it is fetched
in response to some SCSI command (e.g. a mode page or inquiry)
or to use an external repository to store the information.  In
the latter case there needs to be a mechanism to keep the local
mapping and repository in sync, however in the former case you still
need to find the IP/port pair (see next section) which involves
syncronization.

3) In order to establish the connection there must be a mapping
from some service level name into an (IP address, port) pair.
I assert that within the iSCSI transport the service level naming
never appears (I am ignoring 3rd party transfers for now). Thus
using some sort of URL like name as part of a connection login
is redundant information, the target doesn't need to be told who
it is.  All that is needed is the information described in 2) to
determine which subcomponent behind the port that needs to be
accessed. It is however important that we standardize how the service
is named and how it is resolved into an IP address and port number.
DNS is commonly used for the name to IP mapping function so it
might be used for all or part of the resolution, however the name
is likely to address lower level constructs which LDAP is much
better suited.  Whether it is one name service or a two in combination
I don't know.  But the boot issue is a false issue.  If we agree
that 1) above is true, then either placing the resolution of
the service address to IP/port pair into NVRAM or use a boot
service to return it makes it a non-issue.  No external nameservice
is needed to establish an initial connection to storage on boot.
As examples, most x86 BIOS allow you to specifiy C: or D: as the
boot devices, likewise OpenBoot stores the boot device as a string
in NVRAM.

So I see the WG needed to resolve two independant issues, the first
is how to name a sub-unit at login, the second is how to define
the service level name that resolves into an IP/port and what the
resolver is.  I think a URL is overkill for the former but might
be appropiate for the latter.

For third party transfers, we should just consider the target to
become the initiator and it passes either the resolved address
from 3) or the unresolved service name.

	-David