RE: iSCSI: ISID issue

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

All,

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