A team subscribes to interface state for 2,000 access ports over NETCONF YANG-Push. Most ports never change for days, the management network is congested, and operators must see a state flip within seconds. Which telemetry publication model fits this subscription?
Select an answer to reveal the explanation.
Short Explanation
With 2,000 mostly quiet ports, on-change publication sends a sample only when something really differs, so quiet links stay quiet. A fast periodic timer fixes staleness by flooding the very network you're trying to spare. Polling locally doesn't remove the load; it just moves it onto your own server.
Full Explanation
On-change publication best matches the workload: it reports interface-state updates when they occur, so operators can see a flip promptly without repeatedly sending unchanged values for the many stable ports. A two-second periodic interval can provide frequent visibility, but it still publishes samples for ports whose state has not changed; across 2,000 ports, that recurring traffic works against the stated congestion constraint. Polling every second, even with batched requests, can keep observations fresh, but it creates continual request-response traffic and processing overhead rather than sending only actual changes. On-change publication with a ten-second dampening window reduces update bursts, but it can hold back a real state transition beyond the required response time; dampening is useful only when its delay is compatible with the freshness target. Exam caveat: on-change support and details such as dampening, synchronization, and notification delivery depend on the YANG model and device implementation, so the label alone does not guarantee seconds-level delivery. Practical check: verify the device’s supported subscription parameters, then measure change-to-notification latency and message volume under representative load, including a burst of port transitions.