RE: iSCSI Naming: WWUIs, URNs, and namespaces

[Black_David@emc.com]

Marj,

> > 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 :-)).
> 
> 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.

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
> 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???

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
---------------------------------------------------
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
---------------------------------------------------