RE: iSCSI: login issue - partial consensus call

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

I'm mystified as to why it's such an issue that an iSCSI HBA will have to
have a configuration interface, supplied by the manufacturer, in order to be
installed.  This is pretty much a MUST.  That is true of all "things that
need IP addresses, etc" assigned.  Yes, your product can try to select
defaults that may work (DHCP, etc) but there is no way they will work in all
environments.  So why do some seem to feel they should be able to create
iSCSI HBAs that require no configuration?  And if they require some
configuration, two items that should be configurable are iSCSI node name and
ISID range (in addition to IP address, netmask, gateway, DNS host, etc.
etc.).  What am I missing here?

It would be nice if this information could come from OS calls and someday it
might.  Meantime vendors supply config interfaces.  How can IP address(es)
come from the OS?  The iSCSI HBA needs the admin to assign a new one, not
use one the OS has assigned for other network interfaces.

And back on the topic of login behavior, I would submit that in order to
mandate Option B in the protocol, you need to refute the logic summarized so
elloquently by Jim in
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg06369.html

If you can't, option A seems the clear choice to me.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com 

> -----Original Message-----
> From: Martin, Nick [mailto:Nick.Martin@compaq.com]
> Sent: Thursday, September 06, 2001 1:33 PM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: login issue - partial consensus call
> 
> 
> Santosh,
> 
> If an iSCSI HBA driver is going to live within the SCSI subsystems in
> today's operating systems, it will be told almost nothing 
> about the host
> through those interfaces.  When the driver initializes, it is 
> likely to
> be told only the PCI addresses of its adapter(s).  It is provided
> interfaces only to expose its SCSI request, ioctl request, 
> and hardware
> interrupt service routines.  It will not get the host name, or an IP
> address via interfaces in the SCSI subsystem.  Interfaces to collect
> information such as IP address, and host name which are available to
> network drivers, are not available to many storage drivers.  These and
> anything else needed will have to be collected from other interfaces.
> Some OS environments will provide a way for the SCSI driver 
> to initiate
> queries for this information, some will allow static 
> pre-configuration,
> others will need to wait for something to poke the information in
> through custom ioctl interfaces, or retrieve or construct 
> what is needed
> from non-volatile storage on the HBA card.  
> 
> This is partly a chicken and egg problem.  The host name for 
> example is
> normally retrieved from the system disk which can not be read 
> until the
> storage driver has completed its initialization.  If the boot storage
> controller could ask the OS for the host name, it would not get a good
> answer.
> 
> Operating systems will eventually comprehend the need for driver APIs
> for iSCSI which blend network and storage requirements, but initial
> implementations will be entirely supplied by the HBA or driver vendor.
> 
> IMHO, if a driver can initialize (bootstrap) without information from
> other sources, you make life much easier for the driver writers,
> testers, and users.  If all iSCSI drivers operating within 
> the same host
> need to agree on something which is not available through a 
> pre-existing
> interface, there will be problems.  If the administrator has 
> to manually
> set the same InitiatorName (and/or AccessID) for each iSCSI 
> driver, that
> is one thing.  If he has to manually set non-overlapping 
> ranges of ISIDs
> for each driver instance that will be more error prone.
> 
> The suggestion by Michael Schoberg to eliminate initiator 
> assigned ISID,
> and only use TSID which is already guaranteed to be unique makes sense
> to me.  
> 
> As Michael noted, we are a bit off of the consensus topic.
> 
> Thanks,
> Nick
> -----Original Message-----
> From: Santosh Rao [mailto:santoshr@cup.hp.com]
> Sent: Thursday, September 06, 2001 1:57 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: login issue - partial consensus call
> 
> 
> "Martin, Nick" wrote:
> 
> > The problem is that iSCSI does not and will not specify how two HBAs
> > from different vendors installed in the same Initiator 
> should or could
> > get a range of ISIDs for their exclusive use.  This will be 
> operating
> > system specific and vendor defined.  It is uncertain that the same
> tool
> > or repository would be used by all HBA vendors in any environment.
> > Given this, accidental overlap in ISID space is not unlikely.
> 
> In the above scenario, if the HBAs do not have an interface 
> to receive a
> range of ISIDs from the OS iscsi driver, then, they must also lack an
> interface to be handed down an iscsi initiator node name from the
> OS driver. Without using a common iscsi initiator node name, the ISID
> issue
> does not arise for multiple HBAs. [since each would be using its own
> iscsi
> name].
> 
> OTOH, if the HBAs have an interface to be handed down an 
> iscsi initiator
> node name from the OS driver, there's no reason for them to 
> not provide
> an
> interface to be handed down an ISID or a range of ISIDs for their use.
> 
> I am in favor of option (A) since it is the simplest and a 
> well designed
> HBA should be providing interfaces for the OS driver to assign the HBA
> an
> iscsi initiator node name as well as a range of ISIDs, thus, rendering
> Nick's scenario unlikely.
> 
> >
> > Given that there is no one way to play right, we must make sure that
> > everyone can at least play nice.
> >
> > My expectation is that sessions are infrequently 
> established and long
> > lived.  ISIDs may be re-used at will by their current 
> owners.  When no
> > "already owned" ISIDs are available, or an attempt to re-use an
> "already
> > owned" ISID failed, and HBA would need to a) "probe" for a new
> available
> > ISID or b) fail the request to establish the session.  Session
> recovery
> > should not be attempted unless a session is known to have failed.
> >
> > If tools are available, and the administrator has used them 
> correctly,
> > then HBAs will not collide in ISID space.  If the tools are not
> > available or were not used correctly, I would hope the 
> second HBA can
> > still attempt to come up without impacting the sessions 
> established by
> > the first.
> 
> If the tools were not available, how does the 2nd HBA get assigned the
> same
> iscsi initiator node name as the first ? The ISID issue is only
> applicable
> if both HBAs are sharing the same iscsi initiator node name.
> 
> I would like to understand the rationale behind an HBA interface
> allowing
> an initiator node name to be assigned, but not an ISID or a range of
> ISIDs
> (?).
> 
> 
> Regards,
> Santosh
> 
>