Re: iSCSI: login issue - partial consensus call

["John Hufferd" <hufferd@us.ibm.com>]

I did not intend to trivialize the issue, however, I think this is not
necessarily an IETF issue as much as a SNIA type issue.

Having said that, I would also like the vendor HBAs to be able to cooperate
until the OSs catch-up.

Sometimes, when devices start-up, they are able to check and see what other
device like themselves have been already started, and a unique name is
given to their instance, that is often numeric (like "iSCSI Adapter 01", or
"iSCSI Adapter 02").  I think the technique is OS, related, even if the OS
is not aware of it.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


Sandeep Joshi <sandeepj@research.bell-labs.com>@research.bell-labs.com on
09/06/2001 12:35:22 PM

Sent by:  sandeepj@research.bell-labs.com


To:   John Hufferd/San Jose/IBM@IBMUS
cc:   ips@ece.cmu.edu
Subject:  Re: iSCSI: login issue - partial consensus call




John,

I wasnt suggesting making ISIDs a hardware-configurable item.

There are two ways to give out the Initiator Name and ISID to HBAs :
(a) Modify OS stack - new midlayer to coordinate all HBAs
    Transparent to the user.
(b) Custom vendor programs - which download config info
    into HBAs.   Needs admin intervention.

Now, how do we modify all those machines/OS instances out there
to make them work with the new iSCSI HBAs ?

Its going to take time for Microsoft, Linux, Solaris, etc
to make their OSes iSCSI-friendly with perhaps a new driver.
Until then, vendors will be forced to use option (b).

That is the point I was trying to make...how do we play
with existing installations ?

-Sandeep

John Hufferd wrote:
>
> I understand you point, however, the discussion we had on this, talked
> about each HBA needing to have an install process that is OS specific.
It
> was suppose to be an OS specific install or startup process that handed
out
> the ISIDs (or ISID ranges).
>
> I think your point is that you wish that there was no reason to interact
> with the OS, in order to get installed.  I do not think that is a good
> assumption.
>
> It is the OS that needs to let the HBA know what the iSCSI Initiator Node
> Name is, so that the HBA can configure to use it.  It might as well hand
> out the ISIDs at the same time.
>
> You are suggesting that making the ID of the iSCSI HBA only a HW item.
> This is not where we came down previously.  You want to make your job of
> interfacing with the OS, simpler, and put more burden on the
administrator.
> This was the mistake we made with FC and I would not like to see that
> repeated here.  You say that there needs to be Jumpers or switches, well
> this is up to your adapter.  We use to do that kind of stuff before the
> Plug and Play started working with the OS.  We need to work with the OS
in
> a similar manor.
>
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136
> Internet address: hufferd@us.ibm.com
>
> Sandeep Joshi <sandeepj@research.bell-labs.com>@research.bell-labs.com on
> 09/06/2001 11:44:00 AM
>
> Sent by:  sandeepj@research.bell-labs.com
>
> To:   John Hufferd/San Jose/IBM@IBMUS
> cc:   ips@ece.cmu.edu
> Subject:  Re: iSCSI: login issue - partial consensus call
>
> John,
>
> Is this what you are referring to ? (Sec 1.3 of Naming & Discovery)
>
> > b) The ISID name space of the iSCSI Initiator should be partitioned
> >       among the intiator portal groups.
>
> How do you perceive this will be achieved in practice ?
>
> This can turn out to be an nightmare for HBA vendors.
> IRQ settings, jumpers, or setup programs which run at boot
> instantly come to mind.
>
> Ideally, ISIDs should work as SCAM works but that would involve
> adding a mid-layer to OSes, to distribute that ISID name space.
> Modifying OSes in the field is tough, as we all know.
>
> I realize the standard wont mandate such configuration items
> but I'd rather we not add rules which would force such
> configuration tweaks to become necessary.
>
> We should reconsider the above rule and its consequence on
> the login issue Nick brought up.
>
> Regards,
> -Sandeep
>
> John Hufferd wrote:
> >
> > By the way, the OS is also suppose to have a way to hand out (partition
> up)
> > ISIDs to the various iSCSI Initiator functions, whether they are
Software
> > or Hardware.
> >
> > So, even though,  I was initially swayed by Nick's Arguments -- we
> require
> > the OS to partition up the ISID space and hand out specific ISIDs or
> ranges
> > of ISIDs (in some manor) to the iSCSI Initiator functions (regardless
of
> > whether they are in Software or Hardware) -- I do not now see, if the
> > implementation is as specified in our spec., how there is a conflict in
> > ISID.
> > .
> > .
> > .
> > John L. Hufferd
> > Senior Technical Staff Member (STSM)
> > IBM/SSG San Jose Ca
> > Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> > Home Office (408) 997-6136
> > Internet address: hufferd@us.ibm.com