A few years back when I was learning Cisco ACI I read through a lot of white papers and configuration guides, banged my head against the wall trying to sort through all the information which I must admit was challenging and realized that since this is still a fairly new technology, the information I sought would not be readily available on the Internet or simply hard to find. I would have to spend the time researching the topics and with technical hands-on experience, develop standards and best practices that worked best for my customer deployments.
As I deployed more and more ACI Fabrics, I realized that if you have a poor design with your foundational building blocks namely Fabric Access Policies, it would become more difficult to manage the ACI environment and migrate it later to a hybrid or application-centric policy model. Unfortunately, with ACI there are a lot of relationships between constructs and its very difficult to rename objects and in many cases impossible. Organizing and naming ACI constructs from the beginning at the foundational level is essential to a simpler and more scalable architecture.
In my experience, proper ACI construct design begins with Cisco ACI Fabric Access Policies. These ACI Fabric Access Policies consist of physical domains, VLAN pools, AEPs, interface policy groups, interface selectors, interface profiles, switch policies, etc. These are constructs used for attaching endpoints into the Cisco ACI Fabric.
During the build of the Cisco ACI Fabric, it is very important to design the ACI Fabric Access Policies properly for ease of management, simplified troubleshooting and more importantly with scalability in mind. These constructs are heavily utilized in ACI Tenant polices and must be organized and named accordingly.