RE: iSCSI: ISID issue

["Jim Hafner" <hafner@almaden.ibm.com>]

David,

I think your list of why we want ISIDs is missing some things (or perhaps
I've forgotten why they we're dropped from the list before).  But I'll take
a different tact.

My point is not to fixate on the ISID itself.  My point general point is
that I believe we need to have an unambiguous identifier of the SCSI
initiator port.  This is for reasons of
(a) persistent reserverations (as defined today) as well as for future
extensions
(b) there is an obligation today (I think) for the transport layer to
present to the OS layers above a "picture" of the SCSI Initiator Ports
(isn't that what you keep saying goes in /dev stuff?).   Wedge drivers rely
on this stuff too.
(c) some access control stuff (as defined by T10) but this is not a hard
requirement

I don't find the "Target gives the ports names" as meeting the needs listed
here (and I don't think it makes any sense from a model point of view
either).

One solution to this (which it sounds like you find acceptable) is the one
I've tossed on the table before:  every iSCSI Node is single ported and
you're back in the FC management headache space for target access control
configuration.

But you argue this is acceptable because that's what FC does and as long as
the implementation model is the same for everybody, it's easier.  You argue
that the direction we're going will make this much harder in iSCSI (you're
'that depends' remarks).  But aren't we going to have that anyway, as not
all systems will run HBAs of the same caliber?  We'll have some purely
software iSCSI drivers using generic nics, we'll have some purely software
iSCSI drivers bound to specific nics, we'll have some SW/HW driver combos
bound to TOEs, and some bound to iSCSI HBAs.  Each will have a different
infrastructure for even the iSCSI Names.   It will be a very long time (if
ever) where we have the "single instance of the protocol for management
purposes" you allude to as good about FC.

If you want to avoid the multiple 'names' management problem per OS image,
then you have to have names for SCSI Ports derived from (by appending)
something else.   I frankly don't care what it is, but I've argued that the
ISIDs are already there in the spec, so why not use them.  However, perhaps
because some feel that the ISID is closer to a dynamic pointer, we should
move off it for the purposes of naming SCSI ports.  It doesn't really
matter.  Given any name, it use has to be coordinated within the scope of
the iSCSI node, period.

In either case (one port per node OR many ports per node) you still have
the OptionA/OptionB problem in that you still have to define a rule that
says the same SCSI Initiator Port can't build more than one session to the
same SCSI Target Port (Target portal group)   AND you need an enforcement
of that by the target (option A or B).

Perhaps in the one port per node model, it is much less likely for this
RULE to be broken, so the consequences are less severe.

It looks to me like the trade offs boil down to
(a) managing a complex set of iSCSI Names (both detection in the OS and for
target access control configuration) [and I've argued that detection is not
as simple as FC, where even there, discovery took many years just to get a
common API to the drivers!]
OR
(b) finding a way to get name coordination (both iSCSI Name and Portname)
within an OS [and you've argued that this isn't going to happen.]

Does this encapsulate things more clearly (at least between us)?

I have a few other nits on some of your comments below, but I don't think
they'd help change any opinions.

Jim Hafner


Black_David@emc.com on 10/03/2001 12:23:42 pm

To:   Jim Hafner/Almaden/IBM@IBMUS
cc:   ips@ece.cmu.edu
Subject:  RE: iSCSI: ISID issue



I'm getting ready to give up on this due to lack of interest on the list.
As near as I can tell the arguments in favor of ISIDs are:

(1) They've been in the spec for a long time.
(2) Provide symmetry in session identification and a clean mapping to SAM-2
     concepts.
(3) Accommodates possible future persistent reserve functionality.

Of these, I regard (1) and (2) as weak, and will explain in a moment
why (3) is incorrect as things currently stand.

The arguments against are:

(4) ISID existence is the direct cause of the Option A/Option B issue
     about whether setting up a connection with an existing ISID is
     supposed to blow away an existing connection with the same ISID.
(5) The ISID rule does not appear to be uniformly implementable in practice
     on common OS platforms via means other than (error-prone) manual
     configuration.  The whole notion that OS vendors will address this
     sort of allocation issue just because we think they should is an
     exercise in wishful thinking.
(6) Argument (3) above is incorrect, as the possible future persistent
     reserve functionality will not work as expected when different
     ISID values are used by the same Initiator to access Targets or
     Target Portal Groups for which sharing of persistent reserves is
     desired.

To correct the problem with (3), we would have to require that the same
ISID values be used across all Targets that may share an LU, which in
practice probably means all Targets as the LU sharing structure across
Targets is unlikely to be visible to iSCSI.  I hesitate to write such
a rule into iSCSI now to anticipate functionality that is still in a
"to be defined" state at T10, because it will impact implementations.

Julian and Jim's comments on specification of LU mapping miss the point.
The point is that really simple consistent rules for how things work at
this basic level are necessary to get management that scales decently.

To be specific, suppose I have a reasonable sized SMP machine that has
5 Ethernet ports that support iSCSI spread across 3 HBAs and two drivers
- how many iSCSI Initiator Names have to be configured into a Target LUN
masking implementation to give that machine access to its storage from
all 5 ports?

