Traffic Accounting in Segment Routing Networks
draft-ali-spring-sr-traffic-accounting-01

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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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,
              <https://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/RFC7012, September 2013,
              <https://www.rfc-editor.org/info/rfc7012>.

   [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,
              <https://www.rfc-editor.org/info/rfc7013>.

   [RFC7014]  D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow
              Selection Techniques", RFC 7014, DOI 10.17487/RFC7014,
              September 2013, <https://www.rfc-editor.org/info/rfc7014>.

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,
              <https://www.rfc-editor.org/info/rfc7015>.

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,
              <https://www.rfc-editor.org/info/rfc7752>.

   [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,
              <https://www.rfc-editor.org/info/rfc8231>.

   [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]