...

1. Parent switch has some interfaces configured as "fabric" interfaces, but no linknets are specified on the interface (using linknets API calls)
   In this case, the "fabric" interface is configured as access vlan 1, meaning untagged packets are sent to the ZTP DHCP server
2. The new device goes through DHCP_BOOT and DISCOVERED states the same as access switches
3. The administrator has to check in a new device in the settings repository with a new hostname and interfaces.yaml configuration
4. The device_init API-call is extended to allow for ZTP of type DIST and CORE, in addition to hostname this API-call can also take a list of expected neighbors as an argument
   a) device_init will check LLDP neighbors to see which interfaces are connected to other fabric devices and make sure both ends are configured as ifclass fabric
   b) device_init will create new linknets in database using interface information gathered from LLDP and assign IPv4 linknets from block configured in settings
   c) device_init will check that the list of neighbors hostnames exists and are of the correct device_type (neighbors to a DIST device should be CORE, and neighbor to CORE should be DIST)
   ( d) device_init will check that all peers are synchronized and config hash check passes ) this can't be done here, since linknets are already added they will be unsynced?
   e) device_init will push new configuration to the new device, at this point contact is lost to the device, state changes to INIT
   f) device_init will run syncto on peer devices so they re-configure their "fabric" interfaces and apply the new linknet configuration instead of ZTP config, and add BGP-peers etc
   g) device_init will check that the new device is now reachable via loopback, and change state to MANAGED if successful

...