Subject: iSCSI Boot: LUN Technical Issue

From: "Prasenjit Sarkar" <[email-masked]>
Date: Wed, 18 Sep 2002 11:53:39 -0700

Here is a status on the technical issue regarding representation of LUN values in the iSCSI boot DHCP string.

The arguments supporting the representation of a 16-bit LUN value is primarily HCI. (It should be noted that HCI issues are particularly difficult to resolve).

The arguments against the representation of such a value is (a) use of the default LUN simplifies HCI issues in most cases, and (b) LUN equivalence between the DHCP string and iSCSI PDUs is a simpler and desirable paradigm.

I have not heard any new arguments in the past few days, I will let the chairs declare a timeout.

Prasenjit

---

From: Mark Bakke <[email-masked]>
Date: Wed, 18 Sep 2002 14:01:00 -0500

Prasenjit-

What does HCI stand for?

> Prasenjit Sarkar wrote:
> The arguments supporting the representation of a 16-bit LUN value is primarily HCI. (It should be
> noted that HCI issues are particularly difficult to resolve).
> 
> The arguments against the representation of such a value is (a) use of the default LUN simplifies
> HCI issues in most cases, and (b) LUN equivalence between the DHCP string and iSCSI PDUs is a
> simpler and desirable paradigm.
> 

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: Luben Tuikov <[email-masked]>
Date: Wed, 18 Sep 2002 12:47:20 -0700 (PDT)

> What does HCI stand for?

Human Computer Interaction -- see my message
on the thread 
``Re: iSCSI Boot Last Call - Technical Comments''
dating Thu, 12 Sep 2002 16:05:41 -0400.

It is a somewhat newer field in computer science
encompassing several various disciplines (psychology,
etc). It has existed before but never formally. Now
one can actually specialise in HCI in a university
CS program.

...

-- 
Luben

P.S. I can name a number of companies who _desperately_
need ppl specialised in HCI... but alas...

=====
--

__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com

---

From: Mark Bakke <[email-masked]>
Date: Wed, 18 Sep 2002 15:14:39 -0500

Prasenjit-

OK, now I know what you meant (Thanks, David and Luben).

> The arguments supporting the representation of a 16-bit LUN value is
> primarily HCI. (It should be noted that HCI issues are particularly
> difficult to resolve).

So if HCI issues are difficult, why not take a small step by
allowing the user to do the simplest thing most of the time?
I don't think that anyone will be modifying their DHCP servers
to do this for us.

> The arguments against the representation of such a value is
> (a) use of the default LUN simplifies HCI issues in most cases, and
> (b) LUN equivalence between the DHCP string and iSCSI PDUs is a

I still see no reason why the iSCSI PDU matters.  Except for a
few curious (or perhaps frustrated) people who end up watching
their traffic with Ethereal (an excellent tool, BTW), no customer
or end user is going to care about PDUs, or their formats.

We have an iSCSI target with a good set of drivers that has been
available for nearly two years, and there is no mention of the
LUN data structure (beyond that LUNs are 16-bit numbers) in any
of our documentation.  And nobody's asked.  From a standards
point of view, this LUN structure exists, but from a practical
point of view, use of more than a 16-bit LUN (and in most cases
8 bits) is quite rare.

We are choosing between making life easier for the end user, and
making our solution more elegant with respect to the standards.
I'm on the end user's side.

The frustrating thing is we just finished allowing the iSCSI
negotiation sequence to use decimal numbers in addition to
hex, thinking it might be easier for a user to look at or cut
and paste (which I think will be rare), and now we are going
to limit the LUN field in a DHCP option to a strict, difficult-
to-type format, which will always be entered by a user.  This
seems backwards.

Anyway, sorry for the rant, but I really want to see this be
made as easy as possible on the user.

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054