Subject: RE: iSCSI Naming: WWUIs, URNs, and namespaces

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Mon, 9 Apr 2001 19:17:59 -0700

How does this relate to URLs?  Does this mean we can't specify a URL format
for iSCSI resources?  Can you provide the logic behind the IESG pronouncing
that the IESG won't approve another global namespace?  It sounds like the
logic the TCP group used to reject the need for framing first time round("If
we allowed every yahoo that wanted changes to the TCP header, TCP wouldn't
be what it is today..")

Its not clear to me why the N&D group thinks iSCSI devices need globally
unique names.  It seems like a host name is unique enough, and behind that
it's up to the host to ensure uniqueness locally.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: [email-masked] 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 22, 2001 9:48 PM
> To: [email-masked]
> Subject: iSCSI Naming: WWUIs, URNs, and namespaces
> 
> 
> <RANT> I don't like naming issues. </RANT> :-) :-)
> 
> After suitable consulting with some members of
> the IESG and IAB, I have some news to convey about
> the current approach to iSCSI naming.
> 
> The IESG will not approve another global namespace
> for iSCSI's use - this means that WWUIs as currently
> designed will need to be revised out of the
> naming and discovery draft, and that it will not be
> possible to proceed with the WWUI URN draft
> as an official IPS WG work item.  The best course of
> action would probably be to allow the WWUI URN draft
> to expire without further revision.
> 
> To a first approximation, WWUIs are/were a "grand
> unified theory" of naming, in that any namespace could
> be glued into the WWUI world (as several were).
> The WG is being directed to instead focus on the
> individual namespaces and make sure that the ones that
> are used are in fact necessary.  iSCSI can use text
> keys to identify which sort of name is being used
> (one key for each sort of format, for each instance
> in which a name is used), and it may be possible
> to encode the name format in the parse rules for the
> values of iSCSI keys to avoid proliferation of keys.
> 
> Taking a look at the namespaces in the current iSCSI
> naming and discovery draft, here's some initial
> guidance from this WG co-chair:
>   iscsi - canonical target -- This should be fine.
>   eui - WWNs -- The use of these for storage makes eminent
> 	sense.  I don't see a problem here.
>   dns - hostnames -- Use of these should be abandoned as
> 	not only are they not really URNs (as indicated
> 	in the draft), but their intended usage is straying
> 	into the tarpit known as "URN resolution".  Faster
> 	progress will made by staying out.  A DNS hostname
> 	can be put into an Alias or something new can be
> 	invented to carry it as a Location Hint, BUT the
> 	relevant URN WG RFCs and drafts on URN resolution
> 	should be reviewed before proceeding too far in this
> 	direction.
>   iscsi - Reverse DNS and oui - Org. Unique Identifier --
> 	The rationale for these is not clear to me.
> 	Assuming that WWNs are going to be available for
> 	use in naming iSCSI Initiators and Targets, what
> 	are the problems that these sorts of names solve
> 	that WWNs don't?  It appears that one of the problems
> 	may be who can get/create them.  Discussion of this
> 	on the list would be appropriate.
> In any case, the fewer name formats we have to deal with,
> the better.
> 
> I want to try to anticipate an objection to this, which
> would note that from a functional viewpoint the basic
> impact of this is to move some characters from one text 
> string to another (e.g., from a WWUI type designator
> to part of an iSCSI text key), and wonder if this is
> a distinction without a difference.  One of the reasons
> for the <RANT> that started this post is that a functional
> view is not sufficient for naming - how things are named,
> the intended usage of names and their scope matter a lot.
> This is particularly true when considering the structure
> of a namespace and how that structure may be extended.
> The upshot is that avoiding introduction of something
> claiming to be yet another global namespace is important
> (i.e., use existing namespaces with global scope in preference
> to inventing new ones).  The resulting need to define
> the name spaces/formats in the main iSCSI spec. is
> probably a "feature" as it forces us to pay more
> attention to the sorts of names we use and raises the
> bar for adding additional sorts of names in the future.
> 
> I will be working with
> the naming and discovery team in my "copious spare time"
> to make sure that we don't lose the valuable work and
> progress they've made to date as a consequence of this
> change.  Discussion on the list about what sort
> of names are important (e.g., the Reverse DNS and OUI
> namespaces) and why would be useful. 
> 
> Thanks,
> --David
> 
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> [email-masked]       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>

---

From: [email-masked]
Date: Tue, 10 Apr 2001 13:18:05 -0400

Marj,

> that the IESG won't approve another global namespace?

Use of URLs is fine (existing namespace), as is use of URL format.  The word
"global" has a number of meanings - in this context it has to do with scope
and context, namely globally unique identifiers for anything on the globe
that
needs a unique identifier.  While it may not have been the intention to do
so, the WWUI approach leads to a new global naming framework.  The
IESG is saying "NO" to that sort of general framework in no uncertain terms
and asking the WG to focus on the storage naming problems we need to
solve and not go about defining a framework that is extensible to solve a
whole batch of other unrelated problems.

At the next level down, there are three sorts
of issues floating in here:
- Semantics: Unique identifiers, global scope,
	not tied to communication endpoints.
- Syntax: How those identifiers are represented
	in messages and related issues of control
	over use and extension of that representation
- Description: How the syntax is documented and
	the resulting suggestions/implications for
	its use.
To a first approximation, the above list is in
the order of importance to iSCSI (Semantics is
most important) and in REVERSE order of importance
to the IESG/IAB issues I've raised (i.e., the
biggest issues are with the Description, believe
it or not :-)).

