Subject: Re: iSCSI: login issue - partial consensus call

From: "John Hufferd" <[email-masked]>
Date: Thu, 6 Sep 2001 12:48:30 -0700

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: [email-masked]

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

Sent by:  [email-masked]

To:   John Hufferd/San Jose/IBM@IBMUS
cc:   [email-masked]
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: [email-masked]
>
> Sandeep Joshi <[email-masked]>@research.bell-labs.com on
> 09/06/2001 11:44:00 AM
>
> Sent by:  [email-masked]
>
> To:   John Hufferd/San Jose/IBM@IBMUS
> cc:   [email-masked]
> 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: [email-masked]

---

From: Sandeep Joshi <[email-masked]>
Date: Thu, 06 Sep 2001 16:53:00 -0400

> necessarily an IETF issue as much as a SNIA type issue.

Ok.. I was just trying to examine the implications of the
"OS does ISID partition" rule on this consensus call.
(IOW, can we interoperate without this rule?)

If we agree with this rule, then Nick's argument is a non-issue
as you have rightly pointed out. 

thanks
-Sandeep