Export of IGP Algorithm Information in IPFIX

Introduction A Flexible Algorithm Definition (FAD) is the triplet (calculation-type, metric-type, and constraints). A Flexible Algorithm is identified by an IGP Algorithm value in the range 128-255. allows IGPs (IS-IS, OSPFv2 and OSPFv3) to compute constraint-based path over an SR-MPLS or an SRv6 network. In SR, the same prefix can be associated with multiple algorithms. comments that, besides the SR-MPLS prefix SID, the algorithm can be also included as part of an SR-MPLS Adjacency-SID advertisement in scenarios where multiple algorithms share the same link resource. The IANA "IGP Algorithm Types" registry defines the set of values for IGP Algorithms. The registry currently includes the default algorithm (value 0), Strict Shortest Path First (Strict-SPF, value 1), and Flexible Algorithms (values 128-255), while other values (e.g., 2-127) are unassigned. further extends IGP Flexible Algorithm so that it can be used with regular IPv4 and IPv6 forwarding. As in , for the regular IP forwarding, the currently standardized IGP Algorithm Types are the default algorithm (0) and Flex-Algorithms (128-255). IS-IS and OSPFv2 allow a single IGP domain to run multiple independent logical topologies, each identified by a Multi-Topology Identifier (MT-ID). A Flexible Algorithm Definition (FAD) is topology independent, but the forwarding paths computed for an algorithm can differ between topologies. Multi-Topology (MT) is therefore another dimension of the selected forwarding entry:

In SRv6, the SRv6 Locator advertisement in IS-IS includes the MT-ID and the algorithm value, as specified in , paths to the locator are calculated using the specified Flex-Algorithm in the associated topology.
In SR-MPLS, the source of the topology association is protocol specific. An IS-IS Prefix-SID inherits its topology from the parent prefix-reachability advertisement, as specified in . An OSPFv2 Prefix-SID Sub-TLV carries an explicit MT-ID, as specified in . The OSPFv3 Prefix-SID Sub-TLV does not carry an MT-ID, as specified in . This document does not define an OSPFv3 mapping for igpMultiTopologyId. When igpMultiTopologyId is exported for an OSPFv2 Prefix-SID, it MUST be derived from the MT-ID in that Prefix-SID Sub-TLV. When the advertised algorithm value is a Flex-Algorithm, the Prefix-SID is associated with paths calculated using that Flex-Algorithm in the applicable topology.
In IP, the IS-IS IPv4 and IPv6 Algorithm Prefix Reachability TLVs and the OSPFv2 IP Algorithm Prefix Reachability Sub-TLV in carry an MT-ID, binding an IP prefix to a topology and a Flex-Algorithm. The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV in does not carry an MT-ID.

Consequently, the same IGP Algorithm value can select different forwarding paths in different topologies without changing the FAD. Below are the typical use cases when monitoring a traffic flow in a network with IGP Algorithm (especially Flexible Algorithm) enabled.

Which IGP Algorithm is associated with the forwarding entry selected for an SR-MPLS SID or an active SRv6 SID?
Which IGP Algorithm is associated with the forwarding entry selected for an IPv4 or IPv6 destination?

The forwarding object alone does not provide the algorithm and topology information that was used for the observed packet. This document introduces new IP Flow Information Export (IPFIX) information elements (IEs) to identify the IGP Algorithm and MT-ID associated with the selected forwarding entry.

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 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
Metering Process
Template Record
Data Record
Collector

The following terms are used as defined in :

Segment Routing (SR)
Segment List
SRv6
SR-MPLS
Segment Identifier (SID)

The following term is used as defined in Section 3.1 of :

(IGP) Algorithm

The following term is used as defined in Section 4 of :

Flexible Algorithm

IGP Algorithm Information in IPFIX A new IE "igpAlgo" is defined in this document. It reports the IGP Algorithm Type associated with the forwarding entry selected for the observed packet. It does not report a stable control-plane association for a SID, locator, or prefix.

Name:: igpAlgo
ElementID:: TBD1
Description:: The 8-bit value that represents the IGP Algorithm Type associated with the FIB or LFIB entry selected by the forwarding lookup used for the observed packet at the Observation Point. The value is taken from the IANA "IGP Algorithm Types" registry , which is authoritative for codepoint assignments. At the time of publication, value 0 indicates the default algorithm, value 1 indicates Strict Shortest Path First (Strict-SPF), and values 128-255 indicate Flex-Algorithms. For a Flexible Algorithm forwarding entry, this IE carries the Flex-Algorithm identifier in the range 128-255. It MUST NOT carry the Calc-Type, Metric-Type, or constraints from the Flexible Algorithm Definition.
Abstract Data Type:: unsigned8
Data Type Semantics:: identifier
Additional Information:: Specified in Section 3.1 of , Section 4 of , and .
Reference:: This document.