Let me know if I need to explain more,
--David

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Tue, 10 Apr 2001 15:39:42 -0700

> biggest issues are with the Description, believe

I think I'm agreeing with the IESG then.  It appears that the N&D team has
somehow decided that globally unique identifiers are necessary and of
primary importance.  That doesn't make sense to me.  I think we should be
focusing on defining a URL format for iSCSI resources.  The host name
provides the level of uniqueness necessary to allow iSCSI to ensure further
uniqueness within that host.  I'm waiting to hear justification from the N&D
team regarding their focus???

Marjorie Krueger

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 11 Apr 2001 12:43:51 -0400

>  >The host name provides the level of uniqueness necessary            
>  >to allow iSCSI to ensure further uniqueness within that host.       
> 
> Not all iSCSI devices have a host name;  some use DHCP for IP address
> assignment, particularly initiators.  An initiator needs a name that is
> more unique than just within its host, so the target can identify it
> (imagine all the initiators named "WindowsLaptop"). 

My workstation uses DHCP to obtain an address, but it still has a hostname
that is unique.  That's the great thing about hostnames, they aren't
dependant on IP address - even when an initiator uses DHCP, it's hostname
stays the same.

If all the initiators are named "WindowsLaptop", that's an administrative
problem, not iSCSI's problem to solve.  The adminstrators have the means to
solve this problem - they do today for many other applications that use
hostnames to identify workstations.

> You could preconfigure the initiators with a primary hostname and a 
> backup hostname for the target, or use iSNS/SLP to learn its IP address.
>

I'm not sure what you are advocating here, Thomas.  IP hosts typically
already have a hostname configured, and their full host name is a product of
their domain.  For instance, my domain qualified hostname is
user55.rose.hp.com   It's unique enough for storage object naming purposes.
I don't see any reason for iSCSI to define a new (or multiple) hostnames for
initiators to use.

I wouldn't think this is an "either or" situation.  Defining hostnames
(initiator name) doesn't necessarily have anything to do with learning IP
addresses.  I'm concerned that the N&D team is inventing things that don't
need to be invented without understanding current IP practices.

Marj

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 11 Apr 2001 19:38:14 -0400

> >Are "initiators" being connected to actively by "targets"?
> >Via some call back or something?
> 
> Not that I know of.  The target has to map each initiator that is logging
> in to a particular SCSI resource (or set of resources), which may be
> different for each initiator.  For example, suppose you have an iSCSI
> target node with disk space carved up evenly between two users.  When you
> log in to that target, you want to be given access to your disk space
> allocation, not mine.  The initiator identifies itself to the target via
> the InitiatorWWUI text key of the Login.  The current spec  declares that
> InitiatorWWUI is globally unique, which makes this mapping easy.  If
> InitiatorWWUI is unique only within the initiator node, multiple initiator
> nodes can choose the same name (e.g., "WindowsLaptop").  We'll have to
> qualify it with something else to make it unique, at least to a target
that
> uses that name to look up the mapping.
> 

As previously discussed in this thread, your terminology is obsolete - the
IESG axed the use of "WWUI" and you should be referring to "initiator name"
and "target name" or genericly "storage node name".  You have not made a
case for a need for these names to be globally unique.

In any case, fully qualified host names *are* globally  unique, are already
a part of the IP protocols, and can be used as part of a URL syntax to
identify storage node objects.  You keep referring to "WindowsLaptop" as the
hostname, but that's only part of the hostname.  Are you familiar with IP
hostname constructs?

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 11 Apr 2001 16:19:43 -0700

Marjorie Krueger

