Re: [Ips] no DHCP-assigned InitiatorName

My 2cents on the issue. Please correct me if I am wrong. 

Shouldn't it be possible to configure the isns server with a set of
possibly regex rules for the control path. If this not possible today,
then it could possibly be the root to take towards standardizing. 

This can solve the problem of provisioning for dynamic boot environments
with minimum changes to legacy iqn implementations, many of which would
need to relearn to the new iqn mechanism that might end up as a result
of this discussion. Instead of changing numerous configurations we could
simply change the isns server control mechanism.

Comments?

-Shyam Iyer

-----Original Message-----
From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of
Michael Howard
Sent: Monday, September 22, 2008 11:40 PM
To: Julian Satran
Cc: Sivan Tal; Prasenjit Sarkar; ips@ietf.org
Subject: Re: [Ips] no DHCP-assigned InitiatorName

Julian Satran wrote:
> Michael,
> 
> I will have to defer to boot RFC authors. My 2 cents is that DHCP 
> "practice" has already several mechanisms to name the initiator (most 
> based on what the DHCP agents present to the DHCP server - like the 
> real of "fake" (for VMs) MAC address.

I agree that there are several different mechanisms that are used to
construct the initiator name. In practice, what we have ended up with
is:

   iqn.1987-05.com.intel:<hostname>
   iqn.2000-01.org.etherboot:<hostname>
   iqn.1995-05.com.broadcom.<11.22.33.44.55.66>.iscsiboot
   iqn.1986-03.com.ibm.<11:22:33:44:55:66>.<hostname>

This is a problem because almost every commercially available iSCSI
target uses the initiator name as an identification mechanism to control
visibility to target LUNs.

As a result, trying to move from one iSCSI boot initiator to another
requires changes on the SAN storage controller (or iSCSI head) to
reconfigure for the new initiator name. This is unnecessarily
complicated and, in many commercial environments, forces coordination
across different organizational units.

> And I don't know how the iBFT interacts (or is supposed to) with a 
> DHCP server.

There is no *direct* interaction between the DHCP server and the iBFT. 
Rather, the values get passed through the iSCSI boot initiator.

The boot iSCSI initiator is responsible for populating the iBFT with the
iSCSI parameters that are required to continue to boot the OS once it
switches to its protected-mode drivers.

The relevant fields in the iBFT are:
  * portal hostname/ip addr
  * portal port
  * target name
  * target lun
  * initiator name
  * CHAP stuff

The iSCSI boot initiator fills in these fields regardless of whether the
parameters come from EEPROM config or from a DHCP server. The values
that are filled in are the same values used by the boot initiator for
its iSCSI login.

Michael
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www.ietf.org/mailman/listinfo/ips
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www.ietf.org/mailman/listinfo/ips