Re: iSCSI-boot: comments

["Prasenjit Sarkar" <psarkar@almaden.ibm.com>]

Thanks for your comments. Reponses embedded in +++


   Prasenjit Sarkar
   Research Staff Member
   IBM Almaden Research
   San Jose



                                                                                                          
                      "Mallikarjun C."                                                                    
                      <cbm@rose.hp.com>        To:       <ips@ece.cmu.edu>                                
                      Sent by:                 cc:                                                        
                      owner-ips@ece.cmu        Subject:  iSCSI-boot: comments                             
                      .edu                                                                                
                                                                                                          
                                                                                                          
                      05/06/2002 03:09                                                                    
                      PM                                                                                  
                                                                                                          
                                                                                                          



Attached are some comments on the iSCSI boot draft, rev05.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668
Roseville CA 95747
cbm@rose.hp.com


>1. Requirements
>
>   1. There must be no restriction of network topology between the iSCSI
>   boot client and the boot server.

Need to add "other than those in effect for establishing the iSCSI
session."

+++ didnt follow - what topology restrictions are required to establish an
iSCSI session +++
....

>   2. The following represents the minimum information required for an
>   iSCSI boot client to contact an iSCSI boot server: (a) the client's
>   IP address (IPv6 or IPv4); (b) the server's iSCSI Service Delivery
>   Port Name;

Suggest an "iSCSI Target Port Name" in place of "Service Delivery Port
Name"
- same comment for all places in this document wher SDP is used.  SAM-2
no longer uses the term....

Also, I'd think the iSCSI target portal address is required, unless
discovery is being presumed before boot...

++agreed, target portal address has been added to the dhcp string+++
.....

>
>   Additional information may be required at each stage of the boot
>   process.
>
>   3. It is possible for the iSCSI boot client to have none of the above
>   information or capability on starting.
>
>   4. The client should be able to complete boot without user
>   intervention (for boots that occur during an unattended power-up).
>   However, there should be a mechanism for the user to input values so
>   as to bypass stages of the boot protocol.
>
>   5. Additional protocol software (for example, DHCP) may be necessary
>   if the minimum information required for an iSCSI session is not
>   provided.

#3 and #5 above don't sound like requirements to me - particularly #3.

+++ they are requirements found in related boot protocols - while appearing
obvious, they need to be stated ++++

.....
>4. DHCP stage
>
>   In order to use an iSCSI boot server, the following pieces of
>   information are required.

for an iSCSI boot client? [ if this is true, the following bullet
may be reworded as "its own IP address"....]

++ yes +++

>
>   - The IP address of the iSCSI boot client (IPv4 or IPv6)
>
>   - The IP transport endpoint for the iSCSI service delivery port for
>   the iSCSI boot server.  If the transport is TCP, for example, this
>   has to resolve to an IP address and a TCP port number.

It is useful to note that iSCSI currently is defined only for TCP.

++noted++

>
>   - The eight-byte LUN structure identifying the device within the

I wouldn't use "device" at all here - it is a "Logical Unit" per SAM-2.

++ ok ++

>   iSCSI boot server.

It appears to me that all the above information is realized *after*
using the "DHCP stage".  It would be useful to state this, particularly
when presented at the beginning of the section as the "required
information".

++ ok +++
.....

>   Unless otherwise specified here, DHCP fields such as the client ID
>   and gateway information are used identically with applications other
>   than iSCSI.

S/b "identically with applications other than iSCSI."
W/  "in an identical way as applications other than iSCSI do."

++ yes that is definitely better grammar +++

>
....
>   The fields "servername", "port", "protocol" and "LUN" are optional
>   and should be left blank if there are no corresponding values. The
>   "targetname" field is not optional and must be provided.
>
>   Thv "servername" is the name of iSCSI server and contains either a

Typo above - "Thv".

++ ok +++

.....

>   The "LUN" field is a 16 byte hexadecimal representation of the 8-byte

16-nibble?  I'd actually prefer "8 byte".

++ yes +++

>   LU number in hex. Digits above 9 may be either lower or upper case,
>   and all 16 nibbles must be present. If the LUN field is blank, then
>   LUN 0 is assumed.
>
>   Note that SCSI targets are allowed to present different LU numberings
>   for different SCSI initiators, so that to our knowledge nothing
>   precludes a SCSI target from exporting several different devices to

S/b "device" W/ "LU"

+++ correct +++

>   several different SCSI initiators as their respective LU 0s.

S/b "LU" W/ "LUN".

++ yes+++

>
>   The "targetname" field is an iSCSI Name that is defined by the naming
>   and discovery in Section 2.1 iSCSI Naming and Discovery draft[9] to
>   uniquely identify an iSCSI target.  The use of the targetname
>   component is also defined by the iSCSI standard[4] and is to be used
>   accordingly.

Given that iSCSI now assumed all normative N&D text, I would suggest
getting rid of the reference to N&D for normative definitions here.

+++ will do +++

.....
>
>5. Discovery Service stage:

Remove ":"

A general comment on this Stage - the LBA offset within the LUN
(where the boot image starts) could also be discovered by a boot
client via the service attributes in the SLP Service Advertisement.
This is perhaps one more reason for employing Discovery Service stage.

BTW, all stages should either be titled "Stage" or "stage".  I see
both now.

+++ LBA offset discovery is not the concern of iSCSI boot -- this is the
job of the boot protocol above iSCSI boot +++

++ okay wrt Stage/stage +++

>
>   This stage is required if the DHCP server (v4 or v6) is unaware of
>   the Service Delivery Port Name of the iSCSI boot server.  The
>   implemention of the discovery service is to based on the SLP

Remove "to".

++ok++

>   protocol[1,24].
>
>   The iSCSI boot client may have obtained the targetname of the iSCSI
>   boot server in the DHCP stage (Section 4). In that case, the iSCSI
>   boot client queries the Discovery Service using query string 1 as

Need to define "Discovery Service" before using it ( = "discovery service"
 "an instantiation of SLP DA"?).

+++ okay +++

>   specified in the iSCSI SLP interaction document[24] to resolve the
>   targetname to an IP address and port number. One this is obtained,

S/b "One" W/ "Once"

A reading of the iscsi-slp draft doesn't lead me to believe that
this translation is necessarily maintained by the DA.  I am not
sure why can't the regular DNS be used here.

Also, a search of the iscsi-slp draft doesn't yield any pointers
to what "query string 1" (or 4) is....

......

+++ will investigate, havent seen the slp draft in some time +++

>
>   client may contact any iSCSI boot server in the list. Moreover, the
>   the order in which iSCSI boot servers are contacted is also left to

S/b "the order" W/ "order".

+++ okay +++

>   the discretion of the implementor.
>
>6. Boot Stage
>
....

>
>   However, the use of a discovery session is not recommended because at

The iSCSI discovery session *cannot* be used if any read commands
are to be performed.

++ will fix, applies to the following comments too +++

>   this stage (i) a boot server has probably been found and (ii) the

"probably" ?  I presume a boot client would not proceed to Boot Stage
unles a boot server had been found.

.....

>References
.....
>
>
>   [17] http://developer.intel.com/ial/WfM/wfm20/design/pxedt/index.htm

This URL is broken.  Also, Intel now calls the enhanced PXE as
Boot Integrity Services (BIS).