RE: iSCSI: ISID issue

[Black_David@emc.com]

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

> Given that all iscsi HBA vendors will need to have SOME host O.S. driver
> component which they will be writing, it is possible for them to hand
> out ISIDs to their adapters within their own driver domain. The ISID
> rule works fine as long as ISIDs are ditributed within the domain of
> each iscsi driver and since, the number of iscsi drivers supported on an
> O.S. are'nt going to be that large, I think, this is'nt as big an issue
> as FC's node name problems.(which scales linearly with the number of
> HBAs, not the number of drivers).

Actually it's worse because there isn't a single Initiator Name convention.
The only out I can see here is LUN masking/mapping configurations based on
IP addresses.  Simple stupid rules that ensure that everything works the
same way every time are necessary to make this sort of access control
mechanism useful (otherwise it will get misconfigured by a harried admin
who doesn't have the time to appreciate the subtlety of our discussions).

Jim Hafner wrote:

> First, the T10 folks are trying to come up with "additional and optional
> features" that would move in the diretion you're saying. That is partly to
> make the wedge-driver's job easier.  But that doesn't mean that iSCSI can
> ignore the current defined and well-understood model.  We have to live
with
> the current model AND see how what we do might affect (enable or prevent
> enabling) the new features.
> 
> Having the target provide the SSID, in my mind, will prevent the new
> features from being made available.

I worry that we're already in trouble with the new features.
In Parallel SCSI or Fibre Channel, ports are hardware entities and
exhaustive connection setup results in every Initiator Port being connected
to every possible Target Port, and the reservation spanning works, in part
because things like Unix /dev names are used to encode which Initiator
port was used.

At least as iSCSI currently stands, we're not in that situation because
ISID usage is implementation-dependent - if an Initiator chooses to never
reuse an ISID across all of its connections to all Target Ports, the result
is no reservation sharing.  That's permissible as things currently stand
and "will prevent the new features from being made available".  If I follow
Jim's line of reasoning, I think the result is "SHOULD use the same ISID
values
to connect to different Targets and Target Portal Groups" as a
recommendation
for boot and setup behavior so that the Ports behave in the same fashion as
existing SCSI Ports - one can then rebuild existing structures (e.g., /dev
names in Unix) on that base.

That seems like a change from what's been discussed - in essence, one or
a few ISIDs would get configured into each iSCSI implementation and all of
them would be exhaustively connected to every validly accessible (where
"validly"
is meant to encompass discovery scope restrictions) Target Portal Group on
boot.
How many current implementations are doing or anticipate doing that?  How
many
current implementations intend to set up multiple sessions (initially or for
error recovery) to the same Target Portal Group and hence need more than one
ISID?

One alternative would be to eliminate the ISID as a carrier of the Initiator
Port Name and assign that to a text key, which splits the issues of how to
provide support for this to be created reservation functionality from lower
level functional issues in the iSCSI protocol.

FWIW, Jim is right to observe that this is a consequence of multi-connection
sessions that span hardware interfaces.  SAM's world view is that a Port is
a hardware interface and hence some sort of hardware interface identifier
can
be used to name it.  Sessions that span hardware interfaces cause the SCSI
Initiator Port to become a software entity and are at the root of this.
Sessions with multiple connections but restricted to a hardware interface
do not cause issues - to a first approximation Fibre Channel does this
already
via multiple concurrent exchanges within a single N_Port to N_Port session.
This is another alternative - if iSCSI Ports were hardware ports, we'd be
guaranteed to line up well with T10, but that would be a major change.

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