Re: iSCSI Boot: LUN Technical Issue

[Mark Bakke <mbakke@cisco.com>]

Prasenjit-

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

> Prasenjit Sarkar wrote:
> 
> 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).

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
>     simpler and desirable paradigm.

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.


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

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054