Network Observability Innovations at the IETF#

Speakers: Thomas Graf (Swisscom)

• Why: Model-driven streaming telemetry is the direction of travel for every serious network operator, and this talk is a practitioner's map of the actual standards you would build on — from a Swisscom production deployment, not a slide-ware architecture. It answers a concrete ops question: how to get real-time network state without logging into routers, and how to join control-plane, management-plane, and data-plane views into one correlated stream.
• What: Three connected pieces. (1) Real-time L3VPN observability by correlating IPFIX (MPLS/SRv6 provider and IPv4/6 customer data plane), BMP (BGP VPNv4/6 RIBs with path-decision and route-policy metadata), and YANG-Push — using BGP standard communities to tag logical connections/connection points and SRv6 VPN SIDs on the IPv6 next-hop to stitch customer flows to services. (2) IPFIX segment-routing coverage: RFC 9160 (MPLS SR labels), RFC 9487 (SRv6 segment lists, endpoint behavior), RFC 9951 (per-hop forwarding-path delay), plus an IOAM direct-export on-path-delay draft leveraging RFC 9378/9197 and enhanced alternate marking (RFC 9341). (3) The YANG-Push-to-data-mesh architecture: a YANG Schema Registry that assigns schema IDs so YANG notifications can flow unchanged through a message broker (Kafka) with semantic validation at the consumer — plus an honest 23-year timeline of YANG/Push standardization, including that RFC 8639/8641 finished in 2019 with no major vendor implementations and that gNMI was taken to IETF in 2017.
• How: Subscribe to YANG datastores (periodic for statistics, on-change with sync-on-start for state, per RFC 8641/9196), collect module dependencies via <get-schema> and YANG Library, register schema trees centrally, prefix broker messages with schema IDs, and transform BMP messages into YANG-modeled telemetry at the monitoring station per the ietf-bmp and message-broker drafts. Node-based flow aggregation joins IPFIX records with control-plane context.
• Where applicable: The L3VPN/SRv6 correlation pipeline is Swisscom-specific production, but every mechanism cited is an IETF RFC or active draft (BMP RFC 7854/8671/9069/9972, IPFIX SR RFCs, YANG-Push data-mesh drafts in NMOP/GROW) — so the patterns transfer to any SRv6/BGP shop building a telemetry pipeline. Most valuable if you run VPN services and want per-hop delay and service-level flow context from standards rather than vendor probes. Based on the speaker's slides.