The iSCSI answer is a long version of "it depends" that starts with "find
the iSCSI documentation for your host and each of the HBAs to see how each
of them deal with iSCSI Initiator Names".  The possible values probably
range from 1-3.  In contrast, the corresponding Fibre Channel answer of 5
(Port WWN for each FC port) is superior even though it's a larger number
because it's the only possible answer and all the HBAs have to work the
same way.  The reason it's superior is that neither the management software
programmers nor the system administrators have to spend any mental cycles
having to think about instances of the same protocol that have to be
administered differently.

For iSCSI, the ideal answer to the above question is 1.  IMHO, removing
ISIDs
visibly increases the likelihood of that actually being the case all the
time
in practice.  Alternatively, if we leave ISIDs in, I'd want to see a hard
look at how to toughen the current ISID rule to prevent the problem
identified
in (6), and even then, I think the result is still less likely to lead to
the desired goal.

I think part of the difference I have with Jim Hafner is that I think he
wants to make it possible for the future target-spanning persistent
reservation functionality to work without requiring that it work (i.e.,
it'd be ok to have initiators behave in a way that reservations never
span targets, even when targets implement the new functionality).  I
don't think that's good enough - if we go to the trouble of enabling
this, we should do so in a fashion that is guaranteed to work in
the presence of target support for the feature.

As I said, I'm getting ready to give up on this, because I don't see much
in the way of appreciation of the importance of scalable management and
the role of simplicity (in the extreme) in enabling it on the list.

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


> Let me just reiterate more strongly Julo's comment "we may request the LU
> mapping - for  iSCSI - be defined only by the InitiatorName".
> T10 has approved use of the iSCSI InitiatorName as the "TransportID" for
> SCSI access controls (lu mapping).  The portnames have no direct function
> in this context for iSCSI (though they do have an indirect affect that
> isn't worth discussing here).
>
> Whether this standardized approach to lu mapping is adopted by vendors is
a
> different question, but the standard is there.
>
> The issue of port name/identity is primarily an issue for persistent
> reservations (in all its current and future forms).
>
> Jim Hafner
>
>
> Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 10/03/2001 10:20:53 am
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   "ERICKSON,SHAWN (HP-Roseville,ex1)" <shawn_erickson@hp.com>
> cc:   "'Black_David@emc.com'" <Black_David@emc.com>, ips@ece.cmu.edu,
>       owner-ips@ece.cmu.edu, santoshr@cup.hp.com
> Subject:  RE: iSCSI: ISID issue
>
>
>
>
> I agree that LU mapping might be tricky but topology mapping is not
> affected by ISID allocation. You have to get a consistent
> mapping of target
> ports (and the model does that) and Initiators that know how to reach
> targets. Initiators have to know the physical identity of the
> portal when
> they open the connection (or they can get it through a local
> service) and
> the ISID has no role in topology mapping.
>
> I would also say that for any practical purpose we may request the LU
> mapping - for  iSCSI - be defined only by the InitiatorName
> part of the
> InitiatorPortName.
>
> Julo
>
>
>
>
>                            "ERICKSON,SHAWN
>
>                            (HP-Roseville,ex1)"
> To:
>                            <shawn_erickson@hp.com>
> santoshr@cup.hp.com,
>                            Sent by:
> ips@ece.cmu.edu
>                            owner-ips@ece.cmu.edu
> cc:
>
> "'Black_David@emc.com'"
>                            02-10-01 19:25
> <Black_David@emc.com>
>                            Please respond to
> Subject:
>                            "ERICKSON,SHAWN          RE:
> iSCSI: ISID issue
>                            (HP-Roseville,ex1)"
>
>
>
>
>
>
>
>
> > -----Original Message-----
> > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > Sent: Monday, October 01, 2001 3:11 PM
> > To: santoshr@cup.hp.com; ips@ece.cmu.edu
> > Subject: RE: iSCSI: ISID issue
> >
> >
> > Santosh Rao wrote:
> >
> > > I think comparisions to FC's mess-up of the node WWN are
> > not fair to the
> > > current ISID rule, since, unlike in FC, the worst case
> > scenario with the
> > > ISID rule, is that each iscsi driver on the system will take up a
> > > different iscsi initiator name.
> >
> > At least FC had the Port WWN to fall back on.  This is headed for a
> > situation
> > where the iSCSI Initiator Name is unusable for access control
> > configuration
> > because whether it corresponds to the network interface, the
> > HBA (e.g.,
> > suppose
> > there are two interfaces on the HBA), the driver, or the OS image is
> > implementation-dependent.  In FC it is completely
> unambiguous what the
> > Port WWN corresponds to, and that's why it's usually used for
> > LUN masking
> > and mapping solutions.  We're at risk of screwing that up, e.g. ...
>
> I would like to second David's concern about not leaving
> targets with a
> deterministic way of knowing who/what the initiators
> identifier relates to.
> This is not only bad for access control mechanisms but it
> make topology
> mapping (and related concepts) more difficult for management software
> developers.
>
> -Shawn
>
> -------------------------------------------------------
> Shawn Carl Erickson           (805) 883-4319 [Telnet]
> Hewlett Packard Company         OV NSSO Joint Venture
>  Storage Resource Management R&D Lab (Santa Barbara)
> -------------------------------------------------------
>            <http://ecardfile.com/id/shawnce>
> -------------------------------------------------------
>
>
>
>
>
>