idnits 2.17.1 draft-ali-spring-sr-traffic-accounting-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6 Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7 IANA Considerations' ) ** There are 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 155 has weird spacing: '...utlined below...' -- The document date (June 7, 2018) is 2149 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.draft-filsfils-spring-segment-routing-policy' is mentioned on line 233, but not defined == Missing Reference: 'RFC7752' is mentioned on line 137, but not defined ** Obsolete undefined reference: RFC 7752 (Obsoleted by RFC 9552) == Missing Reference: 'RFC 7015' is mentioned on line 262, but not defined == Unused Reference: 'TM' is defined on line 405, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SPRING Working Group Z. Ali 2 Internet-Draft C. Filsfils 3 Intended status: Informational K. Talaulikar 4 Expires: December 6, 2018 Siva Sivabalan 5 Cisco Systems, Inc. 6 M. Horneffer 7 Deutsche Telekom 8 R. Raszuk 9 Bloomberg LP 10 S. Litkowski 11 Orange Business Services 12 D. Voyer 13 R. Morton 14 Bell Canada 15 G. Dawra 16 LinkedIn 17 June 7, 2018 19 Traffic Accounting in Segment Routing Networks 20 draft-ali-spring-sr-traffic-accounting-02.txt 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet 28 Engineering Task Force (IETF), its areas, and its working 29 groups. Note that other groups may also distribute working 30 documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet-Drafts 35 as reference material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on Expires December 6, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with 53 respect to this document. Code Components extracted from this 54 document must include Simplified BSD License text as described 55 in Section 4.e of the Trust Legal Provisions and are provided 56 without warranty as described in the Simplified BSD License. 58 Abstract 60 Capacity planning is the continuous art of forecasting traffic 61 load and failures to evolve the network topology, its capacity, 62 and its routing to meet a defined Service-Level Agreement (SLA). 63 This document takes a holistic view of network capacity planning 64 and identifies the role of traffic accounting in network 65 operation and capacity planning, without creating any additional 66 states in the SR fabric. 68 Table of Contents 70 1 Introduction...................................................2 71 2 SR Traffic Counters............................................4 72 3 SR Traffic Matrix (TM).........................................4 73 3.1 TM Border ................................................4 74 3.1 Choosing TM Border .......................................5 75 3.2 Deriving Demand Matrix ...................................5 76 3.1 Traffic Matrix Counters ..................................5 77 4 Internet Protocol Flow Information Export (IPFIX)..............6 78 5 Segment Routing Traffic Accounting.............................6 79 6 Security Considerations........................................8 80 7 IANA Considerations............................................8 81 8 References.....................................................8 82 8.1 Normative References .....................................8 83 7.2............................................................9 84 9 Acknowledgments................................................9 85 10 Contributors ................................................9 87 1 Introduction 89 Capacity planning is the continuous art of forecasting traffic 90 load and failures to evolve the network topology, its capacity, 91 and its routing to meet a defined Service-Level Agreement (SLA). 92 This document takes a holistic view of traffic accounting and 93 its role in operation and capacity planning in Segment Routing 94 (SR) networks. 96 One of the main architecture principles of Segment Routing (SR) 97 Internet-Draft SR Traffic Accounting 99 to the SR domain. The approach taken in this document respects 100 the architecture principles of SR, i.e., this draft does not 101 create any additional control and data plane states at the 102 ingress, transit or egress node for traffic accounting. Only the 103 ingress node of an SR policy maintains per-flow counters for 104 traffic accounting, which are also needed for other use-cases 105 like billing. 107 The Traffic Matrix (TM) is one of the main components of the 108 holistic approach to traffic accounting taken in this document. 109 A network's traffic matrix is the volume of aggregated traffic 110 flows that enter, traverse and leave an arbitrarily defined 111 boundary in the network over a given time interval. The TM 112 border defines the arbitrary boundary nodes of a contiguous 113 portion of the network across which service providers wish to 114 measure traffic flows. The TM border defined for traffic matrix 115 collection does not have to be at the edge of the network, e.g., 116 it can also be placed at the aggregation layer. Knowledge of the 117 traffic matrix is essential to efficient and effective planning, 118 design, engineering, and operation of any IP or MPLS network. 120 [I-D.draft-filsfils-spring-segment-routing-policy] defines the 121 traffic matrix counters for accounting at the router. This draft 122 describes how these counters simplify traffic matrix collection 123 process. [I-D.draft-filsfils-spring-segment-routing-policy] also 124 specifies policy, prefix-SID and interface counters for 125 accounting in an SR network. This document along with the 126 traffic counters defined in [I-D.draft-filsfils-spring-segment- 127 routing-policy] constitute the holistic view of traffic 128 accounting in an SR network. 130 This document assumes that the routers export the traffic 131 counters defined in [I-D.draft-filsfils-spring-segment-routing- 132 policy] to an external controller. It is also assumed that the 133 controller also collects the following information in order to 134 get the visibility required for traffic accounting: 136 - Network topology information indicates all the nodes and their inter- 137 connecting links (e.g. via BGP-LS [RFC7752]). 138 - SR Policies instantiated at various node and their BSID (e.g. using 139 PCEP as in RFC8231 or BGP-LS as in draft-ietf-idr-te-lsp-distribution). 140 - Aggregate traffic counters and statistics for links that include link 141 utilization, per TC statistics, drop counters, etc. 142 - IPFIX data and the flow accounting information derived from it from an 143 IPFIX collector. 145 The methods for collection of this information by the controller 146 is beyond the scope of the document. 148 Internet-Draft SR Traffic Accounting 150 2 SR Traffic Counters 152 [I-D.draft-filsfils-spring-segment-routing-policy] specifies SR 153 counters that form building blocks on accounting in SR networks. 154 Listing all counters in this document is not the goal of this 155 draft. Some of those counters are outlined below: 157 - Per-prefix SID egress traffic counter (PSID.E) 159 For a remote prefix SID M, this counter accounts for the 160 aggregate traffic forwarded towards M. 162 - Per-prefix SID per-TC egress traffic counter (PSID.E.TC) 164 This counter provides per Traffic Class (TC) breakdown of 165 PSID.E. 167 - Per-SR Policy Aggregate traffic counter (POL) 169 This counter accounts for both labelled and unlabeled traffic 170 steered on an SR policy (P). This counter is only maintained by 171 the head-end node. 173 Traffic matrix counters are outlined in the traffic matrix 174 section. 176 3 SR Traffic Matrix (TM) 178 A traffic matrix T(N, M) is the amount of traffic entering the 179 network at node N and leaving the network at node M, where N and 180 M are border nodes at an arbitrarily defined boundary in the 181 network. The TM border defines the arbitrary boundary nodes of a 182 contiguous portion of the network across which service providers 183 wish to measure traffic flows. The traffic matrix (also called 184 demand matrix) contains all the demands crossing the TM border. 185 It has as many rows as ingress edge nodes and as many columns as 186 egress edge nodes at the TM border. The demand D(N, M) is the 187 cell of the matrix at row N and column M. 189 3.1 TM Border 191 The service provider needs to establish Traffic Matrix (TM) 192 border to collect traffic matrix. The TM border defines the 193 Internet-Draft SR Traffic Accounting 195 which the service provider wishes to measure traffic flows. The 196 TM border divides the network into two parts: 198 - Internal part: a contiguous part of the network that is 199 located within the TM border. 200 - External part: anything outside of the TM border 202 The TM border cuts through nodes, resulting in two types of 203 interfaces: internal and external interfaces. Interfaces are 204 internal if they are located inside the TM border, they are 205 external if they are found outside the TM border. 207 How a node marks it interfaces as external or internal is an 208 implementation matter and beyond the scope of this document. 210 3.1 Choosing TM Border 212 An operator can choose where the TM border is located. 213 Typically, this will be at the edge of the network, but it can 214 also be placed at the aggregation layer. Or an operator can use 215 multiple TM borders for each of their network domains, with each 216 TM border cutting through different nodes; different TM borders 217 cannot cut through the same nodes. 219 3.2 Deriving Demand Matrix 221 The goal is to measure the volume of traffic that enters a TM 222 border node n through an external interface and leaves through 223 an external interface of another TM border node m. This traffic 224 volume yields the traffic matrix entry T . Measuring this for 225 n,m 226 every pair of TM border nodes (n,m) results in the complete 227 traffic matrix. 229 Service providers use various techniques to compute traffic 230 matrix, including a combination of collecting link utilization, 231 gathering IPFIX data, collect MPLS forwarding statistics, etc. 232 A service provider may also use traffic matrix counters defined 233 in [I-D.draft-filsfils-spring-segment-routing-policy] for this 234 purpose. The usefulness and applicability of the Traffic Matrix 235 do not depend on the TM collection mechanism. 237 3.1 Traffic Matrix Counters 239 Traffic Matrix counters are defined in [I-D.draft-filsfils- 240 spring-segment-routing-policy]. The TM counters are summarized 241 in the following for completeness. 243 Internet-Draft SR Traffic Accounting 245 When Node N receives a packet, N maintains the following 246 counters. 248 - Per-Prefix SID Traffic Matrix counter (PSID.E.TM) 250 For a given remote prefix SID M, this counter accounts for all 251 the traffic received on any external interfaces and forwarded 252 towards M. 254 - Per-Prefix, Per TC SID Traffic Matrix counter (PSID.E.TM.TC) 256 This counter provides per Traffic Class (TC) breakdown of 257 PSID.E.TM. 259 4 Internet Protocol Flow Information Export (IPFIX) 261 Internet Protocol Flow Information Export (IPFIX) [RFC 7011]- 262 [RFC 7015] is a standard of export for Internet Protocol flow 263 information. IPFIX is extensively deployed and used by network 264 management systems to facilitate services such as measurement, 265 security, accounting and billing. IPFIX also plays a vital role 266 in traffic accounting in SR network. For example, IPFIX can be 267 used for traffic accounting on an SR policy, without requiring 268 any change to the SR-MPLS or IPFIX protocols. 270 5 Segment Routing Traffic Accounting 272 The SR counters, IPFIX data, Traffic Matrix, network topology 273 information, node, and link statistics, SR policies 274 configuration and various SR counters described in [I-D.draft- 275 filsfils-spring-segment-routing-policy], etc. constitute 276 components of SR traffic accounting. This section describes some 277 potential use of this information, but other mechanisms also 278 exists. 280 One of the possible uses is centered around the traffic matrix. 281 An external controller collects the traffic counters, including 282 the traffic matrix, defined in [I-D.draft-filsfils-spring- 283 segment-routing-policy] from the routers. Using the Traffic 284 Matrix TM(N, M), the controller knows the exact traffic is 285 entering node N and leaving node M, where node N and M are edge 286 node on an arbitrary TM border. The controller also collects 287 Internet-Draft SR Traffic Accounting 289 Using this information, the controller runs local path 290 calculation algorithm to map these demands onto the individual 291 SR paths. This enables a controller to determine the path that 292 would be taken through the network (including ECMP paths) for 293 any prefix at any node. Specifically, the controller starts with 294 distributing the TM(N, M) equally among all ECMP from node N to 295 node M. By repeating the process for all entry and exit nodes in 296 the network, the controller predicts how the demands are 297 distributed among SR paths in the network. The equal 298 distribution of the traffic demand assumption is validated by 299 correlating the projected load with the link and node statistics 300 and other traffic counters described in [I-D.draft-filsfils- 301 spring-segment-routing-policy]. Specifically, the various SR 302 counters described in [I-D.draft-filsfils-spring-segment- 303 routing-policy] provide the view of each segment's ingress and 304 egress statistics at every node and link in the network, which 305 is further supplemented by SR Policies' statistics that are 306 available at all head-end nodes. The uses this information to 307 adjust the predicted load, accordingly. How such adjustments are 308 performed is beyond the scope of this document. The predicted 309 traffic mapping to the individual SR path may be used for serval 310 purposes. That includes simulating what-if scenarios, develop 311 contingency and maintenance plans, manage network latency and to 312 anticipate and prevent congestion, etc. For example, if there is 313 congestion on the link between two nodes, the controller can 314 identify the SR path causing the congestion and how to re-route 315 it to relieve it. 317 Another possible use is built around the IPFIX data. IPFIX can 318 be used for traffic account on an SR policy, without requiring 319 any change to the SR-MPLS or IPFIX protocols. It provides a more 320 granular visibility of network flows (including SR Policy flows) 321 at any point in the network that can be correlated. For example, 322 IPFIX may be enabled on the nodes and links at the traffic 323 matrix border nodes to analyze the flows entering and leaving a 324 specific network region. Additionally, it can be also enabled at 325 any node or a specific link within the network for analyzing 326 flows through it either on demand or continuously basis. IPFIX 327 can also be enabled on the head-end nodes and endpoints of SR 328 Policies in the network to analyze flows steered through various 329 policies. When traffic is steered on an SR policy, the steering 330 is based on a match of the fields of the incoming packet. A 331 controller can replicate the matching criteria to account for 332 the traffic received at the egress for the given SR policy. The 333 policy counters, other traffic counters defined in [I-D.draft- 334 filsfils-spring-segment-routing-policy], and information of 335 Internet-Draft SR Traffic Accounting 337 accounting for measuring, accounting, and billing on per policy 338 basis. Since IPFIX sampling also includes the MPLS label stack 339 on the packet and the underlying payload, the traffic flows for 340 a specific SR policy can also be determined at any intermediate 341 link or node in the network, if necessary. 343 Link level statistics information, derived using the ingress and 344 egress counters (including the QoS counters on a per TC basis), 345 provides the view of link utilization including for a specific 346 class of service at any point. This helps detect congestion for 347 the link as a whole or for specific class of service. 349 In summary, a controller can use the holistic view of traffic 350 accounting provided in this document to predicted traffic 351 mapping to the individual SR paths. The aggregate demands on the 352 network and their paths can be determined and correlated with 353 link utilization to identify the flows causing congestion for 354 specific links. Further visibility into all the flows on a link 355 can be achieved using the SR counters and supplemented by IPIX 356 data. 358 6 Security Considerations 360 This document does not define any new protocol extensions and 361 does not impose any additional security challenges. 363 7 IANA Considerations 365 This document does not define any new protocol or any extension 366 to an existing protocol. 368 8 References 370 8.1 Normative References 372 [I.D-filsfils-spring-srv6-network-programming] 373 Filsfils, C., et al., "Segment Routing Policy for Traffic 374 Engineering", draft-filsfils-spring-segment-routing-policy 375 (work in progress), March 2018. 377 RFC7011 Specification of the IP Flow Information Export (IPFIX) Protocol for 378 the Exchange of Flow Information. B. Claise, Ed., B. Trammell, Ed., 379 P. Aitken. September 2013. (Format: TXT=170852 bytes) (Obsoletes 380 RFC5101) (Also STD0077) (Status: INTERNET STANDARD) (DOI: 381 10.17487/RFC7011) 383 Internet-Draft SR Traffic Accounting 385 Ed., B. Trammell, Ed.. September 2013. (Format: TXT=50237 bytes) 386 (Obsoletes RFC5102) (Status: PROPOSED STANDARD) (DOI: 387 10.17487/RFC7012) 389 RFC7013 Guidelines for Authors and Reviewers of IP Flow Information Export 390 (IPFIX) Information Elements. B. Trammell, B. Claise. September 391 2013. (Format: TXT=76406 bytes) (Also BCP0184) (Status: BEST CURRENT 392 PRACTICE) (DOI: 10.17487/RFC7013) 394 RFC7014 Flow Selection Techniques. S. D'Antonio, T. Zseby, C. Henke, L. 395 Peluso. September 2013. (Format: TXT=72581 bytes) (Status: PROPOSED 396 STANDARD) (DOI: 10.17487/RFC7014) 398 RFC7015 Flow Aggregation for the IP Flow Information Export (IPFIX) 399 Protocol. B. Trammell, A. Wagner, B. Claise. September 2013. 400 (Format: TXT=112055 bytes) (Status: PROPOSED STANDARD) (DOI: 401 10.17487/RFC7015) 403 7.2. Informative References 405 [TM] S. Schnitter, T-Systems; M. Horneffer, T-Com. "Traffic 406 Matrices for MPLS Networks with LDP Traffic Statistics. " Proc. 407 Networks2004, VDE-Verlag 2004. 409 9 Acknowledgments 411 The authors would like to thank Kris Michielsen and Jose Liste 412 for their contribution to this document. 414 10 Contributors 416 Francois Clad 417 Cisco Systems, Inc. 418 fclad@cisco.com 420 Faisal Iqbal 421 Cisco Systems, Inc. 422 faiqbal@cisco.com 424 Authors' Addresses 426 Clarence Filsfils 427 Cisco Systems, Inc. 428 Email: cfilsfil@cisco.com 430 Internet-Draft SR Traffic Accounting 432 Cisco Systems, Inc. 433 Email: zali@cisco.com 435 Ketan Talaulikar 436 Cisco Systems, Inc. 437 Email: ketant@cisco.com 439 Siva Sivabalan 440 Cisco Systems, Inc. 441 Email: msiva@cisco.com 443 Martin Horneffer 444 Deutsche Telekom 445 Email: martin.horneffer@telekom.de 447 Robert Raszuk 448 Bloomberg LP 449 Email: robert@raszuk.net 451 Stephane Litkowski 452 Orange Business Services 453 Email: stephane.litkowski@orange.com 455 Daniel Voyer 456 Bell Canada 457 Email: daniel.voyer@bell.ca 459 Rick Morton 460 Bell Canada 461 Email: daniel.voyer@bell.ca 463 LinkedIn 464 Email: gdawra.ietf@gmail.com