MT-ID Information in IPFIX A new IE "igpMultiTopologyId" is defined in this section. It reports the Multi-Topology Identifier (MT-ID) associated with the forwarding entry selected for the observed packet.

Name:: igpMultiTopologyId
ElementID:: TBD2
Description:: The unsigned16 value that represents the protocol-defined MT-ID associated with the FIB or LFIB entry selected by the forwarding lookup used for the observed packet at the Observation Point. For IS-IS, the low-order 12 bits contain the MT-ID defined by and the high-order four bits MUST be zero. For OSPFv2, the low-order seven bits contain the MT-ID in the range 0-127 defined by and the high-order nine bits MUST be zero.
Abstract Data Type:: unsigned16
Data Type Semantics:: identifier
Range:: 0-4095
Additional Information:: Specified in , , Section 5 of , , and .
Reference:: This document.

This document does not define how to derive igpMultiTopologyId for an OSPFv3 forwarding entry. An exporter MUST NOT export igpMultiTopologyId for such an entry unless an applicable specification defines the mapping.

Operational Considerations

Operational Considerations for igpAlgo

Considerations for SR-MPLS For an SR-MPLS flow, the exporter MUST derive igpAlgo from the installed LFIB entry selected by the top-label lookup for the observed packet. The top label and its companion IEs MUST describe the packet before that label is processed. mplsTopLabelType(46) values 7 (OSPFv2 Segment Routing), 8 (OSPFv3 Segment Routing), and 9 (IS-IS Segment Routing) identify the protocol that allocated the top label . These values do not identify the label, the SID role, or the selected LFIB entry. They provide useful allocation context, but they are neither necessary nor sufficient to determine igpAlgo. An exporter MUST NOT use mplsTopLabelType(46) alone to determine igpAlgo. A conventional Adj-SID has no Algorithm field. An exporter MUST NOT specify igpAlgo for a conventional Adj-SID. An exporter MAY specify igpAlgo for an Adj-SID only when the selected LFIB entry is associated with an algorithm-specific Adj-SID defined by . This includes the local LFIB entry installed for a locally originated algorithm-specific Adj-SID. In that case, the igpAlgo value MUST be in the range 128-255. A Template Record that specifies igpAlgo for SR-MPLS SHOULD also specify the following IEs:

mplsTopLabelType(46), which identifies the protocol that allocated the top label.
mplsTopLabelStackSection(70), which carries the Label, Exp, and S fields of the top MPLS label stack entry.
observationPointId(138). If the incoming label space is interface specific, the Template Record MUST also specify ingressInterface(10).

The exporter and collector MUST have an unambiguous mapping from the exporter, Observation Domain, Observation Point, and applicable interface to the label space and routing context used for the lookup. Section 5.1.4 specifies the common context and ambiguity rules.

Considerations for SRv6 SRv6 IGP advertisements are specified in , , and . binds the Flex-Algorithm to an SRv6 locator, not to an individual SID. Under and , an SRv6 End SID inherits its algorithm from its parent locator. An SRv6 adjacency SID carries an Algorithm field and MUST be covered by a locator with the matching algorithm. When an exporter specifies igpAlgo for a locally instantiated SRv6 SID as described in , it MUST derive the value from the applicable locator or adjacency-SID association and bind that association to the FIB entry selected by the SRv6 lookup. If the exporter cannot make this binding unambiguously, the Template omission rule in Section 5.1.4 applies. For an SRv6 flow, the exporter MUST derive igpAlgo from the installed FIB entry that wins the forwarding plane longest-prefix-match (LPM) lookup for the active SID. If a more-specific locator or an ordinary IPv6 prefix wins over the nominal SRv6 locator, igpAlgo MUST describe the winning entry. For an SRv6 packet with an SRH, a Template Record that specifies igpAlgo SHOULD also specify srhActiveSegmentIPv6(495), srhIPv6ActiveSegmentType(500), destinationIPv6Prefix(169), and destinationIPv6PrefixLength(30) . The active segment and its companion IEs MUST describe the packet before the local SID is processed. The prefix and prefix length MUST identify the exact installed prefix that won the same LPM lookup from which igpAlgo was derived. As specified in , srhIPv6ActiveSegmentType(500) identifies the routing protocol or PCEP extension from which the active segment was learned. The recommendation to include this IE gives this control-plane source context to the collector. The IE does not identify the active SID or the selected FIB entry. An exporter MUST NOT use this IE alone to decide whether igpAlgo applies or to derive the igpAlgo value. For an SRv6 packet without an SRH, the forwarding lookup key is the IPv6 Destination Address before local SID processing. The Destination Address can contain a compressed-SID container as specified in . Absence of an SRH does not imply a single logical segment. A Template Record that specifies igpAlgo SHOULD also specify destinationIPv6Address(28), destinationIPv6Prefix(169), and destinationIPv6PrefixLength(30). The prefix and prefix length MUST identify the exact installed prefix that won the Destination Address lookup. An Options Template or Structured Data association between srhSegmentIPv6(494) and srhSegmentIPv6LocatorLength(501), as described in , can provide locator metadata. Such an association does not identify the FIB entry that won an observed packet's LPM lookup and MUST NOT replace the destination prefix IEs in this section.

