Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)

A dedicated Routing Extension Header, called Segment Routing Header (SRH), is defined in for use of Segment Routing (SR) over IPv6 data plane. Also, three routing protocol extensions, OSPFv3, IS-IS and BGP Prefix Segment Identifiers(Prefix-SIDs) and Path Computation Element Communication Protocol (PCEP) Extension and Segment Routing Policy are defined to propagate Segment Identifiers (SIDs). SRv6 segment endpoint behaviors describe how packets should be processed by SRv6 Segment Endpoint Nodes. Such behaviors are defined in . This document specifies eleven new IPFIX Information Elements (IEs) and one new subregistry within the "IPFIX Information Elements" registry , for SRv6 purposes. These IEs are used to export the SRv6 active segment and its control plane protocol, the SRv6 Segment List, the next SRv6 node and its type, and the numbers of SRv6 segments left. Some examples are provided in Appendix A.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document makes use of the terms defined in , and . The following terms are used as defined in : IPFIX IPFIX Information Elements Template Template Record Options Template Options Template Record Data Record Data Set The following terms are used as defined in : Segment Routing (SR) Segment Segment List Active Segment Segment Identifier (SID) SRv6 SRv6 SID The following terms are used as defined in : Segment Routing Header (SRH) SR Source Node Transit Node SR Segment Endpoint Node Reduced SRH Segments Left Last Entry

This section specifies the new SRv6 IPFIX IEs. 8-bit flags defined in the SRH (Section 2 of ). 16-bit tag field defined in the SRH (Section 2 of ). A tag is used to mark a packet as part of a class or group of packets sharing the same set of properties. 128-bit IPv6 address that represents a SRv6 segment. 128-bit IPv6 address that represents the active SRv6 segment. Ordered basicList of zero or more 128-bit IPv6 addresses in the SRH that represents the SRv6 Segment List. As specified in Section 2 of , the Segment List is encoded starting from the last segment of the SR Policy. That is, the first element of the Segment List (Segment List[0]) contains the last segment of the SR Policy, the second element contains the penultimate segment of the SR Policy, and so on. The SRH Segment List as defined in Section 2 of as a series of octets in IPFIX. 8-bit unsigned integer defining the number of segments remaining to reach the end of the Segment List from the SRH, as specified by the "Segments Left" field in Section 4.4 of and mentioned part of the SRH in Section 2 of ). Exposes the SRH and its TLVs as specified in Section 2 of as a series of octets in IPFIX. Name of the routing protocol or PCEP extension where the active SRv6 segment has been learned from. The SRH segment IPv6 locator length specified as the number of significant bits. Together with srhSegmentIPv6 it enables the calculation of the SRv6 Locator. 16-bit unsigned integer that represents a SRv6 Endpoint behavior as per Section 4 of . Note that the srhSegmentIPv6, srhSegmentIPv6LocatorLength, and srhSegmentIPv6EndpointBehavior IPFIX IEs are generic fields, to be used in the context of IPFIX Options Templates or IPFIX Structured Data .

The IPFIX IEs srhSegmentIPv6BasicList (TBD5) or srhSegmentIPv6ListSection (TBD6), srhActiveSegmentIPv6 (TBD4), srhSegmentsIPv6Left (TBD7), srhIPv6ActiveSegmentType(TBD9), forwardingStatus (89) , and some existing counters information allow to provide answers to the following questions (amongst others): How many packets steered with a 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?

Note to the RFC-Editor: Please replace TBD1 - TBD17 with the values allocated by IANA Please replace the [RFC-to-be] with the RFC number assigned to this document

This document requests IANA to add new IEs () to the "IPFIX Information Elements" registry available at . Table 1 lists the new SRH IEs:

Name:: srhFlagsIPv6

ElementID:: TBD1

Description:: The 8-bit flags defined in the SRH (Section 2 of ). Assigned flags and their meanings are provided in the "Segment Routing Header Flags" IANA registry.

Abstract Data Type:: unsigned8

Data Type Semantics:: flags

