RE: iSCSI: ISID issue

[Black_David@emc.com]

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