SPRING Working Group Z. Ali Internet-Draft C. Filsfils Intended status: Standards Track K. Talaulikar Expires: November 22, 2018 S. Sivabalan J. Liste Cisco Systems, Inc. M. Horneffer Deutsche Telekom R. Raszuk Bloomberg LP S. Litkowski Orange Business Services G. Dawra LinkedIn D. Voyer R. Morton Bell Canada May 21, 2018 Traffic Accounting in Segment Routing Networks draft-ali-spring-sr-traffic-accounting-01.txt Abstract Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing. Traffic accounting plays a critical role in network operation and capacity planning. A traffic account solution is required for SR networks that provides the necessary functionality without creating any additional per SR path states in the fabric. This document provides a holistic view of network capacity planning in a SR network and specifies the mechanisms and counters that are required for a SR Traffic Accounting solution. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Ali, et al. Expires November 22, 2018 [Page 1] Internet-Draft SR Traffic Accounting May 2018 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 22, 2018. Copyright Notice Copyright (c) 2018 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://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. SR Traffic Counters . . . . . . . . . . . . . . . . . . . . . 5 2.1. Traffic Counters Naming convention . . . . . . . . . . . 5 2.2. Per-Interface SR Counters . . . . . . . . . . . . . . . . 6 2.2.1. Per interface, per protocol aggregate egress SR traffic counters (SR.INT.E.PRO) . . . . . . . . . . . 6 2.2.2. Per interface, per traffic-class, per protocol aggregate egress SR traffic counters (SR.INT.E.PRO.TC) . . . . . . . . . . . . . . . . . . 7 2.2.3. Per interface aggregate ingress SR traffic counter (SR.INT.I) . . . . . . . . . . . . . . . . . . . . . 7 2.2.4. Per interface, per TC aggregate ingress SR traffic counter (SR.INT.I.TC) . . . . . . . . . . . . . . . . 7 2.3. Prefix SID Counters . . . . . . . . . . . . . . . . . . . 7 2.3.1. Per-prefix SID egress traffic counter (PSID.E) . . . 8 2.3.2. Per-prefix SID per-TC egress traffic counter (PSID.E.TC) . . . . . . . . . . . . . . . . . . . . . 8 2.3.3. Per-prefix SID, per egress interface traffic counter (PSID.INT.E) . . . . . . . . . . . . . . . . . . . . 8 Ali, et al. Expires November 22, 2018 [Page 2] Internet-Draft SR Traffic Accounting May 2018 2.3.4. Per-prefix SID per TC per egress interface traffic counter (PSID.INT.E.TC) . . . . . . . . . . . . . . 8 2.3.5. Per-prefix SID, per ingress interface traffic counter (PSID.INT.I) . . . . . . . . . . . . . . . . . . . . 8 2.3.6. Per-prefix SID, per TC, per ingress interface traffic counter (PSID.INT.I.TC) . . . . . . . . . . . . . . . 9 2.4. SR Policy Counters . . . . . . . . . . . . . . . . . . . 9 2.4.1. Per-SR Policy Aggregate traffic counter (POL) . . . . 9 2.4.2. Per-SR Policy labelled steered aggregate traffic counter (POL.BSID) . . . . . . . . . . . . . . . . . 9 2.4.3. Per-SR Policy, per TC Aggregate traffic counter (POL.TC) . . . . . . . . . . . . . . . . . . . . . . 9 2.4.4. Per-SR Policy, per TC labelled steered aggregate traffic counter (POL.BSID.TC) . . . . . . . . . . . . 10 2.4.5. Per-SR Policy, Per-Segment-List Aggregate traffic counter (POL.SL) . . . . . . . . . . . . . . . . . . 10 2.4.6. Per-SR Policy, Per-Segment-List labelled steered aggregate traffic counter (POL.SL.BSID) . . . . . . . 10 3. SR Traffic Matrix . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Traffic Matrix Border . . . . . . . . . . . . . . . . . . 11 3.2. Choosing Traffic Matrix Border . . . . . . . . . . . . . 11 3.3. Deriving Demand Matrix . . . . . . . . . . . . . . . . . 11 3.4. Traffic Matrix Counters . . . . . . . . . . . . . . . . . 12 3.4.1. Per-Prefix SID Traffic Matrix counter (PSID.E.TM) . . 12 3.4.2. Per-Prefix, Per TC SID Traffic Matrix counter (PSID.E.TM.TC) . . . . . . . . . . . . . . . . . . . 12 4. Internet Protocol Flow Information Export . . . . . . . . . . 12 5. SR Traffic Accounting . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction One of the main architecture principles of Segment Routing (SR) [I-D.ietf-spring-segment-routing] is that it maintains per-flow states only at the ingress nodes in the SR domain. The approach taken in this document respects the architecture principles of SR, i.e., it does not create any additional control and data plane states at the transit or egress node for traffic accounting. Only the ingress node of an SR policy [I-D.filsfils-spring-segment-routing-policy] maintains per-flow Ali, et al. Expires November 22, 2018 [Page 3] Internet-Draft SR Traffic Accounting May 2018 counters for traffic accounting, which are also needed for other use- cases like billing. Capacity planning is the continuous art of forecasting traffic load and failures to evolve the network topology, its capacity, and its routing to meet a defined Service-Level Agreement (SLA). This document takes a holistic view of traffic accounting and its role in operation and capacity planning in SR networks. The Traffic Matrix (TM) [Traffic-Matrices] is one of the important components of the holistic approach to traffic accounting taken in this document. A network's traffic matrix is the volume of aggregated traffic flows that enter, traverse and leave an arbitrarily defined boundary in the network over a given time interval. The TM border defines the arbitrary boundary nodes of a contiguous portion of the network across which service providers wish to measure traffic flows. The TM border defined for traffic matrix collection does not have to be at the edge of the network, e.g., it can also be placed at the aggregation layer. Knowledge of the traffic matrix is essential to efficient and effective planning, design, engineering, and operation of any IP or MPLS network. This document defines the traffic matrix counters for accounting at the router and how these counters simplify traffic matrix calculation process for the network. Furthermore, it specifies policy, prefix- SID and interface counters for accounting in an SR network. The goal of the document is to provide a holistic view of traffic accounting in an SR network. This document assumes that the routers export the traffic counters defined in Section 2 and Section 3 to an external controller. It is also assumed that the controller also collects the following information in order to get the visibility required for traffic accounting: o Network topology information indicates all the nodes and their inter-connecting links (e.g. via BGP-LS [RFC7752] ) o SR Policies instantiated at various node and their BSID (e.g. using PCEP [RFC8231] or BGP-LS [I-D.ietf-idr-te-lsp-distribution]) o Aggregate traffic counters and statistics for links that include link utilization, per traffic class (TC) statistics, drop counters, etc. o IPFIX [RFC7011] data and the flow accounting information derived from an IPFIX collector. Ali, et al. Expires November 22, 2018 [Page 4] Internet-Draft SR Traffic Accounting May 2018 The methods for collection of this information by the controller is beyond the scope of the document. 2. SR Traffic Counters This section describes counters for traffic accounting in segment routing networks. The essence of Segment Routing consists in scaling the network by only maintaining per-flow state at the source or edge of the network. Specifically, only the headend of an SR policy maintains the related per-policy state [I-D.filsfils-spring-segment-routing-policy] . Egress and Midpoints along the source route do not maintain any per-policy state. The traffic counters described in this section respects the architecture principles of SR, while given visibility to the service provider for network operation and capacity planning. The SR traffic counters are divided into three categories: interface counters, prefix counters and SR policy counters at the policy head-end. 2.1. Traffic Counters Naming convention The section uses the following naming convention when referring to the various counters. This is done in order to assign mnemonic names to SR counters. o The term counter(s) in all of the definitions specified in this document refers either to the (packet, byte) counters or the byte counter. o SR: any traffic whose FIB lookup is a segment (IGP prefix/Adj segments, BGP segments, any type of segments) or the matched FIB entry is steered on an SR Policy. o INT in name indicates a counter is implemented at a per interface level. o E in name refers to egress direction (with respect to the traffic flow). o I in name refers to ingress direction (with respect to the traffic flow). o TC in name indicates a counter is implemented on a Traffic Class (TC) basis. o TM in name refers to a Traffic Matrix (TM) counter. Ali, et al. Expires November 22, 2018 [Page 5] Internet-Draft SR Traffic Accounting May 2018 o PRO in name indicates that the counter is implemented on per protocol/adjacency type basis. Per PRO counters in this document can either be accounts for: * LAB (Labelled Traffic): the matched FIB entry is a segment, and the outgoing packet has at least one label (that label does not have to be a segment label, e.g., the label may be a VPN label). * V4 (IPv4 Traffic): the matched FIB entry is a segment which is PoP'ed. The outgoing packet is IPv4. * V6 (IPv6 Traffic): the matched FIB entry is a segment which is PoP'ed. The outgoing packet is IPv6. o POL in name refers to a Policy counter. o BSID in name indicates a policy counter for labelled traffic. o SL in name indicates a policy counter is implemented at a Segment- List (SL) level. Counter nomenclature is exemplified using the following example: o SR.INT.E.PRO: Per-interface per-protocol aggregate egress SR traffic. o POL.BSID: Per-SR Policy labelled steered aggregate traffic counter. 2.2. Per-Interface SR Counters For each local interface, node N maintains the following per- interface SR counters. These counters include accounting due to push, pop or swap operations on SR traffic. 2.2.1. Per interface, per protocol aggregate egress SR traffic counters (SR.INT.E.PRO) The following counters are included under this category. o SR.INT.E.LAB: For each egress interface (INT.E), N MUST maintain counter(s) for the aggregate SR traffic forwarded over the (INT.E) interface as labelled traffic. o SR.INT.E.V4: For each egress interface (INT.E), N MUST maintain counter(s) for the aggregate SR traffic forwarded over the (INT.E) interface as IPv4 traffic (due to the pop operation). Ali, et al. Expires November 22, 2018 [Page 6] Internet-Draft SR Traffic Accounting May 2018 o SR.INT.E.V6: For each egress interface (INT.E), N MUST maintain counter(s) for the aggregate SR traffic forwarded over the (INT.E) interface as IPv6 traffic (due to the pop operation). 2.2.2. Per interface, per traffic-class, per protocol aggregate egress SR traffic counters (SR.INT.E.PRO.TC) This counter provides per Traffic Class (TC) breakdown of SR.INT.E.PRO. The following counters are included under this category. o SR.INT.E.LAB.TC: For each egress interface (INT.E) and a given Traffic Class (TC), N SHOULD maintain counter(s) for the aggregate SR traffic forwarded over the (INT.E) interface as labelled traffic. o SR.INT.E.V4.TC: For each egress interface (INT.E) and a given Traffic Class (TC), N SHOULD maintain counter(s) for the aggregate SR traffic forwarded over the (INT.E) interface as IPv4 traffic (due to the pop operation). o SR.INT.E.V6.TC: For each egress interface (INT.E) and a given Traffic Class (TC), N SHOULD maintain counter(s) for the aggregate SR traffic forwarded over the (INT.E) interface as IPv6 traffic (due to the pop operation). 2.2.3. Per interface aggregate ingress SR traffic counter (SR.INT.I) The SR.INT.I counter is defined as follows: For each ingress interface (INT.I), N SHOULD maintain counter(s) for the aggregate SR traffic received on I. 2.2.4. Per interface, per TC aggregate ingress SR traffic counter (SR.INT.I.TC) This counter provides per Traffic Class (TC) breakdown of the SR.INT.I. It is defined as follow: For each ingress interface (INT.I) and a given Traffic Class (TC), N MAY maintain counter(s) for the aggregate SR traffic (matching the traffic class TC criteria) received on I. 2.3. Prefix SID Counters For a remote prefix SID S, node N maintains the following prefix SID counters. These counters include accounting due to push, pop or swap operations on the SR traffic. Ali, et al. Expires November 22, 2018 [Page 7] Internet-Draft SR Traffic Accounting May 2018 2.3.1. Per-prefix SID egress traffic counter (PSID.E) This counter is defined as follows: For a remote prefix SID S, N MUST maintain counter(s) for aggregate traffic forwarded towards S. 2.3.2. Per-prefix SID per-TC egress traffic counter (PSID.E.TC) This counter provides per Traffic Class (TC) breakdown of PSID.E. It is defined as follows: For a given Traffic Class (TC) and a remote prefix SID S, N SHOULD maintain counter(s) for traffic forwarded towards S. 2.3.3. Per-prefix SID, per egress interface traffic counter (PSID.INT.E) This counter is defined as follows: For a given egress interface (INT.E) and a remote prefix SID S, N SHOULD maintain counter(s) for traffic forwarded towards S over the (INT.E) interface. 2.3.4. Per-prefix SID per TC per egress interface traffic counter (PSID.INT.E.TC) This counter provides per Traffic Class (TC) breakdown of PSID.INT.E. It is defined as follows: For a given Traffic Class (TC), an egress interface (INT.E) and a remote prefix SID S, N MAY maintain counter(s) for traffic forwarded towards S over the (INT.E) interface. 2.3.5. Per-prefix SID, per ingress interface traffic counter (PSID.INT.I) This counter is defined as follows: For a given ingress interface (INT.I) and a remote prefix SID S, N MAY maintain counter(s) for the traffic received on I and forwarded towards S. Ali, et al. Expires November 22, 2018 [Page 8] Internet-Draft SR Traffic Accounting May 2018 2.3.6. Per-prefix SID, per TC, per ingress interface traffic counter (PSID.INT.I.TC) This counter provides per Traffic Class (TC) breakdown of PSID.INT.I. It is defined as follows: For a given Traffic Class (TC), ingress interface (INT.I), and a remote prefix SID S, N MAY maintain counter(s) for the traffic received on I and forwarded towards S. 2.4. SR Policy Counters Per policy counters are only maintained at the policy head-end node. For each SR policy [I-D.filsfils-spring-segment-routing-policy] , the head-end node maintains the following counters. 2.4.1. Per-SR Policy Aggregate traffic counter (POL) This counter includes both labelled and unlabelled steered traffic. It is defined as: For each SR policy (P), head-end node N MUST maintain counter(s) for the aggregate traffic steered onto P. 2.4.2. Per-SR Policy labelled steered aggregate traffic counter (POL.BSID) This counter is defined as: For each SR policy (P), head-end node N SHOULD maintain counter(s) for the aggregate labelled traffic steered onto P. Please note that labelled steered traffic refers to incoming packets with an active SID matching a local BSID of an SR policy at the head-end. 2.4.3. Per-SR Policy, per TC Aggregate traffic counter (POL.TC) This counter provides per Traffic Class (TC) breakdown of POL. It is defined as follows: For each SR policy (P) and a given Traffic Class (TC), head-end node N SHOULD maintain counter(s) for the aggregate traffic (matching the traffic class TC criteria) steered onto P. Ali, et al. Expires November 22, 2018 [Page 9] Internet-Draft SR Traffic Accounting May 2018 2.4.4. Per-SR Policy, per TC labelled steered aggregate traffic counter (POL.BSID.TC) This counter provides per Traffic Class (TC) breakdown of POL.BSID. It is defined as follows: For each SR policy (P) and a given Traffic Class (TC), head-end node N MAY maintain counter(s) for the aggregate labelled traffic steered onto P. 2.4.5. Per-SR Policy, Per-Segment-List Aggregate traffic counter (POL.SL) This counter is defined as: For each SR policy (P) and a given Segment-List (SL), head-end node N SHOULD maintain counter(s) for the aggregate traffic steered onto the Segment-List (SL) of P. 2.4.6. Per-SR Policy, Per-Segment-List labelled steered aggregate traffic counter (POL.SL.BSID) This counter is defined as: For each SR policy (P) and a given Segment-List (SL), head-end node N MAY maintain counter(s) for the aggregate labelled traffic steered onto the Segment-List SL of P. Please note that labelled steered traffic refers to incoming packets with an active SID matching a local BSID of an SR policy at the head-end. 3. SR Traffic Matrix A traffic matrix T(N, M) is the amount of traffic entering the network at node N and leaving the network at node M, where N and M are border nodes at an arbitrarily defined boundary in the network. The TM border defines the arbitrary boundary nodes of a contiguous portion of the network across which service providers wish to measure traffic flows. The traffic matrix (also called demand matrix) contains all the demands crossing the TM border. It has as many rows as ingress edge nodes and as many columns as egress edge nodes at the TM border. The demand D(N, M) is the cell of the matrix at row N and column M. In order to facilitate network level traffic matrix calculations, nodes position at the edge of the network boundary SHOULD support traffic matrix counters. The nodes positioned within the network boundary are not required to support these counters. Ali, et al. Expires November 22, 2018 [Page 10] Internet-Draft SR Traffic Accounting May 2018 3.1. Traffic Matrix Border The service provider needs to establish TM border to collect traffic matrix. The TM border defines the boundary nodes of a contiguous portion of the network across which the service provider wishes to measure traffic flows. The TM border divides the network into two parts: o Internal part: a contiguous part of the network that is located within the TM border. o External part: anything outside of the TM border The TM border cuts through nodes, resulting in two types of interfaces: internal and external interfaces. Interfaces are internal if they are located inside the TM border, they are external if they are found outside the TM border. A node implementing Traffic Matrix SHOULD support the classification of any of its interfaces as internal or external. How a node marks it interfaces as external or internal is an implementation matter and beyond the scope of this document. 3.2. Choosing Traffic Matrix Border An operator can choose where the TM border is located. Typically, this will be at the edge of the network, but it can also be placed at the aggregation layer. Or an operator can use multiple TM borders for each of their network domains, with each TM border cutting through different nodes; different TM borders cannot cut through the same nodes. 3.3. Deriving Demand Matrix The goal is to measure the volume of traffic that enters a TM border node n through an external interface and leaves through an external interface of another TM border node m. This traffic volume yields the traffic matrix entry Tn,m. Measuring this for every pair of TM border nodes (n,m) results in the complete traffic matrix. Service providers use various techniques to compute traffic matrix, including a combination of collecting link utilization, gathering IPFIX data, collect MPLS forwarding statistics, etc. A service provider may also use traffic matrix counters defined in this document for that purpose. The usefulness and applicability of the Traffic Matrix do not depend on the TM collection mechanism. Ali, et al. Expires November 22, 2018 [Page 11] Internet-Draft SR Traffic Accounting May 2018 3.4. Traffic Matrix Counters As mentioned above, a Traffic Matrix (TM) provides, for every ingress point N into the network and every egress point M out of the network, the volume of traffic T(N, M) from N to M over a given time interval. To measure the traffic matrix, nodes in an SR network designate its interfaces as either internal or external. When Node N receives a packet destined to remote prefix SID M, N maintains the following counters. These counters include accounting due to push, pop or swap operations. 3.4.1. Per-Prefix SID Traffic Matrix counter (PSID.E.TM) This counter is defined as follows: For a given remote prefix SID M, N SHOULD maintain counter(s) for all the traffic received on any external interfaces and forwarded towards M. 3.4.2. Per-Prefix, Per TC SID Traffic Matrix counter (PSID.E.TM.TC) This counter provides per Traffic Class (TC) breakdown of PSID.E.TM. It is defined as follows: For a given Traffic Class (TC) and a remote prefix SID M, N SHOULD maintain counter(s) for all the traffic received on any external interfaces and forwarded towards M. 4. Internet Protocol Flow Information Export Internet Protocol Flow Information Export (IPFIX) [RFC7011] [RFC7012] [RFC7013] [RFC7014] [RFC7015] is a standard of export for Internet Protocol flow information. IPFIX is extensively deployed and used by network management systems to facilitate services such as measurement, security, accounting and billing. IPFIX also plays a vital role in traffic accounting in SR network. For example, IPFIX can be used for traffic accounting on an SR policy, without requiring any change to the SR-MPLS or IPFIX protocols. 5. SR Traffic Accounting The SR counters, IPFIX data, Traffic Matrix, network topology information, node, and link statistics, SR policies configuration, etc. constitute components of SR traffic accounting. This section describes some potential use of this information, but other mechanisms also exist. Ali, et al. Expires November 22, 2018 [Page 12] Internet-Draft SR Traffic Accounting May 2018 One of the possible uses is centered around the traffic matrix. An external controller collects the traffic counters, including the traffic matrix, defined in Section 3 from the routers. Using the Traffic Matrix TM(N, M), the controller knows the exact traffic is entering node N and leaving node M, where node N and M are edge node on an arbitrary TM border. The controller also collects network topology and SR policies configuration from the network. Using this information, the controller runs local path calculation algorithm to map these demands onto the individual SR paths. This enables a controller to determine the path that would be taken through the network (including ECMP paths) for any prefix at any node. Specifically, the controller starts with distributing the TM(N, M) equally among all ECMP from node N to node M. By repeating the process for all entry and exit nodes in the network, the controller predicts how the demands are distributed among SR paths in the network. The equal distribution of the traffic demand assumption is validated by correlating the projected load with the link and node statistics and other traffic counters described in this document. The various SR counters described in Section 2 provide the view of each segment's ingress and egress statistics at every node and link in the network, which is further supplemented by SR Policies' statistics that are available at all head-end nodes. The controller adjusts the predicted values, accordingly. How such adjustments are performed is beyond the scope of this document. The predicted traffic mapping to the individual SR path maybe used for serval purposes. That includes simulating "what-if" scenarios, develop contingency and maintenance plans, manage network latency and to anticipate and prevent congestion, etc. For example, if there is congestion on the link between two nodes, the controller can identify the SR path causing the congestion and how to re-route it to relieve it. Another possible use is built around the IPFIX data. IPFIX can be used for traffic account on an SR policy, without requiring any change to the SR-MPLS or IPFIX protocols. This is because when traffic is steered on an SR policy, the steering is based on a match of the fields of the incoming packet. A controller can replicate the matching criteria to account for the traffic received at the egress for the given SR policy. The policy counters, other traffic counters defined in Section 2, and information of packet loss over policy can further supplement the IPFIX based accounting for measuring, accounting, and billing on per policy basis. IPFIX Information when required and enabled provides a more granular visibility of network flows (including SR Policy flows) at any point in the network that can be correlated. For example, IPFIX may be enabled on the nodes and links at the network edge (on similar lines as the nodes along the Traffic Matrix Border)to analyze the flows Ali, et al. Expires November 22, 2018 [Page 13] Internet-Draft SR Traffic Accounting May 2018 entering and leaving a specific network region. Additionally, it can be also enabled at any node or a specific link within the network for analyzing flows through it - either on demand or continuously. IPFIX can also be enabled on the head-end nodes and endpoints of SR Policies in the network to analyze flows steered through various policies. Since IPFIX sampling also includes the MPLS label stack on the packet, the traffic flows for a specific SR Policy can also be determined at any intermediate link or node in the network, when necessary. Link level statistics information, derived using the ingress and egress counters (including the QoS counters on a per TC basis), provides the view of link utilization including for a specific class of service at any point. This helps detect congestion for the link as a whole or for specific class of service. In summary, a controller can analyze all of the above information together and correlated them to predicted traffic mapping to the individual SR paths. The aggregate demands on the network and their paths can be determined and correlated with link utilization to identify the flows causing congestion for specific links. Visibility into all the flows on a link can be achieved using the SR counters and supplemented by IPIX. 6. Security Considerations This document does not define any new protocol extensions and does not impose any additional security challenges. 7. IANA Considerations This document has no actions for IANA. 8. Acknowledgement The authors like to thank Kris Michielsen for his valuable comments and suggestions. 9. Contributors The following people have substantially contributed to the editing of this document: Francois Clad Cisco Systems Email: fclad@cisco.com Ali, et al. Expires November 22, 2018 [Page 14] Internet-Draft SR Traffic Accounting May 2018 Faisal Iqbal Cisco Systems Email: faiqbal@cisco.com 10. References 10.1. Normative References [I-D.filsfils-spring-segment-routing-policy] Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad, F., Talaulikar, K., Ali, Z., Hegde, S., daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., Litkowski, S., and P. Mattes, "Segment Routing Policy for Traffic Engineering", draft-filsfils-spring-segment- routing-policy-05 (work in progress), February 2018. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf-spring-segment-routing-15 (work in progress), January 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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/RFC7011, September 2013, . [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, . [RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements", BCP 184, RFC 7013, DOI 10.17487/RFC7013, September 2013, . [RFC7014] D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow Selection Techniques", RFC 7014, DOI 10.17487/RFC7014, September 2013, . Ali, et al. Expires November 22, 2018 [Page 15] Internet-Draft SR Traffic Accounting May 2018 [RFC7015] Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol", RFC 7015, DOI 10.17487/RFC7015, September 2013, . 10.2. Informative References [I-D.ietf-idr-te-lsp-distribution] Previdi, S., Dong, J., Chen, M., Gredler, H., and J. Tantsura, "Distribution of Traffic Engineering (TE) Policies and State using BGP-LS", draft-ietf-idr-te-lsp- distribution-08 (work in progress), December 2017. [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, . [Traffic-Matrices] Schnitter, T-Systems, S. and M. Horneffer, T-Com, "Traffic Matrices for MPLS Networks with LDP Traffic Statistics, Proc. Networks2004, VDE-Verlag 2004", 2015. Authors' Addresses Zafar Ali Cisco Systems, Inc. Email: zali@cisco.com Clarence Filsfils Cisco Systems, Inc. Email: cfilsfil@cisco.com Ketan Talaulikar Cisco Systems, Inc. Email: ketant@cisco.com Ali, et al. Expires November 22, 2018 [Page 16] Internet-Draft SR Traffic Accounting May 2018 Siva Sivabalan Cisco Systems, Inc. Email: msiva@cisco.com Jose Liste Cisco Systems, Inc. Email: jliste@cisco.com Martin Horneffer Deutsche Telekom Email: martin.horneffer@telekom.de Robert Raszuk Bloomberg LP Email: robert@raszuk.net Stephane Litkowski Orange Business Services Email: stephane.litkowski@orange.com Gaurav Dawra LinkedIn Email: gdawra.ietf@gmail.com Daniel Voyer Bell Canada Email: daniel.voyer@bell.ca Rick Morton Bell Canada Email: rick.morton@bell.ca Ali, et al. Expires November 22, 2018 [Page 17]