RFC 9487: Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)
- T. Graf,
- B. Claise,
- P. Francois
Abstract
This document introduces new IP Flow Information Export (IPFIX) Information Elements (IEs) to identify a set of information related to Segment Routing over IPv6 (SRv6) such as data contained in a Segment Routing Header (SRH), the SRv6 control plane, and the SRv6 Endpoint behavior that traffic is being forwarded with.¶
Status of This Memo
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://
1. Introduction
A dedicated Routing Extension Header, called "Segment Routing Header (SRH)", is defined in [RFC8754] for use of Segment Routing over IPv6 (SRv6) data plane.¶
Also, three routing protocol extensions, OSPFv3 [OSPFV3-SRV6-EXT], IS-IS [RFC9352], and BGP Prefix Segment Identifiers (Prefix-SIDs) [RFC8669]; the Path Computation Element Communication Protocol (PCEP) Extension [PCEP-SRV6-EXT]; and the Segment Routing Policy [RFC9256] 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 [RFC8986].¶
This document specifies eleven new IPFIX Information Elements (IEs) and one new subregistry within the "IPFIX Information Elements" registry [RFC7012], 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.¶
2. Terminology
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document makes use of the terms defined in [RFC7011], [RFC8402], and [RFC8754].¶
The following terms are used as defined in [RFC7011]:¶
The following terms are used as defined in [RFC8402]:¶
The following terms are used as defined in [RFC8754]:¶
3. New IPFIX IPv6 SRH Information Elements
This section specifies the new IPFIX IPv6 SRH IEs.¶
- srhFlagsIPv6
- The 8-bit Flags field defined in the SRH (Section 2 of [RFC8754]).¶
- srhTagIPv6
- The 16-bit Tag field defined in the SRH (Section 2 of [RFC8754]). A tag is used to mark a packet as part of a class or group of packets sharing the same set of properties.¶
- srhSegmentIPv6
- The 128-bit IPv6 address that represents an SRv6 segment.¶
- srh
Active Segment IPv6 - The 128-bit IPv6 address that represents the active SRv6 segment.¶
- srh
Segment IPv6Basic List - 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 [RFC8754], 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.¶
- srh
Segment IPv6List Section - The SRH Segment List as defined in Section 2 of [RFC8754] as a series of octets in IPFIX.¶
- srh
Segments IPv6Left - The 8-bit unsigned integer that defines 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 [RFC8200] and as mentioned in the SRH part of Section 2 of [RFC8754].¶
- srhIPv6Section
- The SRH and its TLVs as specified in Section 2 of [RFC8754] as a series of octets in IPFIX.¶
- srh
IPv6Active Segment Type - The designator of the routing protocol or PCEP extension where the active SRv6 segment has been learned from.¶
- srh
Segment IPv6Locator Length - The length of the SRH segment IPv6 locator specified as the number of significant bits. Together with srhSegmentIPv6, it enables the calculation of the SRv6 Locator.¶
- srh
Segment IPv6Endpoint Behavior - The 16-bit unsigned integer that represents an SRv6 Endpoint behavior as per Section 4 of [RFC8986].¶
Note that the srhSegmentIPv6, srh
4. Sample Use Cases
The IPFIX IEs srh
5. IANA Considerations
5.1. IPFIX Information Elements Registry
IANA has added the following new IEs to the "IPFIX Information Elements" registry [RFC7012] at [IANA-IPFIX]:¶
5.1.1. srhFlagsIPv6
- ElementID:
- 492¶
- Name:
- srhFlagsIPv6¶
- Abstract Data Type:
- unsigned8¶
- Data Type Semantics:
- flags¶
- Description:
- The 8-bit Flags field defined in the SRH (Section 2 of [RFC8754]). Assigned flags and their meanings are provided in the "Segment Routing Header Flags" IANA registry.¶
- Additional Information:
- See the assignments in the "Segment Routing Header Flags"
registry at <https://
www >. See also [RFC8754] for the SRH specification.¶.iana .org /assignments /ipv6 -parameters - Reference:
- RFC 9487¶
5.1.2. srhTagIPv6
- ElementID:
- 493¶
- Name:
- srhTagIPv6¶
- Abstract Data Type:
- unsigned16¶
- Data Type Semantics:
- identifier¶
- Description:
- The 16-bit Tag field defined in the SRH (Section 2 of [RFC8754]). A tag is used to mark a packet as part of a class or group of packets sharing the same set of properties.¶
- Additional Information:
- See Section 2 of [RFC8754] for more details about the Tag.¶
- Reference:
- RFC 9487¶
5.1.3. srhSegmentIPv6
- ElementID:
- 494¶
- Name:
- srhSegmentIPv6¶
- Abstract Data Type:
- ipv6Address¶
- Data Type Semantics:
- default¶
- Description:
- The 128-bit IPv6 address that represents an SRv6 segment.¶
- Additional Information:
- Specified in Section 1 of [RFC8402] and mentioned in "Segment List" in Section 2 of [RFC8754].¶
- Reference:
- RFC 9487¶
5.1.5. srhSegmentIPv6BasicList
- ElementID:
- 496¶
- Name:
- srh
Segment IPv6Basic List¶ - Abstract Data Type:
- basicList¶
- Data Type Semantics:
- list¶
- 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 [RFC8754], 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.¶
- Additional Information:
- See Section 2 of [RFC8754] for more details about the SRv6 Segment List.¶
- Reference:
- RFC 9487¶
5.1.6. srhSegmentIPv6ListSection
- ElementID:
- 497¶
- Name:
- srh
Segment IPv6List Section¶ - Abstract Data Type:
- octetArray¶
- Data Type Semantics:
- default¶
- Description:
- The SRv6 Segment List as defined in Section 2 of [RFC8754] as a series of octets in IPFIX.¶
- Additional Information:
- See Section 2 of [RFC8754] for more details about the SRv6 Segment List.¶
- Reference:
- RFC 9487¶
5.1.7. srhSegmentsIPv6Left
- ElementID:
- 498¶
- Name:
- srh
Segments IPv6Left¶ - Abstract Data Type:
- unsigned8¶
- Data Type Semantics:
- quantity¶
- Description:
- The 8-bit unsigned integer defining the number of segments remaining to reach the end of the Segment List from the SRH.¶
- Additional Information:
- Specified by the "Segments Left" field in Section 4.4 of [RFC8200] and mentioned in Section 2 of [RFC8754].¶
- Reference:
- RFC 9487¶
5.1.8. srhIPv6Section
- ElementID:
- 499¶
- Name:
- srhIPv6Section¶
- Abstract Data Type:
- octetArray¶
- Data Type Semantics:
- default¶
- Description:
- The SRH and its TLVs as defined in Section 2 of [RFC8754] as a series of octets in IPFIX.¶
- Additional Information:
- See Section 2 of [RFC8754] for more details about the structure of an SRH.¶
- Reference:
- RFC 9487¶
5.1.9. srhIPv6ActiveSegmentType
- ElementID:
- 500¶
- Name:
- srh
IPv6Active Segment Type¶ - Abstract Data Type:
- unsigned8¶
- Data Type Semantics:
- identifier¶
- Description:
- The designator of the routing protocol or PCEP extension where the active SRv6 segment has been learned from. Values for this Information Element are listed in the "IPFIX IPv6 SRH Segment Type (Value 500)" subregistry.¶
- Additional Information:
- See the assigned types in the "IPFIX IPv6 SRH Segment (Value 500)" registry at <https://
www >.¶.iana .org /assignments /ipfix - Reference:
- RFC 9487¶
5.1.10. srhSegmentIPv6LocatorLength
- ElementID:
- 501¶
- Name:
- srh
Segment IPv6Locator Length¶ - Data Type Semantics:
- default¶
- Description:
- The length of the SRH segment IPv6 locator specified as the number of significant bits. Together with srhSegmentIPv6, it enables the calculation of the SRv6 Locator.¶
- Additional Information:
- See Section 3.1 of [RFC8986] for more details about the SID format.¶
- Reference:
- RFC 9487¶
5.1.11. srhSegmentIPv6EndpointBehavior
- ElementID:
- 502¶
- Name:
- srh
Segment IPv6Endpoint Behavior¶ - Abstract Data Type:
- unsigned16¶
- Data Type Semantics:
- identifier¶
- Description:
- The 16-bit unsigned integer that represents an SRv6 Endpoint behavior as per Section 4 of [RFC8986]. Assigned values and their meanings are provided in the "SRv6 Endpoint Behaviors" registry.¶
- Additional Information:
- See the assigned behaviors in the "SRv6 Endpoint Behaviors"
registry at <https://
www >. See Section 4 of [RFC8986] for more details about the processing of endpoint behaviors.¶.iana .org /assignments /segment -routing - Reference:
- RFC 9487¶
5.2. New IPFIX IPv6 SRH Segment Type (Value 500) Subregistry
IANA has created a new subregistry called "IPFIX IPv6 SRH Segment Type (Value 500)" under the "IPFIX Information Elements" registry [RFC7012] at [IANA-IPFIX].¶
The allocation policy of this new subregistry is Expert Review (Section 4.5 of [RFC8126]).¶
The designated experts for this registry should be familiar with SRH. The guidelines that are being followed by the designated experts for the "IPFIX Information Elements" 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.¶
6. Operational Considerations
6.1. SRv6 Segment List
The zero or more 128-bit IPv6 addresses in the SRH [RFC8754] can be exported in two different ways, with two different IPFIX IEs:¶
The srh
The srh
It is not expected that an exporter would support both
srh
6.2. Compressed SRv6 Segment List Decomposition
The SRv6 Segment List in the IPFIX IEs srh
7. Security Considerations
There are no additional security considerations regarding allocation of these new IPFIX IEs compared to [RFC7012].¶
The IEs described in this document export provider plane data metrics on how packets are being forwarded within an 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 [RFC7011] as appropriate.¶
8. References
8.1. Normative References
- [RFC2119]
-
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10
.17487 , , <https:///RFC2119 www >..rfc -editor .org /info /rfc2119 - [RFC6313]
-
Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, DOI 10
.17487 , , <https:///RFC6313 www >..rfc -editor .org /info /rfc6313 - [RFC7011]
-
Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10
.17487 , , <https:///RFC7011 www >..rfc -editor .org /info /rfc7011 - [RFC7012]
-
Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10
.17487 , , <https:///RFC7012 www >..rfc -editor .org /info /rfc7012 - [RFC8126]
-
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10
.17487 , , <https:///RFC8126 www >..rfc -editor .org /info /rfc8126 - [RFC8174]
-
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10
.17487 , , <https:///RFC8174 www >..rfc -editor .org /info /rfc8174 - [RFC8200]
-
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10
.17487 , , <https:///RFC8200 www >..rfc -editor .org /info /rfc8200 - [RFC8754]
-
Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10
.17487 , , <https:///RFC8754 www >..rfc -editor .org /info /rfc8754
8.2. Informative References
- [IANA-IPFIX]
-
IANA, "IP Flow Information Export (IPFIX) Entities", <https://
www >..iana .org /assignments /ipfix - [OSPFV3
-SRV6 -EXT] -
Li, Z., Hu, Z., Talaulikar, K., Ed., and P. Psenak, "OSPFv3 Extensions for SRv6", Work in Progress, Internet-Draft, draft
-ietf , , <https://-lsr -ospfv3 -srv6 -extensions -15 datatracker >..ietf .org /doc /html /draft -ietf -lsr -ospfv3 -srv6 -extensions -15 - [PCEP-SRV6-EXT]
-
Li, C., Kaladharan, P., Sivabalan, S., Koldychev, M., and Y. Zhu, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing leveraging the IPv6 dataplane", Work in Progress, Internet-Draft, draft
-ietf , , <https://-pce -segment -routing -ipv6 -20 datatracker >..ietf .org /doc /html /draft -ietf -pce -segment -routing -ipv6 -20 - [RFC7270]
-
Yourtchenko, A., Aitken, P., and B. Claise, "Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX)", RFC 7270, DOI 10
.17487 , , <https:///RFC7270 www >..rfc -editor .org /info /rfc7270 - [RFC8402]
-
Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10
.17487 , , <https:///RFC8402 www >..rfc -editor .org /info /rfc8402 - [RFC8669]
-
Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, A., and H. Gredler, "Segment Routing Prefix Segment Identifier Extensions for BGP", RFC 8669, DOI 10
.17487 , , <https:///RFC8669 www >..rfc -editor .org /info /rfc8669 - [RFC8986]
-
Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10
.17487 , , <https:///RFC8986 www >..rfc -editor .org /info /rfc8986 - [RFC9256]
-
Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10
.17487 , , <https:///RFC9256 www >..rfc -editor .org /info /rfc9256 - [RFC9352]
-
Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B., and Z. Hu, "IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane", RFC 9352, DOI 10
.17487 , , <https:///RFC9352 www >..rfc -editor .org /info /rfc9352 - [SRV6-SRH-COM]
-
Cheng, W., Ed., Filsfils, C., Li, Z., Decraene, B., and F. Clad, Ed., "Compressed SRv6 Segment List Encoding", Work in Progress, Internet-Draft, draft
-ietf , , <https://-spring -srv6 -srh -compression -09 datatracker >..ietf .org /doc /html /draft -ietf -spring -srv6 -srh -compression -09
Appendix A. IPFIX Encoding Examples
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:
srh
A.1. Three Observed SRH Headers and Their Routing Protocols
A.1.1. Template Record and Data Set with Segment Basic List
With encoding in Figure 1, the examples in Table 3 are represented with the following IEs, where "=>" is used to indicate which IE is mapped to given information:¶
In this example, the Template ID is 256, which will be used in
the Data Record. The field length for srh
The data set is represented as follows:¶
A.1.2. Template Record and Data Set with Segment List Section
With encoding in Figure 3, the examples in Table 3 are represented with the following IEs, where "=>" is used to indicate which IE is mapped to given information:¶
In this example, the Template ID is 257, which will be used in
the Data Record. The field length for srh
The data can be represented as follows:¶
A.1.3. Template Record and Data Set with SRH Section
With encoding in Figure 5, the examples in Table 3 are represented with the following IEs, where "=>" is used to indicate which IE is mapped to given information:¶
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 [RFC7011]).¶
The data can be represented as follows:¶
(*) The Length must be calculated to include the optional Type Length Value objects.¶
A.2. Options Template Record and Data Set for SRv6 Segment Endpoint Behavior and Locator Length
This appendix provides an SRv6 Endpoint Behavior Options Template
example, for the values presented in Table 4. In the
Options Template case, the srh
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.¶
Acknowledgements
The authors would like to thank Yao Liu, Eduard Vasilenko, Bruno Decraene, Mohamed Boucadair, Kamran Raza, Qin Wu, Jim Guichard, Tero Kivinen, Paul Aitken, Roman Danyliw, John Scudder, Éric Vyncke, Erik Kline, Lars Eggert, and Andrew Alston for their reviews and valuable comments. And thank you to Paolo Lucente and Alex Huang Feng for the implementation and validation.¶