Additional Information:: See the assignments in the "Segment Routing Header Flags" IANA registry at https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#segment-routing-header-flags. See also RFC8754 for the SRH specification.

Reference:: [RFC-to-be]

Name:: srhTagIPv6

ElementID:: TBD2

Description:: The 16-bit tag field defined in the SRH (Section 2 of ). A tag is used to mark a packet as part of a class or group of packets sharing the same set of properties.

Abstract Data Type:: unsigned16

Data Type Semantics:: identifier

Additional Information:: See Section 2 of for more details about the tag.

Reference:: [RFC-to-be]

Name:: srhSegmentIPv6

ElementID:: TBD3

Description:: The 128-bit IPv6 address that represents a SRv6 segment.

Abstract Data Type:: ipv6address

Data Type Semantics:: default

Additional Information:: Specified in Section 1 of and mentioned in "Segment List" in Section 2 of .

Reference:: [RFC-to-be]

Name:: srhActiveSegmentIPv6

ElementID:: TBD4

Description:: The 128-bit IPv6 address that represents the active SRv6 segment.

Abstract Data Type:: ipv6address

Data Type Semantics:: default

Additional Information:: See Section 2 of for the definition of active segment.

Reference:: [RFC-to-be]

Name:: srhSegmentIPv6BasicList

ElementID:: TBD5

Description:: The Ordered basicList [RFC6313] of zero or more 128-bit IPv6 addresses in the SRH that represents the SRv6 Segment List. As specified in Section 2 of , the Segment List is encoded starting from the last segment of the SR Policy. That is, the first element of the Segment List (Segment List[0]) contains the last segment of the SR Policy, the second element contains the penultimate segment of the SR Policy, and so on.

Abstract Data Type:: basicList

Data Type Semantics:: list

Additional Information:: See Section 2 of for more details about the SRv6 Segment List.

Reference:: [RFC-to-be]

Name:: srhSegmentIPv6ListSection

ElementID:: TBD6

Description:: The SRH Segment List as defined in Section 2 of as a series of octets in IPFIX.

Abstract Data Type:: octetArray

Data Type Semantics:: default

Additional Information:: See Section 2 of for more details about the SRv6 Segment List.

Reference:: [RFC-to-be]

Name:: srhSegmentsIPv6Left

ElementID:: TBD7

Description:: 8-bit unsigned integer defining the number of segments remaining to reach the end of the Segment List in the SRH.

Abstract Data Type:: unsigned8

Data Type Semantics:: quantity

Additional Information:: Specified by the "Segments Left" field in Section 4.4 of and mentioned in Section 2 of ).

Reference:: [RFC-to-be]

Name:: srhIPv6Section

Description:: The SRH and its TLVs as defined in Section 2 of as a series of octets in IPFIX.

Abstract Data Type:: octetArray

Data Type Semantics:: default

Additional Information:: See Section 2 of for more details about the structure of an SRH.

Reference:: [RFC-to-be]

Name:: srhIPv6ActiveSegmentType

ElementID:: TBD9

Description:: The name of the routing protocol or PCEP extension from where the active SRv6 segment has been learned from. Values for this Information Element are listed in the "IPFIX IPv6 SRH Segment type" subregistry, see .

Abstract Data Type:: unsigned8

Data Type Semantics:: identifier

Additional Information:: See the assigned types in [IPFIX IPv6 SRH Segment Type Subregistry].
Note to IANA:: Please replace [IPFIX IPv6 SRH Segment Type Subregistry] with the URL of the IANA subregistry.

Reference:: [RFC-to-be]

This document requests IANA to create a new subregistry called "IPFIX IPv6 SRH Segment Type" () under the "IPFIX Information Elements" registry available at . The allocation policy of this new subregistry is Expert Review (Section 4.5 of ). The designed experts for this registry should be familiar with SRH. The guidelines that are being followed by the designated experts for the IPFIX registry should be followed for this subregistry. In particular, criteria that should be applied by the designated experts include determining whether the proposed registration duplicates existing entries and whether the registration description is clear and fits the purpose of this registry. Within the review period, the designated experts will either approve or deny the registration request, communicating this decision to IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Initial values in the registry are defined in Table 2.

