Subject: iSCSI Boot: Technical Issues

From: "Prasenjit Sarkar" <[email-masked]>
Date: Fri, 20 Sep 2002 11:57:01 -0700

1. Looks like there is no opposition to making this a standard draft.

2. After talking to an HCI person in IBM, I have the following proposal:

We can change the LUN format to be xxxx-xxxx-xxxx-xxxx

This notation is subtantially better than "xxxxxxxxxxxxxxxx" in terms of HCI errors and is almost equivalent to a 16-bit format representation.

Since most of the numbers are going to be zeros, all we need to do is to edit 1 set of "xxxx".

I hope concerned parties at both sides are amenable to a resolution, since I have not seen any new arguments in the past week,

Thanks,
Prasenjit

---

From: Paul Koning <[email-masked]>
Date: Fri, 20 Sep 2002 15:59:22 -0400

>>>>> "Prasenjit" == Prasenjit Sarkar <[email-masked]> writes:

 Prasenjit> 1. Looks like there is no opposition to making this a
 Prasenjit> standard draft.  2. After talking to an HCI person in IBM,
 Prasenjit> I have the following proposal:

 Prasenjit> We can change the LUN format to be xxxx-xxxx-xxxx-xxxx

 Prasenjit> This notation is subtantially better than
 Prasenjit> "xxxxxxxxxxxxxxxx" in terms of HCI errors and is almost
 Prasenjit> equivalent to a 16-bit format representation.

 Prasenjit> Since most of the numbers are going to be zeros, all we
 Prasenjit> need to do is to edit 1 set of "xxxx".

I don't see why human factors questions appear in discussions about
protocols. 

If you want the UI to be nice, put a nice UI on the application that
generates the protocol.  I see no reason to make the protocol encoding
itself user-friendly.

       paul

---

From: Mark Bakke <[email-masked]>
Date: Fri, 20 Sep 2002 15:15:52 -0500

Prasenjit-

I like the dashes better.  They would also make it easier to just
specify the part of the LUN structure that is needed. SAM-2 section
4.9 defines three formats for 4-byte LUNs; the first two only use
the first 16 bits, and most implementations only use these.  I still
think that it will be a relatively rare case to use more than the
first four digits.

Can I suggest:

Single-level LUNs (defined in SAM-2 4.9.3) use xxxx; these can
have values up to 0x3fff.

Multiple-level LUNs (defined in 4.9.4) use as many xxxx fields as
they need (e.g. xxxx-xxxx, xxxx-xxxx-xxxx, and xxxx-xxxx-xxxx-xxxx
are all valid; unspecified xxxx are zeroes).  That would fit well
with the way the LUN structuring works in SAM-2; each implementation
uses the number of levels that it needs.

I just noticed that SAM-2 also allows extended single-level LUN
fields up to 8 bytes.  It appears that these are there for single-
level LUN implementations that need to define LUN values greater
than 0x3fff, without using the multi-level LUN structure which was
built mostly for (I think) parallel SCSI gateways.

Anyway, I think that your dash format, allowing for as many sets
of xxxx as needed, would be the ideal LUN format.

--
Mark

> Prasenjit Sarkar wrote:
> This notation is subtantially better than "xxxxxxxxxxxxxxxx" in terms of HCI errors and is almost
> equivalent to a 16-bit format representation.
> 

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

---

From: Mark Bakke <[email-masked]>
Date: Fri, 20 Sep 2002 15:20:09 -0500

Paul-

Since DHCP strings are configured directly by the user of a
DHCP server (which knows nothing about iSCSI or LUNs, and
probably shouldn't), we do have to care about the human factors
here.  Otherwise, anyone wanting to support iSCSI boot will
either have to build their own DHCP server tools (or interfaces
to Linux or Microsoft servers), or will have to convince
Microsoft to add iSCSI string and LUN support to DHCP (and
wait for this to happen), or let the user live with a difficult
format.

None of the above solutions are that appealing.  Making the
LUN format easier to handle is by far the simplest solution.

--
Mark

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

---

From: Luben Tuikov <[email-masked]>
Date: Fri, 20 Sep 2002 19:04:12 -0700 (PDT)

--- Mark Bakke <[email-masked]> wrote:
> are all valid; unspecified xxxx are zeroes).

