Currently, when a node boots and submits the info available during IPXE (macs and uuid) to /svc/boot, the node is either identified as an existing node and the ID of that node returned, or its not and a new node is created at that point and the new ID returned.
We have situations, particularly with blade servers which are highly integrated where failure in the hardware require the mother board to be swapped out which includes the NICs meaning that the machine gets a new set of MACs and a new UUID. At this point the machine is "new" in the eyes of Razor.
Razor should be able to be configured so that it does not create a new node during the /svc/boot phase but rather delay this to the first checkin performed by the MK. At this point, the server could re-attempt to match the node using the full range of facts (which facts to use would be configurable). At this point if the node was to match an existing node, the MACs and UUID of the node would be updated and the node rebooted. /svc/boot would successfully match the node at this point. If still no match could be made, the server would generate a new node and return the ID.
Pull request https://github.com/puppetlabs/razor-server/pull/142 implements this behaviour. In this implementation, users would add to the configuration a configurable declaring what facts should be used to match. If no facts are supplied, the traditional behaviour of /svc/boot creating the node prevails. In my environment, I use facts that reveal the UUID of the disk partitions (these facts I believe eill be included in facter 2) which allows the node ID to associate to the machines data, I could essentially rebuild the machine around the data and maintain the association of the ID with the data.
Pull request https://github.com/puppetlabs/razor-el-mk/pull/18 on the MK repository also supports this behaviour.