...

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 will can also require take a list of peer hostnames it should build linknets toexpected neighbors as an argument
   a) device_init will check that the settings repository contains a device with this hostname
   bLLDP 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 peer neighbors hostnames exists and are of same the correct device_type (all DIST or all CORE)
   cneighbors 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
   d) device_init will check LLDP neighbors to see that provided list of peers are actually seen, and what interfaces both ends use
   e) device_init will create new linknets in database using interface information gathered from LLDP
   f) device_init will push new configuration to the new device, at this point contact is lost to the device, state changes to INIT
   gf) 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
   hg) device_init will check that the new device is now reachable via loopback, and change state to MANAGED if successful

...

New device is not directly connected so LLDP information is not seen, in this case peer hostnames list can be set as an empty list and all interfaces and BGP peers have to be configured manually? Also manual reconfig of peer devices might be needed at step 4g4f

Caveats:

It might not be able to fully ZTP devices that should go in the "evpn_peers" list (CORE devices), since it's probably not possible to populate "evpn_peers" list before the devices exist, and routing connectivity to the management loopback will not work until after the evpn_peers has been established.