More formally: `` ... unspecified xxxx to the left, are
zeros.''

-- 
Luben

=====
--

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

---

From: Mark Bakke <[email-masked]>
Date: Mon, 23 Sep 2002 08:31:35 -0500

Oh, yes, I forgot to specify that.

Actually, it should be "unspecified xxxx to the right are
all zeroes".  The reason is that the LUN field is not a
number; it is a structure.  The first two bytes are the
first-level LUN; the second two are the second-level LUN,
and so forth.  It's meant to allow a gateway to take, for
instance, a group of targets, each with their own LUNs,
make the original LUNs second-level LUNs, then make up its
own first-level LUN for each target.  These can be used
in other ways as well.

This all means that when specifying a first-level LUN, it
would be (let's say LUN 4) 0004-0000-0000-0000.  So saying
they are unspecified to the right would be the way to go.

--
Mark

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

---

From: Luben Tuikov <[email-masked]>
Date: Mon, 23 Sep 2002 08:53:28 -0700 (PDT)

> they are unspecified to the right would be the way to go.

Careful!

Tom, Dick and Harriet are used to just enter for a LUN a
number (and they think it's a number), so you'll have
ppl entering just `4'. Using ``to the right'' would make
this 4000-0000-0000-0000, contrary to your example.

Using ``to the right'' rule is kind of half way telling
users _what_ the SAM-3 LUN structure might be like and
I also don't think this is wise as Julian has suggested.

Natural ordering (e.g. what humans use) would
suggest ``to the left'' rule. So that the current
(physical)
addressing of LUN (`4') and the future (801F-0000-...) 
supported addressing are both easy on users.
(This was more or less my original argument for the
``to the left rule''.)

Q: is xxxx-xxxx-xxxx-xxxx supposed to be _just_ as
SAM-3 stipulates? (rhetorical question)

If so, then ``within each group of 4 hexacedimal digits
zeros are filled to the right, and groups of zeros
are filled to the left'' might be a wiser stipulation.

This ``right/left'' rule will be easy on the average user's
(the luser :-)) brain not to strain too much to understand
what it is (LUN) and that the good old '4' still
works just as the newer '801F-0000-...'.

-- 
Luben

=====
--

---

From: Mark Bakke <[email-masked]>
Date: Mon, 23 Sep 2002 11:08:47 -0500

I see your point.  In fact, we would take "4" as
0004-0000-0000-0000.  How about saying:

Within dashes, zeroes to the left; e.g. 4A == 004A.
Missing dashed fields become zeroes to the right.

4A = 004A-0000-0000-0000
12C-4-32 = 012C-0004-0032-0000

etc.  This is more what I think the user would expect.

--
Mark

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

---

From: Luben Tuikov <[email-masked]>
Date: Mon, 23 Sep 2002 09:55:37 -0700 (PDT)

> 12C-4-32 = 012C-0004-0032-0000

The examples are great, though the stipulation is not
formal as there are _only_ two groups ``within dashes''.

A clear an unambiguous stipulation would include
this definition plus your examples:

      Within each group of 4 hexacedimal digits zeros are
      filled to the right, and groups of zeros are filled
      to the left.
      
      Example:
        4A = 004A-0000-0000-0000

The advantage is that is is formal, and unambiguous
without a doubt. It implicitly defines what a group
is (four hexadecimal digits), if not defined anywhere
in the embedding document.

-- 
Luben

=====
--

---

From: Mark Bakke <[email-masked]>
Date: Mon, 23 Sep 2002 12:11:07 -0500

Luben-

I like it.

--
Mark

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