| +-------+--------------------+---------------------------------------+ | TBD14 | Path Computation | [RFC-to-be], | +-------+--------------------+---------------------------------------+ | TBD15 | OSPFv3 | [RFC-to-be],| +-------+--------------------+---------------------------------------+ | TBD16 | IS-IS | [RFC-to-be], | | | Segment Routing | | +-------+--------------------+---------------------------------------+ | TBD17 | BGP Segment | [RFC-to-be], | | | Routing Prefix-SID | | +-------+--------------------+---------------------------------------+ Table 2: "IPFIX IPv6 SRH Segment Type" Subregistry ]]>

Name:: srhSegmentIPv6LocatorLength

ElementID:: TBD10

Description:: The SRH segment IPv6 locator length specified as the number of significant bits. Together with srhSegmentIPv6 it enables the calculation of the SRv6 Locator.

Abstract Data Type:: unsigned8

Data Type Semantics:: default

Additional Information:: See Section 3.1 of for more details about the SID format.

Reference:: [RFC-to-be]

Name:: srhSegmentIPv6EndpointBehavior

ElementID:: TBD11

Description:: The 16-bit unsigned integer that represents a SRv6 Endpoint behavior as per Section 4 of . Assigned values and their meanings are provided in the "SRV6 Endpoint Behavior" registry.

Abstract Data Type:: unsigned16

Data Type Semantics:: identifier

Additional Information:: See the assigned behaviors at the "SRv6 Endpoint Behavior" registry available at https://www.iana.org/assignments/segment-routing/segment-routing.xhtml#srv6-endpoint-behaviors. See Section 4 of for more details about the endpoint behaviors processing.

Reference:: [RFC-to-be]

The zero or more 128-bit IPv6 addresses in the SRH [RFC8754] can be exported in two different ways, with two different IPFIX IEs: srhSegmentIPv6BasicList srhSegmentIPv6ListSection The srhSegmentIPv6BasicList encodes the SRv6 Segment List with a basicList, specified in the IPFIX Structured Data . This encoding offers the advantage to the data collection that the different IPv6 addresses are already structured as a list, without the need of post processing. However, this method requires some extra processing on the exporter, to realize the BasicList data mapping. The srhSegmentIPv6ListSection, on the other hand, encodes the list of IPv6 addresses as an octetArray. This doesn't impose any data flow manipulation on the exporter, facilitating the immediate export. However, the data collection MUST be able to decode the IPv6 addresses according to the SR specifications. Compared to the srhSegmentIPv6BasicList, the srhSegmentIPv6ListSection flow records length is slightly reduced. It is not expected that an exporter would support both srhSegmentIPv6BasicList and srhSegmentIPv6ListSection at the same time.

The SRv6 Segment List in the IPFIX IEs srhSegmentIPv6BasicList and srhSegmentIPv6ListSection could contain compressed-SID containers as described in . The SR Endpoint Flavors, described in Section 4 of defines new flavors for SID endpoint behaviors, and determine wherever the Segment List encoding is compressed, along with the flavor. The SID Locator as described in Section 3.1 of , determines the common most significant bits.

If multiple SRHs are observed (for reasons that are not detailed here), the export of the same IE multiple times in one data record and related template record is supported and the order within the packet SHOULD be preserved in the IPFIX export according to Section 8 of . If the network node is not capable to export IPFIX for more than one SRH, it MUST export IPFIX for the SRH of the active segment.

The authors would like to thank Yao Liu, Eduard Vasilenko, Bruno Decraene, Mohamed Boucadair, Kamran Raza, Qin Wu, Jim Guichard, Tero Kivinen, Paul Aitken and Roman Danyliw for their review and valuable comments, and Paolo Lucente and Alex Huang Feng for the implementation and validation.

Note to the RFC-Editor: Please remove this section before publishing.

