How to determine a switch's role in a Clos network with MLAG’d leaves

A group of us have been experimenting with IP Fabrics recently and I'm curious to know if anyone has used the following approach or knows of work that accomplishes the same goal in a different way.  

When initializing an IP Fabric, one of the first decisions that needs to be made concerns the switch role (e.g., is this a leaf or a spine switch).  There are multiple approaches that could be used to aid with this decision:

1. Rely on the factory to preset the personality of each switch before it is shipped. The challenge with this approach is that it requires additional information to be supplied by the customer and consumed by the technician in the factory.
2. Rely on the customer to identify the switch roles (e.g., via MAC Address) as racks are being installed. This approach could be perceived as burdensome to the customer.
3. Determine the switch role programmatically and allow the customer to override the switch roles if necessary.  The diagram below and the explanation following it provide an overview of how this might be possible if we assume MLAG’d leaves are going to be a part of the topology.

Step 0: Every switch will provide the Network Controller with the list of switches it is connected to.  This information can be gathered via LLDP. 

Step 1: The Network Controller will separate the switches into two groups; the first group (i.e., A, B and C) will be connected to a common set of other switches (i.e., D, E, F, G, H, I), the second group (i.e., D, E, F, G, H, I) will not be connected to a common set of switches. 

Step 2: Label the common set of switches that the first group is connected to as set Ω and understand that anything connected to Ω is a spine switch and should be included in set Φ.

Step 3: For each member in Ω, remove the members of Φ from its list of connected members.

Step 4: For each member in Ω, use the remaining switch in the list of connected members as its MLAG partner.

Comments welcome!