Considerations for Regular IPv4/IPv6 Forwarding For regular IPv4 or IPv6 forwarding, the exporter MUST derive igpAlgo from the installed destination FIB entry that wins the forwarding plane LPM lookup for the observed packet. The exporter reports value 0 when that entry was installed from ordinary IGP reachability. currently defines values 128-255 for IP Algorithm Prefix Reachability advertisements. An assignment in the IANA "IGP Algorithm Types" registry alone does not make that value applicable to regular IP forwarding. An exporter MUST NOT report any other value for this profile unless an applicable specification defines its use. A Template Record that specifies igpAlgo for regular IP forwarding SHOULD also specify the following IEs:

For IPv4, destinationIPv4Prefix(45) and destinationIPv4PrefixLength(13).
For IPv6, destinationIPv6Prefix(169) and destinationIPv6PrefixLength(30).

The prefix and prefix-length IEs MUST identify the exact installed prefix that won the same destination lookup from which igpAlgo was derived. They MUST NOT contain an unrelated Flow aggregation prefix. If the selected destination entry was installed by BGP, a static route, a connected route, or another non-IGP source, the exporter MUST use a Template Record that does not specify igpAlgo. Recursive resolution of such an entry through an IGP next hop does not associate the destination entry with that IGP Algorithm.

Generic Considerations For each Data Record, igpAlgo and, when present, igpMultiTopologyId MUST be derived from the same FIB or LFIB lookup. That lookup MUST be the profile-specific lookup defined in Sections 5.1.1 through 5.1.3. If a packet undergoes more than one sequential or recursive lookup, the exporter MUST select one lookup for the Data Record. Companion IEs that identify a label, SID, locator, or prefix MUST identify the lookup key or the selected entry for that same lookup. An exporter MUST NOT take the algorithm from one lookup or a control-plane association while it identifies the forwarding object from a different lookup. If the exporter cannot derive one unambiguous igpAlgo value from the selected forwarding entry and its required context, it MUST use a Template Record that does not specify igpAlgo for those Data Records. A collector MUST treat absence of igpAlgo as unavailable; it MUST NOT infer value 0. The IGP Algorithm Type associated with a forwarding entry can change while a Flow is active, for example because of IGP convergence, FAD changes, or locator withdrawal. The following rules apply:

When igpAlgo is a non-key IE in a Flow Record, it is derived from Packet Treatment, and the first-packet rule in Section 5 of applies by default.
When separate accounting for each IGP Algorithm is required, an exporter SHOULD include igpAlgo in the Flow Key so that packets forwarded under different algorithms are accounted in different Flow Records.

A Flex-Algorithm number is not globally unique. A collector can need the following context to interpret igpAlgo:

FAD advertisement scope. In OSPF, a FAD is normally scoped to an area; defines the conditions for use of AS flooding scope. In IS-IS, the FAD Sub-TLV has area or level scope, and the Router Capability TLV has the S bit clear. permits a configured L1/L2 router to regenerate the winning FAD, without modification, from L2 into an L1 area; it prohibits regeneration from L1 into L2.
Data plane. IP participation is advertised independently from Segment Routing participation. SR-MPLS and SRv6 can share the Segment Routing participation advertisement .
Routing context. The selected entry can differ between routing tables or VRFs.
Topology. A FAD is topology independent, but the selected paths and forwarding entries can differ between topologies.

