Service Design
What this lens evaluates
Whether the network delivers the specific services and applications the business runs - with the right QoS, multicast, network services, and segmentation - to meet application SLAs. The network exists to carry services; this lens keeps the design application-driven.
The questions it forces
- What are the application requirements (latency, loss, jitter, bandwidth) and SLAs?
- Is QoS designed end-to-end to honour them?
- Are multicast and network services (NAT, DNS/DHCP, load balancing, app delivery) designed for?
- Is segmentation offered as a service (per-tenant/per-app)?
Core considerations
- QoS -> QoS design - models and strategy.
- Multicast -> Multicast routing design - PIM, RP, MSDP, Layer 2 multicast - IGMP and MLD snooping.
- Network services & connectivity -> SD-WAN design, MPLS L3VPN and L2VPN, Generic routing and addressing - PBR, NAT, RIB-FIB.
- Segmentation as a service -> Infrastructure segmentation.
The AI/ML angle (Exam Topics 4.2.g)
AI is the application: the inference service must be delivered and protected (Protecting AI services - WAF, API security, and inference endpoints), the storage service must sustain training/checkpoints (Storage and checkpointing for AI), and the workload profile (training vs inference) sets the service requirements (AI-ML workloads and their infrastructure impact).
The network is a service
The design mindset has shifted from network availability to application and service availability - users only care that the application works - so design backward from application models and their constraints/requirements (latency, loss, jitter, bandwidth, transaction patterns). For cloud-delivered services the connectivity model is itself a service-design choice: direct cloud access, access via a cloud access point/gateway, or a hybrid approach - chosen against the application's requirements and the placement drivers in Service placement - on-prem, cloud, hybrid, distributed.
How it shows up in a scenario
You map application/SLA requirements to QoS, services, and segmentation. Start from the service the business needs and design the network to deliver it - not the other way round.
Tip: Scenario reflex
*Design to the application's actual SLA, not the best possible.* Over-provisioning QoS, multicast, or services the application does not need is as wrong as under-serving it - deliver exactly what the stated requirement calls for, and no more.
Spaced repetition
In Service Design, why is over-provisioning a wrong answer?
You design to the application's actual SLA - delivering more QoS/services than the requirement needs adds cost and complexity without benefit, which the exam penalises just like under-serving.
What does the Service Design lens keep the design anchored to?
The applications/services and their SLAs - QoS, multicast, network services, and segmentation are designed to meet application requirements.
Service Design for AI means [...].
Service Design for AI means delivering and protecting the inference service, sustaining the storage/checkpoint service, and matching the training-vs-inference profile.
The end-to-end mechanism for honouring application SLAs across the network is [...].
The end-to-end mechanism for honouring application SLAs across the network is QoS (classification/marking/queuing per a chosen model).
What is the "shifting of availability" idea?
Design focus has moved from network availability to application/service availability - users only care that the app works - so you design backward from application requirements.
The three cloud connectivity models are [...].
The three cloud connectivity models are direct cloud access, access via a cloud access point/gateway, and hybrid.
Sources
- Cisco CCDE v3.1 Unified Exam Topics (Domain 4).