idnits 2.17.1 draft-ali-spring-sr-traffic-accounting-00.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 154 has weird spacing: '...utlined below...' -- The document date (March 5, 2018) is 2237 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 232, but not defined == Missing Reference: 'RFC7752' is mentioned on line 136, but not defined ** Obsolete undefined reference: RFC 7752 (Obsoleted by RFC 9552) == Missing Reference: 'RFC 7015' is mentioned on line 261, but not defined == Unused Reference: 'TM' is defined on line 404, 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. -------------------------------------------------------------------------------- 2 SPRING Working Group Z. Ali 3 Internet-Draft C. Filsfils 4 Intended status: Informational K. Talaulikar 5 Expires: September 4, 2018 Siva Sivabalan 6 Cisco Systems, Inc. 7 M. Horneffer 8 Deutsche Telekom 9 R. Raszuk 10 Bloomberg LP 11 S. Litkowski 12 Orange Business Services 13 D. Voyer 14 R. Morton 15 Bell Canada 16 March 5, 2018 18 Traffic Accounting in Segment Routing Networks 19 draft-ali-spring-sr-traffic-accounting-00.txt 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet 27 Engineering Task Force (IETF), its areas, and its working 28 groups. Note that other groups may also distribute working 29 documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other 33 documents at any time. It is inappropriate to use Internet-Drafts 34 as reference material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on September 5, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described 54 in Section 4.e of the Trust Legal Provisions and are provided 55 without warranty as described in the Simplified BSD License. 57 Abstract 59 Capacity planning is the continuous art of forecasting traffic 60 load and failures to evolve the network topology, its capacity, 61 and its routing to meet a defined Service-Level Agreement (SLA). 62 This document takes a holistic view of network capacity planning 63 and identifies the role of traffic accounting in network 64 operation and capacity planning, without creating any additional 65 states in the SR fabric. 67 Table of Contents 69 1 Introduction...................................................2 70 2 SR Traffic Counters............................................4 71 3 SR Traffic Matrix (TM).........................................4 72 3.1 TM Border ................................................4 73 3.1 Choosing TM Border .......................................5 74 3.2 Deriving Demand Matrix ...................................5 75 3.1 Traffic Matrix Counters ..................................5 76 4 Internet Protocol Flow Information Export (IPFIX)..............6 77 5 Segment Routing Traffic Accounting.............................6 78 6 Security Considerations........................................8 79 7 IANA Considerations............................................8 80 8 References.....................................................8 81 8.1 Normative References .....................................8 82 7.2............................................................9 83 9 Acknowledgments................................................9 84 10 Contributors ................................................9 86 1 Introduction 88 Capacity planning is the continuous art of forecasting traffic 89 load and failures to evolve the network topology, its capacity, 90 and its routing to meet a defined Service-Level Agreement (SLA). 91 This document takes a holistic view of traffic accounting and 92 its role in operation and capacity planning in Segment Routing 93 (SR) networks. 95 One of the main architecture principles of Segment Routing (SR) 96 Internet-Draft SR Traffic Accounting 98 to the SR domain. The approach taken in this document respects 99 the architecture principles of SR, i.e., this draft does not 100 create any additional control and data plane states at the 101 ingress, transit or egress node for traffic accounting. Only the 102 ingress node of an SR policy maintains per-flow counters for 103 traffic accounting, which are also needed for other use-cases 104 like billing. 106 The Traffic Matrix (TM) is one of the main components of the 107 holistic approach to traffic accounting taken in this document. 108 A network's traffic matrix is the volume of aggregated traffic 109 flows that enter, traverse and leave an arbitrarily defined 110 boundary in the network over a given time interval. The TM 111 border defines the arbitrary boundary nodes of a contiguous 112 portion of the network across which service providers wish to 113 measure traffic flows. The TM border defined for traffic matrix 114 collection does not have to be at the edge of the network, e.g., 115 it can also be placed at the aggregation layer. Knowledge of the 116 traffic matrix is essential to efficient and effective planning, 117 design, engineering, and operation of any IP or MPLS network. 119 [I-D.draft-filsfils-spring-segment-routing-policy] defines the 120 traffic matrix counters for accounting at the router. This draft 121 describes how these counters simplify traffic matrix collection 122 process. [I-D.draft-filsfils-spring-segment-routing-policy] also 123 specifies policy, prefix-SID and interface counters for 124 accounting in an SR network. This document along with the 125 traffic counters defined in [I-D.draft-filsfils-spring-segment- 126 routing-policy] constitute the holistic view of traffic 127 accounting in an SR network. 129 This document assumes that the routers export the traffic 130 counters defined in [I-D.draft-filsfils-spring-segment-routing- 131 policy] to an external controller. It is also assumed that the 132 controller also collects the following information in order to 133 get the visibility required for traffic accounting: 135 - Network topology information indicates all the nodes and their inter- 136 connecting links (e.g. via BGP-LS [RFC7752]). 137 - SR Policies instantiated at various node and their BSID (e.g. using 138 PCEP as in RFC8231 or BGP-LS as in draft-ietf-idr-te-lsp-distribution). 139 - Aggregate traffic counters and statistics for links that include link 140 utilization, per TC statistics, drop counters, etc. 141 - IPFIX data and the flow accounting information derived from it from an 142 IPFIX collector. 144 The methods for collection of this information by the controller 145 is beyond the scope of the document. 147 Internet-Draft SR Traffic Accounting 149 2 SR Traffic Counters 151 [I-D.draft-filsfils-spring-segment-routing-policy] specifies SR 152 counters that form building blocks on accounting in SR networks. 153 Listing all counters in this document is not the goal of this 154 draft. Some of those counters are outlined below: 156 - Per-prefix SID egress traffic counter (PSID.E) 158 For a remote prefix SID M, this counter accounts for the 159 aggregate traffic forwarded towards M. 161 - Per-prefix SID per-TC egress traffic counter (PSID.E.TC) 163 This counter provides per Traffic Class (TC) breakdown of 164 PSID.E. 166 - Per-SR Policy Aggregate traffic counter (POL) 168 This counter accounts for both labelled and unlabeled traffic 169 steered on an SR policy (P). This counter is only maintained by 170 the head-end node. 172 Traffic matrix counters are outlined in the traffic matrix 173 section. 175 3 SR Traffic Matrix (TM) 177 A traffic matrix T(N, M) is the amount of traffic entering the 178 network at node N and leaving the network at node M, where N and 179 M are border nodes at an arbitrarily defined boundary in the 180 network. The TM border defines the arbitrary boundary nodes of a 181 contiguous portion of the network across which service providers 182 wish to measure traffic flows. The traffic matrix (also called 183 demand matrix) contains all the demands crossing the TM border. 184 It has as many rows as ingress edge nodes and as many columns as 185 egress edge nodes at the TM border. The demand D(N, M) is the 186 cell of the matrix at row N and column M. 188 3.1 TM Border 190 The service provider needs to establish Traffic Matrix (TM) 191 border to collect traffic matrix. The TM border defines the 192 Internet-Draft SR Traffic Accounting 194 which the service provider wishes to measure traffic flows. The 195 TM border divides the network into two parts: 197 - Internal part: a contiguous part of the network that is 198 located within the TM border. 199 - External part: anything outside of the TM border 201 The TM border cuts through nodes, resulting in two types of 202 interfaces: internal and external interfaces. Interfaces are 203 internal if they are located inside the TM border, they are 204 external if they are found outside the TM border. 206 How a node marks it interfaces as external or internal is an 207 implementation matter and beyond the scope of this document. 209 3.1 Choosing TM Border 211 An operator can choose where the TM border is located. 212 Typically, this will be at the edge of the network, but it can 213 also be placed at the aggregation layer. Or an operator can use 214 multiple TM borders for each of their network domains, with each 215 TM border cutting through different nodes; different TM borders 216 cannot cut through the same nodes. 218 3.2 Deriving Demand Matrix 220 The goal is to measure the volume of traffic that enters a TM 221 border node n through an external interface and leaves through 222 an external interface of another TM border node m. This traffic 223 volume yields the traffic matrix entry T . Measuring this for 224 n,m 225 every pair of TM border nodes (n,m) results in the complete 226 traffic matrix. 228 Service providers use various techniques to compute traffic 229 matrix, including a combination of collecting link utilization, 230 gathering IPFIX data, collect MPLS forwarding statistics, etc. 231 A service provider may also use traffic matrix counters defined 232 in [I-D.draft-filsfils-spring-segment-routing-policy] for this 233 purpose. The usefulness and applicability of the Traffic Matrix 234 do not depend on the TM collection mechanism. 236 3.1 Traffic Matrix Counters 238 Traffic Matrix counters are defined in [I-D.draft-filsfils- 239 spring-segment-routing-policy]. The TM counters are summarized 240 in the following for completeness. 242 Internet-Draft SR Traffic Accounting 244 When Node N receives a packet, N maintains the following 245 counters. 247 - Per-Prefix SID Traffic Matrix counter (PSID.E.TM) 249 For a given remote prefix SID M, this counter accounts for all 250 the traffic received on any external interfaces and forwarded 251 towards M. 253 - Per-Prefix, Per TC SID Traffic Matrix counter (PSID.E.TM.TC) 255 This counter provides per Traffic Class (TC) breakdown of 256 PSID.E.TM. 258 4 Internet Protocol Flow Information Export (IPFIX) 260 Internet Protocol Flow Information Export (IPFIX) [RFC 7011]- 261 [RFC 7015] is a standard of export for Internet Protocol flow 262 information. IPFIX is extensively deployed and used by network 263 management systems to facilitate services such as measurement, 264 security, accounting and billing. IPFIX also plays a vital role 265 in traffic accounting in SR network. For example, IPFIX can be 266 used for traffic accounting on an SR policy, without requiring 267 any change to the SR-MPLS or IPFIX protocols. 269 5 Segment Routing Traffic Accounting 271 The SR counters, IPFIX data, Traffic Matrix, network topology 272 information, node, and link statistics, SR policies 273 configuration and various SR counters described in [I-D.draft- 274 filsfils-spring-segment-routing-policy], etc. constitute 275 components of SR traffic accounting. This section describes some 276 potential use of this information, but other mechanisms also 277 exists. 279 One of the possible uses is centered around the traffic matrix. 280 An external controller collects the traffic counters, including 281 the traffic matrix, defined in [I-D.draft-filsfils-spring- 282 segment-routing-policy] from the routers. Using the Traffic 283 Matrix TM(N, M), the controller knows the exact traffic is 284 entering node N and leaving node M, where node N and M are edge 285 node on an arbitrary TM border. The controller also collects 286 Internet-Draft SR Traffic Accounting 288 Using this information, the controller runs local path 289 calculation algorithm to map these demands onto the individual 290 SR paths. This enables a controller to determine the path that 291 would be taken through the network (including ECMP paths) for 292 any prefix at any node. Specifically, the controller starts with 293 distributing the TM(N, M) equally among all ECMP from node N to 294 node M. By repeating the process for all entry and exit nodes in 295 the network, the controller predicts how the demands are 296 distributed among SR paths in the network. The equal 297 distribution of the traffic demand assumption is validated by 298 correlating the projected load with the link and node statistics 299 and other traffic counters described in [I-D.draft-filsfils- 300 spring-segment-routing-policy]. Specifically, the various SR 301 counters described in [I-D.draft-filsfils-spring-segment- 302 routing-policy] provide the view of each segment's ingress and 303 egress statistics at every node and link in the network, which 304 is further supplemented by SR Policies' statistics that are 305 available at all head-end nodes. The uses this information to 306 adjust the predicted load, accordingly. How such adjustments are 307 performed is beyond the scope of this document. The predicted 308 traffic mapping to the individual SR path may be used for serval 309 purposes. That includes simulating what-if scenarios, develop 310 contingency and maintenance plans, manage network latency and to 311 anticipate and prevent congestion, etc. For example, if there is 312 congestion on the link between two nodes, the controller can 313 identify the SR path causing the congestion and how to re-route 314 it to relieve it. 316 Another possible use is built around the IPFIX data. IPFIX can 317 be used for traffic account on an SR policy, without requiring 318 any change to the SR-MPLS or IPFIX protocols. It provides a more 319 granular visibility of network flows (including SR Policy flows) 320 at any point in the network that can be correlated. For example, 321 IPFIX may be enabled on the nodes and links at the traffic 322 matrix border nodes to analyze the flows entering and leaving a 323 specific network region. Additionally, it can be also enabled at 324 any node or a specific link within the network for analyzing 325 flows through it either on demand or continuously basis. IPFIX 326 can also be enabled on the head-end nodes and endpoints of SR 327 Policies in the network to analyze flows steered through various 328 policies. When traffic is steered on an SR policy, the steering 329 is based on a match of the fields of the incoming packet. A 330 controller can replicate the matching criteria to account for 331 the traffic received at the egress for the given SR policy. The 332 policy counters, other traffic counters defined in [I-D.draft- 333 filsfils-spring-segment-routing-policy], and information of 334 Internet-Draft SR Traffic Accounting 336 accounting for measuring, accounting, and billing on per policy 337 basis. Since IPFIX sampling also includes the MPLS label stack 338 on the packet and the underlying payload, the traffic flows for 339 a specific SR policy can also be determined at any intermediate 340 link or node in the network, if necessary. 342 Link level statistics information, derived using the ingress and 343 egress counters (including the QoS counters on a per TC basis), 344 provides the view of link utilization including for a specific 345 class of service at any point. This helps detect congestion for 346 the link as a whole or for specific class of service. 348 In summary, a controller can use the holistic view of traffic 349 accounting provided in this document to predicted traffic 350 mapping to the individual SR paths. The aggregate demands on the 351 network and their paths can be determined and correlated with 352 link utilization to identify the flows causing congestion for 353 specific links. Further visibility into all the flows on a link 354 can be achieved using the SR counters and supplemented by IPIX 355 data. 357 6 Security Considerations 359 This document does not define any new protocol extensions and 360 does not impose any additional security challenges. 362 7 IANA Considerations 364 This document does not define any new protocol or any extension 365 to an existing protocol. 367 8 References 369 8.1 Normative References 371 [I.D-filsfils-spring-srv6-network-programming] 372 Filsfils, C., et al., "Segment Routing Policy for Traffic 373 Engineering", draft-filsfils-spring-segment-routing-policy 374 (work in progress), March 2018. 376 RFC7011 Specification of the IP Flow Information Export (IPFIX) Protocol for 377 the Exchange of Flow Information. B. Claise, Ed., B. Trammell, Ed., 378 P. Aitken. September 2013. (Format: TXT=170852 bytes) (Obsoletes 379 RFC5101) (Also STD0077) (Status: INTERNET STANDARD) (DOI: 380 10.17487/RFC7011) 382 Internet-Draft SR Traffic Accounting 384 Ed., B. Trammell, Ed.. September 2013. (Format: TXT=50237 bytes) 385 (Obsoletes RFC5102) (Status: PROPOSED STANDARD) (DOI: 386 10.17487/RFC7012) 388 RFC7013 Guidelines for Authors and Reviewers of IP Flow Information Export 389 (IPFIX) Information Elements. B. Trammell, B. Claise. September 390 2013. (Format: TXT=76406 bytes) (Also BCP0184) (Status: BEST CURRENT 391 PRACTICE) (DOI: 10.17487/RFC7013) 393 RFC7014 Flow Selection Techniques. S. D'Antonio, T. Zseby, C. Henke, L. 394 Peluso. September 2013. (Format: TXT=72581 bytes) (Status: PROPOSED 395 STANDARD) (DOI: 10.17487/RFC7014) 397 RFC7015 Flow Aggregation for the IP Flow Information Export (IPFIX) 398 Protocol. B. Trammell, A. Wagner, B. Claise. September 2013. 399 (Format: TXT=112055 bytes) (Status: PROPOSED STANDARD) (DOI: 400 10.17487/RFC7015) 402 7.2. Informative References 404 [TM] S. Schnitter, T-Systems; M. Horneffer, T-Com. "Traffic 405 Matrices for MPLS Networks with LDP Traffic Statistics. " Proc. 406 Networks2004, VDE-Verlag 2004. 408 9 Acknowledgments 410 The authors would like to thank Kris Michielsen and Jose Liste 411 for their contribution to this document. 413 10 Contributors 415 Francois Clad 416 Cisco Systems, Inc. 417 fclad@cisco.com 419 Faisal Iqbal 420 Cisco Systems, Inc. 421 faiqbal@cisco.com 423 Authors' Addresses 425 Clarence Filsfils 426 Cisco Systems, Inc. 427 Email: cfilsfil@cisco.com 429 Internet-Draft SR Traffic Accounting 431 Cisco Systems, Inc. 432 Email: zali@cisco.com 434 Ketan Talaulikar 435 Cisco Systems, Inc. 436 Email: ketant@cisco.com 438 Siva Sivabalan 439 Cisco Systems, Inc. 440 Email: msiva@cisco.com 442 Martin Horneffer 443 Deutsche Telekom 444 Email: martin.horneffer@telekom.de 446 Robert Raszuk 447 Bloomberg LP 448 Email: robert@raszuk.net 450 Stephane Litkowski 451 Orange Business Services 452 Email: stephane.litkowski@orange.com 454 Daniel Voyer 455 Bell Canada 456 Email: daniel.voyer@bell.ca 458 Rick Morton 459 Bell Canada 460 Email: daniel.voyer@bell.ca