INSA Lyon implemented the following IEs as part of a prototype in the FD.io VPP (Vector Packet Processing) platform: srhActiveSegmentIPv6 srhSegmentIPv6EndpointBehavior srhSegmentsIPv6Left srhFlagsIPv6 srhTagIPv6 srhSegmentIPv6ListSection srhSegmentIPv6BasicList The open source code can be obtained here: and was validated at the IETF 115 hackathon.

Huawei implemented the following IEs as part of a a production implementation in the VRP platform: srhActiveSegmentIPv6 srhSegmentsIPv6Left srhFlagsIPv6 srhTagIPv6 srhSegmentIPv6ListSection The implementation was validated at the IETF 115 hackathon.

Paolo Lucente implemented the IE srhSegmentIPv6ListSection decomposition as part of a a production implementation in the open source Network Telemetry data collection project pmacct. The source code can be obtained here: and was validated at the IETF 115 hackathon.

There exists no extra security considerations regarding allocation of these new IPFIX IEs compared to . The IEs described in this document export provider plane data metrics on how packets are being forwarded within a SRv6 network. Applications and operators using the IEs described in this document must evaluate the sensitivity of this information in their implementation context, and apply the data-at-rest storage guidance in Section 11.8 of as appropriate.

IANA, "IP Flow Information Export (IPFIX) Entities" INSA Lyon, FD.io VPP implementation Paolo Lucente, Pmacct open source Network Telemetry Data Collection

This appendix represents three different encodings for the newly introduced IEs, for the example values in Table 3. The three different encodings use the following IEs, respectively: srhSegmentIPv6BasicList, srhSegmentIPv6ListSection, and srhIPv6Section.

With encoding in Figure 1, the examples in Table 3 are represented with the following IEs: “=>” is used to indicate which IE is mapped to a given information. SR Flags => srhFlagsIPv6 (TBD1) SR Tag => srhTagIPv6 (TBD2) Active Segment Type => srhIPv6ActiveSegmentType (TBD9) Segment List => srhSegmentIPv6BasicList (TBD5)

In this example, the Template ID is 256, which will be used in the Data Record. The field length for srhSegmentIPv6BasicList is 0xFFFF, which means the length of this IE is variable, and the actual length of this IE is indicated by the List Length field in the basicList format as per . The data set is represented as follows:

With encoding in Figure 3, the examples in Table 3 are represented with the following IEs: “=>” is used to indicate which IE is mapped to a given information. SR Flags => srhFlagsIPv6 (TBD1) SR Tag => srhTagIPv6 (TBD2) Active Segment Type => srhIPv6ActiveSegmentType (TBD9) Segment List => srhSegmentIPv6ListSection (TBD6)

In this example, the Template ID is 257, which will be used in the Data Record. The field length for srhSegmentIPv6ListSection in the Template Record is 0xFFFF, which means that the length of this IE is variable: its actual length is encoded in the Data Set. Note that, with an actual length inferior to 255 in the Data Record example, the length field is encoded in 8 bits (Section 7 of ). The data can be represented as follows:

With encoding in Figure 5, the examples in Table 3 are represented with the following IEs: “=>” is used to indicate which IE is mapped to a given information. SR Flags + SR Tag + Segment List => srhIPv6Section (TBD8) Active Segment Type => srhIPv6ActiveSegmentType (TBD9)

In this example, the Template ID is 258, which will be used in the Data Record. The field length for srhIPv6Section in the Template Record is 0xFFFF, which means that the length of this IE is variable: its actual length is encoded in the Data Set. Note that, with an actual length inferior to 255 in the Data Record example, the length field is encoded in 8 bits (Section 7 of ). The data can be represented as follows:

(*) The Length must be calculated to include the optional Type Length Value objects.

This appendix provides an SRv6 EndPoint Bevahior Options Template example, for the values presented in Table 4. In the Options Template case, the srhActiveSegmentIPv6 Information Element is a Scope field

In this example, the Template ID is 259, which will be used in the Data Record. The data set is represented as follows:

(*) The Length must be calculated to include the optional Type Length Value objects.