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