A collector MAY obtain FADs and their advertisement scopes from BGP-LS or from network configuration. When a collector correlates igpAlgo with a FAD, or when more than one forwarding context can apply, the mapping used with a Flow Record MUST unambiguously identify the applicable IPFIX Exporting Process and Observation Domain, IGP protocol and instance, OSPF area or IS-IS area or level, data plane, routing table or VRF, and topology for the selected lookup. As specified in , a collector uses the Transport Session and Observation Domain ID to separate IPFIX export streams. If this mapping relies on an Observation Domain or observationPointId(138), the Observation Domain ID in the IPFIX Message Header MUST be nonzero. An Observation Domain ID identifies an IPFIX Observation Domain; it MUST NOT be interpreted as an IGP instance or routing-table identifier. observationPointId(138) is unique only within an Observation Domain, and ingressVRFID(234) is unique only within a Metering Process. The mapping can combine the Transport Session and Observation Domain ID with exporter or controller configuration, observationPointId(138), an applicable VRF IE such as ingressVRFID(234) or VRFname(236), and igpMultiTopologyId in the same Template Record. When more than one Metering Process can assign a context value, the mapping MUST also identify the applicable Metering Process, for example with meteringProcessId(143). If a mapping required by the preceding paragraph is unavailable or ambiguous, the exporter MUST apply the Template omission rule above. The Flow Record and its context determine the data plane. For SR-MPLS, mplsTopLabelStackSection(70) and the required forwarding-context mapping identify the SR-MPLS profile. When present, mplsTopLabelType(46) values 7-9 identify the allocating IGP. For SRv6 with an SRH, the SRH IEs identify SRv6. For SRv6 without an SRH, the mapping MUST identify the Destination Address lookup as SRv6. An IPv6 address alone does not distinguish regular IPv6 forwarding from SRv6 forwarding. The igpAlgo IE is scoped to a selected forwarding entry that has an unambiguous IGP Algorithm association under Sections 5.1.1 through 5.1.3. For SR-MPLS and SRv6, this includes a locally instantiated SID entry whose association is defined by an applicable IGP or IGP-SR specification; the local entry need not be installed by the IGP process. For regular IP, the selected destination entry MUST be installed by an IGP as specified in Section 5.1.3. mplsTopLabelType(46) value 10 (BGP Segment Routing Prefix-SID) is outside the igpAlgo scope. For SRv6, srhIPv6ActiveSegmentType(500) value 5 (BGP Segment Routing) alone does not determine whether igpAlgo applies. The exporter MUST omit igpAlgo when the selected entry has no unambiguous IGP Algorithm association under the applicable profile, or when the exporter cannot derive one unambiguous value with the required context. The table below summarizes the applicability and the values defined for each profile at publication. Applicability of igpAlgo

Scenario	igpAlgo Applicable	Values Defined for This Profile at Publication
SR-MPLS Prefix-SID	Yes	0, 1, 128-255
SR-MPLS conventional Adj-SID	No	-
SR-MPLS algorithm-specific Adj-SID	Yes	128-255
SRv6 with SRH	Yes	0, 1, 128-255
SRv6 without SRH	Yes	0, 1, 128-255
Regular IGP-installed IPv4/IPv6 route	Yes	0, 128-255

A later IANA assignment applies to a forwarding profile only when an applicable specification defines that use. In a "Yes" row, igpAlgo is applicable only when the selected FIB or LFIB entry has an unambiguous IGP Algorithm association under the applicable profile and the exporter can derive one unambiguous value with the required context. Otherwise, the Template omission rule above applies.

Operational Considerations for igpMultiTopologyId The IE "igpMultiTopologyId" reports the MT-ID associated with the forwarding entry used for the observed packet. It is an independent dimension from igpAlgo. Value 0 is a valid value that identifies the base or default topology. Absence of igpMultiTopologyId means that the topology was not exported or is not applicable; a collector MUST NOT interpret absence as value 0. When more than one IGP protocol, instance, or routing context can apply, the exporter and collector MUST have an unambiguous mapping from the value to the applicable protocol, instance, and routing context for the same forwarding lookup. If such a required mapping is unavailable or ambiguous, the exporter MUST use a Template Record that does not specify igpMultiTopologyId. When igpMultiTopologyId is a non-key IE, it is derived from Packet Treatment, and the first-packet rule in Section 5 of applies. When separate accounting for each topology is required, an exporter SHOULD include igpMultiTopologyId in the Flow Key.

Security Considerations There are no additional security considerations regarding allocation of these new IPFIX IEs compared to . Other security considerations for IGP Algorithm in and apply to this document. These IEs and the context mappings used to interpret them can disclose internal routing policy, topology use, VRF membership, and Flexible Algorithm deployment. Implementations MUST evaluate the sensitivity of this information and apply the security and privacy considerations in Section 11 of , including authenticated and integrity-protected export, confidentiality when disclosure is a concern, and authorized access to stored data. Modification, stale configuration, or incorrect binding of these values and their context can cause a collector to attribute traffic to the wrong algorithm, topology, routing table, or FAD. A collector MUST bind records and context to the applicable Transport Session, Observation Domain, Template, and mappings specified in Section 5.1.4. It MUST treat an unavailable or ambiguous mapping as unavailable and MUST NOT infer a value.

IANA Considerations This document requests that IANA register two new IEs in the "IPFIX Information Elements" registry available at . IANA is requested to assign the Element IDs and replace TBD1 and TBD2 throughout this document with the assigned values. New IPFIX Information Elements

Element ID	Name	Reference
TBD1	igpAlgo	This document
TBD2	igpMultiTopologyId	This document

Acknowledgements The authors would like to thank Thomas Graf for his helpful comments and suggestions.