[dhcwg] PXE specification or network boot alternative

[<[e-mail]>]

Hi,

Apologies for emailing you all, but I didn't know who would be interested or who specifically to approach on this matter.

I am a C Developer and Unix Engineer currently contracted to The Royal Bank of Scotland.  I have just designed and delivered the first iteration of an end-to-end Solaris and Linux OS global provisioning system for the bank.  I am beginning to consider the next iteration and am contemplating the problems I encountered during the first, and one of the biggest problems I have is with the PXE specification: http://download.intel.com/design/archives/wfm/downloads/pxespec.pdf

In a large enterprise environment, there are several competing systems that would all like to use PXE and which do not co-exist or co-operate with one another.  Two identical types of hardware sitting next to each other in the same server cabinet, connected to the same subnet, might have two entirely different roles and each require to be network booted from different PXE servers.  The options available within DHCP for handing different PXE responses to different client requests are small and logistically horrible to manage in a company with 10,000+ servers worldwide.  As far as I can tell the only real options today for providing a different PXE server in a DHCP response, in a large enterprise, are based on:

 * IP address: filter by subnet.  Ineffective as clients of different types share the same subnets.
 * Architecture: filter by CPU architecture type.  Ineffective as clients of the same architecture (e.g. Intel) are built using different operating systems depending on use case (e.g. Windows, Linux, Solaris).
 * MAC address: filter by MAC address.  Ineffective given the large number of clients involved.  Managing changes to MAC address registrations becomes a software problem.  Integrating multiple services that each rely on PXE such that a single MAC registration process can be used is very complex.  Additional problems are introduced if network cards are moved between machines.  Migrating from one DHCP solution to another brings with it a complicated migration exercise.

An additional problem is that I am having to set-up tailored PXE menus per MAC address, in order to provide suitable boot menus for pre-registered Solaris and Linux clients.  Registering MAC addresses is troublesome, especially in a large environment, as when network cards are replaced, repositioned, or mother boards swapped, the registrations become invalid.  Convincing operators of a host registration system to provide the correct MAC address in a multi-homed system can also prove more of a challenge than one might expect.  It would be better if the choice of PXE server and PXE boot menu could be based optionally on GUIDs instead of MAC addresses.

I have some simple but effective improvements that I would like to see in PXE, which would include a change in PXE information included within DHCP Discover and DHCP Offer packets, that would be of benefit to all (but especially large corporates).

But, after doing a very small amount of digging so far, here are where the problems begin.

1) PXE is not an open standard, as far as I can see.  It is owned by Intel, possibly covered by patents (although I haven't checked this).
2) But, lots of open operating systems support PXE.

What I would like to know is -

a) Are IETF working on any open standards that could possibly replace PXE?  If so, I'd like to get involved please.
b) Does anyone have a contact within Intel who might consider my suggestions for improvement?  As far as I can tell the PXE specification hasn't been modified since 1999.
c) Could there be any ground for requesting that Intel release the PXE protocol to the IETF for continued development?
d) Any other options....?

If PXE were an open standard, I'd be the first to draft up a new RFC.  So any help or guidance would be appreciated on what the realistic options are here.  I'm really quite motivated to see an improved network boot mechanism prevail.

Here are details of the main improvements I'm looking for in the PXE specification, or which could be translated into a new open standard:

A) PC BIOS: BIOS to provide a 'PXE environment' field, which is a UINT16 and is included in the DHCP Discover packet.  How this new BIOS parameter is configured is up to the vendor.
B) PXE Client: When network booting, the 'PXE environment' field defined in the BIOS is included in the DHCP Discover packet.
C) PXE Client: When networking booting, additionally the server GUID (if available in the BIOS) is also included in the DHCP Discover packet.
D) DHCP/Proxy: When the DHCP server receives the DHCP Discover packet to port 67, it additionally looks for the 'PXE environment' field and GUID, and uses one or both of these when looking for matching rules.  The choice of PXE server can then be selected based on the value of these fields.  The DHCP Offer packet returned on port 68 can therefore be adjusted according to the requested environment.
E) DHCP/Proxy: If the 'PXE environment' field is missing, retain current behaviour.
F) DHCP/Proxy: If the 'PXE environment' field is 0, return a DHCP Offer packet on port 68 for a default PXE server but that additionally contains a list of the available PXE environments by number and by name.
G) PXE Client: If the 'PXE environment' field sent in the DHCP Discover packet was 0, look for the list of available PXE environments in the returned DHCP Offer packets.  Display to user and allow the user to select the environment.  The 'PXE environment' field can be set using this response and the process is then repeated from step B above.  Exact implementation of this stage (i.e. how to prompt the user to select the correct PXE environment) is up to the vendor.
H) PXE Client: DHCP Request to Installation Server on port 67 includes the 'PXE environment' field and GUID.
I) PXE Client: Boot Service Discover (DHCP Discover) to Boot Server on port 67 or 4011 includes the 'PXE environment' field and GUID.
J) DHCP/Boot Server: When the Boot Server receives the Boot Service Discover (DHCP Discover) packet, it additionally looks for the 'PXE environment' field and GUID, allowing these fields to affect the choice of boot file returned in the Boot Service Ack (DHCP Ack) as well as the configuration parameters.  This would therefore allow the PXE boot menu to be adjusted according to the 'PXE environment' and/or GUID.

What I'm looking for is guidance from this group on who initially I should discuss this idea with further, and how to overcome the challenges of open vs. non-open standards.  I expect more groups need to be involved than just this working group, and probably some of this is beyond the reach of IETF and I'll need to involve other parties.  Appropriate contacts I should be speaking with would be very helpful.

Best regards,
Mark.

Mark Bannister
Technical Consultant
RBS Global Banking & Markets



***********************************************************************************
The Royal Bank of Scotland plc. Registered in Scotland No 90312. 
Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. 
Authorised and regulated by the Financial Services Authority. The
Royal Bank of Scotland N.V. is authorised and regulated by the 
De Nederlandsche Bank and has its seat at Amsterdam, the 
Netherlands, and is registered in the Commercial Register under 
number 33002587. Registered Office: Gustav Mahlerlaan 10, 
Amsterdam, The Netherlands. The Royal Bank of Scotland N.V. and 
The Royal Bank of Scotland plc are authorised to act as agent for each 
other in certain jurisdictions.
 
This e-mail message is confidential and for use by the addressee only.
If the message is received by anyone other than the addressee, please 
return the message to the sender by replying to it and then delete the 
message from your computer. Internet e-mails are not necessarily 
secure. The Royal Bank of Scotland plc and The Royal Bank of Scotland 
N.V. including its affiliates ("RBS group") does not accept responsibility 
for changes made to this message after it was sent. 

Whilst all reasonable care has been taken to avoid the transmission of 
viruses, it is the responsibility of the recipient to ensure that the onward
transmission, opening or use of this message and any attachments will 
not adversely affect its systems or data. No responsibility is accepted 
by the RBS group in this regard and the recipient should carry out such 
virus and other checks as it considers appropriate. 

Visit our website at www.rbs.com

***********************************************************************************