If you are a network engineer, you should know about Segment Routing and in particular Segment Routing version 6 (SRv6).

If you have been living in a cave for a couple of years, let me summarize: Segment Routing starts to be THE routing protocol, with multiple operators deployments in production, while some others are in the process of migrated from to MPLS to Segment Routing MPLS (SR-MPLS) to SRv6.

As Dan Voyer, Bell Canada, mentioned: “The power of SRv6 and SRv6 header compression allows us to change the game. Before, we used to have an MPLS network that only combined P and PEs. But with SRv6, we can stretch the network, include cell sites, and compute, keeping the transport very simple while easily managing the blast radius when there is an outage” [reference].

One of the reasons why I like SRv6, it’s for its ability to simplify the protocols stack. Think of a traditional L3VPN over MPLS and the multitude of protocols involved: the IGP with OSPF or IS-IS, MPLS, MPLS Label Distribution Protocol (LDP), Multi-Protocol BGP (MP-BGP), etc. Thanks to its compatibility with IPv6, SRv6 simplifies the deployment of network services.

What I specifically love about SRv6, it’s the mindset of the operators (thinking about) deploying it. If they act to simplify the routing stack and harmonize it through the different domains (core, data center, cloud, etc.), then those same operators already understood the importance of simplifying and harmonizing the operations and management stack (my playground).

Historically, the IETF made the mistake of specifying protocols while considering its operational aspects of at a later stage. Yes, you read my mind … “as a afterthought”! However, the industry, the vendors, and hence IETF, realized (sometimes the hard way) that if a feature can’t be automated, it basically doesn’t exist.

Wine get better with age, so does we at the IETF. Next to the numerous work-in-progress documents, I am happy to see a couple of operations & management Segment Routing related RFCs published already:

• RFC 9020 on YANG Data Model for Segment Routing
• RFC 9160: Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX)
• RFC 9259: Operations, Administration, and Maintenance (OAM) in Segment Routing over IPv6 (SRv6)
• RFC 9503: Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks

Today, I am happy to share this brand new RFC: RFC9487: Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPIFX), co-authored with Thomas Graf and Pierre François, which exports all the SRv6 header information:

Think about potential new cases:

• How many packets steered with an SR policy are forwarded or dropped using SRv6 in a network?
• If dropped, for which reasons?
• What is the current active segment and its associated control plane protocol?
• What is the SRv6 Segment List?
• What is the next SRv6 node and its type?
• How many SRv6 segments are left?

What is happening in case of compression of an SRv6 segment list? Remember: compression is required to reduce the size of the SRv6 encapsulation needed to steer packets over long segment lists. In such as case, the IPFIX flow records would report what is observed on the wire, so the IPFIX srhSegmentIPv6BasicList, srhSegmentIPv6ListSection and destinationIPv6Address Information Elements would report the compressed-SID containers. The SR Endpoint Flavors determines wherever the Segment List encoding is compressed, along with the flavor. The SID Locator determines the common most significant bits. By using described information from srhSegmentIPv6EndpointBehavior and srhSegmentIPv6LocatorLength IPFIX Information Elements, the compressed-SID containers can be decoded at IPFIX collector.

IETF is about running code and consensus, and yes there is already running code & interoperability, as you can see from the “Implementation Status” section in the draft version. Note that according to RFC 7942, Improving Awareness of Running Code: The Implementation Status Section, this section must disappear when the RFC is published.

If you want to learn more about our IETF hackathon experience, the glory details are in this blog “IETF Hackathon: SRv6 IPFIX Flow Monitoring” blog post.

Now, onto the next innovation, because obviously, this is only the beginning… See you at the IETF and its hackathon.