A sanitation department runs two SD-Access fabrics that may merge later. Which planning practice best reduces renumbering chaos at merge time?
Select an answer to reveal the explanation.
Short Explanation
Two fabrics that might become one are like two towns that might consolidate—duplicate street numbers become a nightmare. Keep IP pools unique and non-overlapping now. Future merge then stitches plans instead of renumbering every truck tablet overnight.
Full Explanation
A sanitation department running two SD-Access fabrics that may merge later should keep carefully unique, non-overlapping IP pools and addressing plans so a future merge does not force mass renumbering. Dual-fabric coexistence with disciplined addressing is the planning practice that reduces merge chaos.
Reusing identical user subnets at both sites because LISP will permanently hide all overlaps is unsafe; overlaps become painful at interconnect/merge time.
Assigning the same edge locator pool to both fabrics to simplify borders creates locator collisions across fabrics.
Numbering both fabrics from overlapping RFC1918 space and relying on NAT inside every VN by default adds fragility rather than clean merge readiness.
Exam caveat: uniqueness must cover underlay locators, pools, and often site/fabric identifiers—not only user DHCP scopes.
Operational check: publish a combined addressing spreadsheet for both fabrics with reserved merge ranges, and reject duplicate pool requests. Store the plan under sanitation network architecture control. In municipal operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same control still holds under the platform code and policy revisions used by the civic network team.