Swisscom

Binzring 17 Zurich 8045 Switzerland thomas.graf@swisscom.com

Huawei

benoit.claise@huawei.com

INSA-Lyon

Lyon France pierre.francois@insa-lyon.fr

This document introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of Segment Routing over IPv6 (SRv6) related information such as data contained in a Segment Routing Header (SRH), the SRv6 control plane, and the SRv6 behavior that traffic is being forwarded with.

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 one Path Computation Element Communication Protocol (PCEP) Extension are defined to propagate Segment Identifiers (SIDs). SRv6 segment endpoint behaviors are defined in and describe how packets should be processed by intermediate nodes. This document specifies eleven new IPFIX Information Elements (IEs) and three new subregistries within the "IPFIX Information Elements" registry , for SRv6 purposes. These IEs are used to export SRv6 active segment and its control plane protocol, the SRv6 segment list, the next SRv6 node and its type, and then 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 .

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 that 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 an 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. Exposes the SRH Segment List as defined in Section 2 of as series of n octets in IPFIX. 8-bit unsigned integer defining the number of segments remaining to reach the end of the segment list. Exposes the SRH and its TLVs as specified in Section 2 of as series of n octets in IPFIX. Name of the routing protocol or PCEP extension from where the active SRv6 segment has been learned from. 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, srhSegmentLocatorLength, and srhSegmentEndpointBehavior 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), srhSegmentIPv6sLeft (TBD7), srhActiveSegmentIPv6Type(TBD9), forwardingStatus(89) , and some existing counters information allows to provide answers to the following (amongst others): How many packets 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?

This document requests IANA to create new IEs (see table 1) and three new subregistries called "IPFIX IPv6 SRH Flags" (table 2), "IPFIX IPv6 SRH Segment Type" (table 3), and "IPFIX SRv6 Endpoint Behavior" (table 4) under the "IPFIX Information Elements" registry available at .

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

Name:

srhFlagsIPv6

ElementID:

TBD1

Description:

This Information Element identifies the 8-bit flags defined in the SRH. Values for this Information Element are listed in the "IPFIX IPv6 SRH Flags" registry, see . srhFlagsIPv6 values must not be directly added to this "IPFIX IPv6 SRH Flags" registry. They must instead be added to the "Segment Routing Header Flags" registry. Both the "IPFIX IPv6 SRH Flags" and the "Segment Routing Header Flags" registries must be kept in synch. Initial values in the registry are defined by the table below.

Note to IANA:

Add a note to the "IPFIX SRV6 Endpoint Behavior" registry so that new values are echoed in the new "IPFIX SRv6 EndPoint Behavior

Abstract Data Type:

unsigned8

Data Type Semantics:

flags

Reference:

[RFC-to-be], RFC8754

Name:

srhTagIPv6

ElementID:

TBD2

Description:

This IE identifies the 16-bit tag field defined in the SRH that marks 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

Reference:

[RFC-to-be], RFC8754

Name:

srhSegmentIPv6

ElementID:

TBD3

Description:

This Information Element identifies the 128-bit IPv6 address that represents an SRv6 segment.

Abstract Data Type:

ipv6address

Data Type Semantics:

default

Reference:

[RFC-to-be], RFC8754

Name:

srhActiveSegmentIPv6

ElementID:

TBD4

Description:

This Information Element identifies the 128-bit IPv6 address that represents the active SRv6 segment.

Abstract Data Type:

ipv6address

Data Type Semantics:

default

Reference:

[RFC-to-be], RFC8754

Name:

srhSegmentIPv6BasicList

ElementID:

TBD5

Description:

This Information Element identifies the Ordered basicList [RFC6313] of zero or more 128-bit IPv6 addresses in the SRH that represents the SRv6 segment list. As described 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

Reference:

[RFC-to-be], RFC8754

Name:

srhSegmentIPv6ListSection

ElementID:

TBD6

Description:

Exposes the SRH Segment List as defined in section 2 of as series of n octets.

Abstract Data Type:

octetArray

Data Type Semantics:

default

Reference:

[RFC-to-be], RFC8754

Name:

srhSegmentIPv6sLeft

ElementID:

TBD7

Description:

This Information Element identifies the 8-bit unsigned integer defining the number of route segments remaining to reach the end of the segment list.

Abstract Data Type:

unsigned8

Data Type Semantics:

quantity

Reference:

[RFC-to-be], RFC8754

Name:

srhSectionIPv6

Description:

This IE exposes the SRH and its TLVs as defined in Section 2 of as series of n octets.

Abstract Data Type:

octetArray

Data Type Semantics:

default

Reference:

[RFC-to-be], RFC8754

Name:

srhActiveSegmentIPv6Type

ElementID:

TBD9

Description:

This IE identifies 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 . Initial values in the registry are defined by the table below. New assignments of values will be administered by IANA and are subject to Expert Review . Experts need to check definitions of new values for completeness, accuracy, and redundancy.

| +-------+--------------------+--------------------------------------+ Table 3: "IPFIX IPv6 SRH Segment type" subregistry ]]>

Abstract Data Type:

unsigned8

Data Type Semantics:

identifier

Reference:

[RFC-to-be]

Name:

srhSegmentLocatorLength

ElementID:

TBD10

Description:

This Information Element identifies the number of significant bits and together with srhSegmentIPv6 enables the calculation of the SRv6 Locator.

Abstract Data Type:

unsigned8

Data Type Semantics:

default

Reference:

[RFC-to-be], RFC8986 Section 3.1

Name:

srhSegmentEndpointBehavior

ElementID:

TBD11

Description:

This Information Element identifies the 16-bit SRv6 Endpoint behavior. Values for this Information Element are listed in the "IPFIX SRV6 Endpoint Behavior" registry, see . srhSegmentEndpointBehavior values must not be directly added to this "IPFIX SRV6 Endpoint Behavior" registry. They must instead be added to the "Segment Routing SRv6 Endpoint Behaviors" registry. Both the "IPFIX SRV6 Endpoint Behavior" and the "Segment Routing SRv6 Endpoint Behaviors" registries must be kept in synch.

Note to IANA:

Add a note to the "IPFIX SRV6 Endpoint Behavior" registry so that new values are echoed in the new "IPFIX SRv6 EndPoint Behavior

Abstract Data Type:

unsigned16

Data Type Semantics:

identifier

Reference:

[RFC-to-be], RFC8986 Section 4

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 SID list of IPv6 addresses 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 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 SID endpoint behaviors described in section 4 of determine wherever the segment list is compressed or not. The SID Locator as described in section 3.1 , determines the common most significant bits.

describes the support of multiple extension headers in one IPv6 packet. Allowing the use of multiple SRH per SRv6 packet. The export of the same IE multiple times in one data-record and data-template 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 active SRH.

There exists no significant extra security considerations regarding the allocation of these new IPFIX IEs compared to .

The authors would like to thank Yao Liu, Paolo Lucente, Eduard Vasilenko, Alex Huang Feng, Bruno Decraene and Mohamed Boucadair for their review and valuable comments.

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

With encoding in Figure 1, the examples in Table 5 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 => srhActiveSegmentIPv6Type (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 5 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 => srhActiveSegmentIPv6Type (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 is 0xFFFF, which means the length of this IE is variable. The data can be represented as follows:

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

In this example, the Template ID is 258, which will be used in the Data Record. The field length for srhSectionIPv6 is 0xFFFF, which means the length of this IE is variable. 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 12. In the Options Template case, the srhEndPointIPv6 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.