> From: Douglas Otis [mailto:[email-masked]]
> Sent: Wednesday, April 11, 2001 1:44 PM
> To: Brian Pawlowski; Thomas McSweeney
> Cc: [email-masked]; [email-masked]
> Subject: RE: iSCSI Naming: WWUIs, URNs, and namespaces
> 
> 
> Brian and Marjorie,
> 
> There is a need to obtain iSCSI configuration information in 
> a generalized
> way.  This information should allow the client to find the 
> server using
> existing IP namespace information.  Forging connections 
> within the server
> must use normal SCSI naming appended in some manner to the IP 
> namespace.
> The SCSI naming should not be dereferenced to require an 
> additional name
> server.  DHCP provides a standard means of indicating the 
> location of LDAP.
> SLP also provides a standard means of locating LDAP.  There 
> is a standard
> alias convention of ldap.example.com of finding the LDAP 
> server and LDAP has
> be working with may security schemes for years.  Once an LDAP 
> schema is
> defined by the IPS group, then any Directory User Agent can obtain any
> auxiliary information without the need for yet another name server.
> 
> Marjorie had mentioned that some are considering XML to support this
> function.  You will need some way to find this service.  You will find
> little information regarding security and w3c.org conventions 
> for naming are
> system not public based as I had mentioned.  Security issues 
> regarding XML
> will be addressed.  Microsoft has announced their secure 
> version of NT (XP)
> will use XML to manage updates through third parties.  I bet 
> this will be as
> popular as Clippit.  With the desire to invent a new name server, XML
> namespace seems a likely bet.  It will be interesting to see 
> if all this can
> be made secure.  It is a goal of Microsoft obviously and will 
> keep w3c.org
> busy for many years.  It does seem rather bold to base 
> management on such
> new code for something so critical.
> 
> Doug
> 
> > Wait.
> >
> > I might be missing something here - I was doing a mental analogy
> > to NFS clients and servers - we had to come up with a server
> > name space, but the clients were initiating the mappings and
> > only had to be able to find file systems on servers (forming
> > an identifier).
> 
> 
>

---

From: [email-masked]
Date: Thu, 12 Apr 2001 04:24:25 -0400

Marj,

> primary importance.  That doesn't make sense to me.

Actually that's not the IESG/IAB concern.  If iSCSI needs globally unique
identifiers, that's ok, but we MUST not invent a new potentially
all-encompassing global namespace for them.  Reuse of existing
globally unique identifiers, like WWNs, is fine.

> I think we should be

Off the top of my head, this gets caught between the rock of parallel
sessions
on parallel network fabrics and the hard place of authentication.  Setting
up
parallel sessions requires naming the session endpoints explicitly to avoid
having the sessions cross-routed in a way that a single network device
failure
could take all of them out.  Authentication would like a single identity for
each side of the set of sessions to simplify identity management.  An
implicit
assumption in the parallel sessions scenario is that the ability to have
multiple TCP connections in a session is not sufficient for parallel multi-
path I/O - this is based on past discussions about concerns like CmdSN
sequencing for one session that is spread across multiple iSCSI HBA cards.

DNS works well for naming endpoints because one DNS name can resolve
to one IP address. Trying to kill both birds with one stone results in
needing
to resolve one DNS name to a set of IP addresses, which DNS isn't very
good at -- round-robin risks cross-routed paths, and if we insist on using
multi-homing, the network administration community will have
our heads.  This gets even worse if the parallel paths between Initiator
and Target aren't cross-connected (e.g., the interfaces on each side
are split across two parallel networks that aren't connected, or don't
have a routable connection between them due to VLAN configuration)
as this further complicates use of DNS by requiring something
encode this lack of connectivity to avoid any attempt to set up connections
where communication is impossible.  Hence it appears that something
else is needed to name targets and probably also initiators, at least
for authentication purposes.  The NDT folks will need to comment on
how they arrived at the "something else" they are recommending.

My 0.02,
--David

---

From: "Thomas McSweeney" <[email-masked]>
Date: Thu, 12 Apr 2001 11:12:34 -0400

Sorry for using obsolete terminology, but I feel uncomfortable using
anything but the latest published spellings for the text keys on the Login
Command.  If there is an updated copy of the spec available (more recent
than the -05 version), I'll go find it and use the corrected terms from it
in the future.

I know what DNS names look like, but I do I did a little experimenting with
my machine's host name.  I discovered that it does have one despite the
fact that I use DHCP - whoever installed Windows2000 must have typed in the
machine's serial number as the name (and set it to automatically append the
DNS suffix).  I tried to delete the name, but Windows2000 wouldn't let me.
I also learned that our DNS does not resolve that hostname to an IP address
-  I can't ping my hostname from anywhere, except from itself.  Finally, I
changed it to match the hostname of another machine in my office which does
not use DHCP, and rebooted.  It came up OK and connected to the net just
fine.  I'm not advocating this, in fact I quickly changed my hostname again
to make it unique (I agree that all fully qualified hostnames should be
unique).

This solidifies in my mind the difference between the iSCSI resource's name
and its location.  I don't object to using the hostname as (part of) the
iSCSI name (perhaps qualified with a locally-unique identifier of a
specific iSCSI resource), as long as the spec does not require an initiator
to find its target's location by passing the hostname portion of the iSCSI
name to a DNS.  It would be OK for an implementation to do such a location
lookup, but it restricts functionality (e.g., if the target is temporarily
moved to another host without being renamed, the initiator won't be able to
find it).  I think this is consistent with what David Black said in his
append.

Tom McSweeney
iSCSI Development, Storage Systems Group, IBM
Email: [email-masked]
Phone: (USA) 919-254-5634  (tie line: 444-5634)
Fax:   (USA) 919-254-0391  (tie line: 444-0391)