Reference models and migration considerations
In one line
The frameworks that structure operations and architecture - FCAPS, ITIL, TOGAF, DevOps - plus how to migrate a design safely.
Reference models
- FCAPS - Fault, Configuration, Accounting, Performance, Security: the network-management functional model.
- ITIL - IT service management (incident/change/problem).
- TOGAF - enterprise architecture framework.
- DevOps / NetDevOps - CI/CD, Infrastructure as Code, automation culture.
The management pyramids - TMN layers, OAM&P, eTOM, and mediation
The classic architecture question - "how do we organise the management estate?" - has a standard vocabulary. The TMN hierarchy stacks four layers: element management (keep each box running), network management (own relationships and end-to-end integrity), service management, and business management. Its enduring insight sits at the second layer: individually valid element configurations can still add up to a broken network - a static path misconfigured on one hop, timers that fight each other - so something must own the network as a whole, not one device at a time. OAM&P (operations, administration, maintenance, provisioning) cuts the same ground the way large providers organise teams, and eTOM/FAB cuts it as a lifecycle - fulfilment (turn the order into a working service), assurance (keep it within its promised level), billing - applied across network, service, and customer layers. Between the layers sits mediation: interfaces change going up in information (raw counters aggregate into KPIs), services (a mid-tier can offer subscription or archival services the device never had), and protocol (expose a modern northbound while speaking whatever the devices speak) - which is the honest job description of a manager-of-managers layer, and the answer to the otherwise N-x-M integration problem as tool count grows from element managers to network-wide inventory to service/billing systems. Design use: when a scenario asks where a capability belongs or why five element managers cannot stay the operating model, place the function on the pyramid and let the mediation layer absorb the heterogeneity.
Migration techniques
Phased / parallel cutover, ships-in-the-night (run old and new control planes together), overlay-then-migrate, controlled redistribution boundaries (see Redistribution and route manipulation), pilot/canary sites, and always a rollback plan. Minimize fate sharing during the transition.
Design considerations
Greenfield vs brownfield; interoperability; risk/rollback; and the business constraints (cost, timelines, change windows) that shape the plan.
What a high-level implementation plan contains
The Practical asks for the plan, not just the end state. A defensible high-level implementation plan is phased in dependency order, and every phase carries: entry and exit criteria (what must be verified before and after the step), a change window sized to the blast radius, named responsibilities, and a rollback trigger plus a tested fallback - a rollback that was never rehearsed is a hope, not a plan. Around the phases sit communication and training for the people the change touches, and the plan closes with acceptance testing against the written criteria agreed during design (Network Design - the prototype/pilot bookend). The step order is itself an exam answer: dependencies first, reversible before irreversible, observe between steps.
Why it matters for design
The CCDE expects you to place a design inside an operational framework and to produce a safe, staged migration / implementation plan - not just the end-state topology.
Related
- IPv6 design and migration - the IPv6-specific transition mechanisms.
- Redistribution and route manipulation
- Network management - traditional vs model-driven
Spaced repetition
Expand FCAPS.
Fault, Configuration, Accounting, Performance, Security (the network-management functional model).
Running the old and new control planes simultaneously during a migration is called [...].
Running the old and new control planes simultaneously during a migration is called ships-in-the-night.
The one thing every migration plan must include alongside the cutover steps is a [...].
The one thing every migration plan must include alongside the cutover steps is a rollback plan.
What makes an implementation plan defensible at CCDE level?
Phased in dependency order with per-phase entry/exit criteria, blast-radius-sized change windows, named responsibilities, a rollback trigger plus a tested fallback, comms/training around it, and closing acceptance tests against the written criteria - reversible steps before irreversible ones.
Why does the TMN network-management layer exist above element management?
Because individually valid element configurations can still yield a broken network - end-to-end integrity (paths, timer coordination, admission consistency) needs an owner; mediation layers then adapt information, services, and protocols between the layers (the manager-of-managers job).
Sources
- Cisco Press, Network Management Fundamentals (Clemm) - TMN/OAM&P/eTOM layering, management mediation and integration.
- Cisco Press, Top-Down Network Design; The Art of Network Architecture.