idnits 2.17.1 draft-filsfils-spring-sr-traffic-counters-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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 7, 2018) is 2122 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-ali-spring-sr-traffic-accounting-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group C. Filsfils 3 Internet-Draft Z. Ali, Ed. 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: December 9, 2018 M. Horneffer 6 Deutsche Telekom 7 D. Voyer 8 Bell Canada 9 M. Durrani 10 Equinix 11 R. Raszuk 12 Bloomberg LP 13 June 7, 2018 15 Segment Routing Traffic Accounting Counters 16 draft-filsfils-spring-sr-traffic-counters-00.txt 18 Abstract 20 Segment Routing (SR) allows a headend node to steer a packet flow 21 along any path. Intermediate per-flow states are eliminated thanks 22 to source routing. Traffic accounting plays a critical role in 23 network operation. A traffic account solution is required for SR 24 networks that provides the necessary functionality without creating 25 any additional per SR path states in the fabric. 27 This document describes counters for traffic accounting in SR 28 networks. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on December 9, 2018. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. SR Traffic Counters . . . . . . . . . . . . . . . . . . . . . 4 72 2.1. Traffic Counters Naming convention . . . . . . . . . . . 4 73 2.2. Per-Interface SR Counters . . . . . . . . . . . . . . . . 5 74 2.2.1. Per interface, per protocol aggregate egress SR 75 traffic counters (SR.INT.E.PRO) . . . . . . . . . . . 5 76 2.2.2. Per interface, per traffic-class, per protocol 77 aggregate egress SR traffic counters 78 (SR.INT.E.PRO.TC) . . . . . . . . . . . . . . . . . . 5 79 2.2.3. Per interface aggregate ingress SR traffic counter 80 (SR.INT.I) . . . . . . . . . . . . . . . . . . . . . 6 81 2.2.4. Per interface, per TC aggregate ingress SR traffic 82 counter (SR.INT.I.TC) . . . . . . . . . . . . . . . . 6 83 2.3. Prefix SID Counters . . . . . . . . . . . . . . . . . . . 6 84 2.3.1. Per-prefix SID egress traffic counter (PSID.E) . . . 6 85 2.3.2. Per-prefix SID per-TC egress traffic counter 86 (PSID.E.TC) . . . . . . . . . . . . . . . . . . . . . 7 87 2.3.3. Per-prefix SID, per egress interface traffic counter 88 (PSID.INT.E) . . . . . . . . . . . . . . . . . . . . 7 89 2.3.4. Per-prefix SID per TC per egress interface traffic 90 counter (PSID.INT.E.TC) . . . . . . . . . . . . . . 7 91 2.3.5. Per-prefix SID, per ingress interface traffic counter 92 (PSID.INT.I) . . . . . . . . . . . . . . . . . . . . 7 93 2.3.6. Per-prefix SID, per TC, per ingress interface traffic 94 counter (PSID.INT.I.TC) . . . . . . . . . . . . . . . 7 95 2.4. Traffic Matrix Counters . . . . . . . . . . . . . . . . . 8 96 2.4.1. Per-Prefix SID Traffic Matrix counter (PSID.E.TM) . . 8 97 2.4.2. Per-Prefix, Per TC SID Traffic Matrix counter 98 (PSID.E.TM.TC) . . . . . . . . . . . . . . . . . . . 8 99 2.5. SR Policy Counters . . . . . . . . . . . . . . . . . . . 8 100 2.5.1. Per-SR Policy Aggregate traffic counter (POL) . . . . 9 101 2.5.2. Per-SR Policy labelled steered aggregate traffic 102 counter (POL.BSID) . . . . . . . . . . . . . . . . . 9 103 2.5.3. Per-SR Policy, per TC Aggregate traffic counter 104 (POL.TC) . . . . . . . . . . . . . . . . . . . . . . 9 105 2.5.4. Per-SR Policy, per TC labelled steered aggregate 106 traffic counter (POL.BSID.TC) . . . . . . . . . . . . 9 107 2.5.5. Per-SR Policy, Per-Segment-List Aggregate traffic 108 counter (POL.SL) . . . . . . . . . . . . . . . . . . 9 109 2.5.6. Per-SR Policy, Per-Segment-List labelled steered 110 aggregate traffic counter (POL.SL.BSID) . . . . . . . 10 111 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 112 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 113 5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 114 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 115 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 116 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 117 7.2. Informative References . . . . . . . . . . . . . . . . . 12 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 120 1. Introduction 122 This document defines counters for traffic accounting in segment 123 routing (SR) [I-D.ietf-spring-segment-routing] networks. The essence 124 of Segment Routing consists in scaling the network by only 125 maintaining per-flow state at the source or edge of the network. 126 Specifically, only the headend of an SR policy 127 [I-D.filsfils-spring-segment-routing-policy] maintains the related 128 per-policy state. Egress and midpoints along the source route do not 129 maintain any per-policy state. The traffic counters described in 130 this section respects the architecture principles of SR, while given 131 visibility to the service provider for network operation and capacity 132 planning. 134 This document specifies prefix-SID, interface and SR Policy counters 135 to be implemented at each SR router. Furthermore, it describes the 136 traffic matrix (TM) counters for accounting at the TM border routers 137 (details described in Section 2.4).The goal of the document is to 138 specify these necessary counters for traffic accounting in an SR 139 network. The actual usage of this information and leveraging for 140 various use-cases is outside the scope of this document. 141 [I-D.ali-spring-sr-traffic-accounting] describes some of the use- 142 cases and application of these counters in an SR network. 144 This document assumes that the routers export the traffic counters 145 defined in Section 2 to an external controller. The methods for 146 collection of this information by the controller is beyond the scope 147 of the document. 149 2. SR Traffic Counters 151 2.1. Traffic Counters Naming convention 153 The section uses the following naming convention when referring to 154 the various counters. This is done in order to assign mnemonic names 155 to SR counters. 157 o The term counter(s) in all of the definitions specified in this 158 document refers either to the (packet, byte) counters or the byte 159 counter. 161 o SR: any traffic whose FIB lookup is a segment (IGP prefix/Adj 162 segments, BGP segments, any type of segments) or the matched FIB 163 entry is steered on an SR Policy. 165 o INT in name indicates a counter is implemented at a per interface 166 level. 168 o E in name refers to egress direction (with respect to the traffic 169 flow). 171 o I in name refers to ingress direction (with respect to the traffic 172 flow). 174 o TC in name indicates a counter is implemented on a Traffic Class 175 (TC) basis. 177 o TM in name refers to a Traffic Matrix (TM) counter. 179 o PRO in name indicates that the counter is implemented on per 180 protocol/adjacency type basis. Per PRO counters in this document 181 can either be accounts for: 183 * LAB (Labelled Traffic): the matched FIB entry is a segment, and 184 the outgoing packet has at least one label (that label does not 185 have to be a segment label, e.g., the label may be a VPN 186 label). 188 * V4 (IPv4 Traffic): the matched FIB entry is a segment which is 189 PoP'ed. The outgoing packet is IPv4. 191 * V6 (IPv6 Traffic): the matched FIB entry is a segment which is 192 PoP'ed. The outgoing packet is IPv6. 194 o POL in name refers to a Policy counter. 196 o BSID in name indicates a policy counter for labelled traffic. 198 o SL in name indicates a policy counter is implemented at a Segment- 199 List (SL) level. 201 Counter nomenclature is exemplified using the following example: 203 o SR.INT.E.PRO: Per-interface per-protocol aggregate egress SR 204 traffic. 206 o POL.BSID: Per-SR Policy labelled steered aggregate traffic 207 counter. 209 2.2. Per-Interface SR Counters 211 For each local interface, node N maintains the following per- 212 interface SR counters. These counters include accounting due to 213 push, pop or swap operations on SR traffic. 215 2.2.1. Per interface, per protocol aggregate egress SR traffic counters 216 (SR.INT.E.PRO) 218 The following counters are included under this category. 220 o SR.INT.E.LAB: For each egress interface (INT.E), N MUST maintain 221 counter(s) for the aggregate SR traffic forwarded over the (INT.E) 222 interface as labelled traffic. 224 o SR.INT.E.V4: For each egress interface (INT.E), N MUST maintain 225 counter(s) for the aggregate SR traffic forwarded over the (INT.E) 226 interface as IPv4 traffic (due to the pop operation). 228 o SR.INT.E.V6: For each egress interface (INT.E), N MUST maintain 229 counter(s) for the aggregate SR traffic forwarded over the (INT.E) 230 interface as IPv6 traffic (due to the pop operation). 232 2.2.2. Per interface, per traffic-class, per protocol aggregate egress 233 SR traffic counters (SR.INT.E.PRO.TC) 235 This counter provides per Traffic Class (TC) breakdown of 236 SR.INT.E.PRO. The following counters are included under this 237 category. 239 o SR.INT.E.LAB.TC: For each egress interface (INT.E) and a given 240 Traffic Class (TC), N SHOULD maintain counter(s) for the aggregate 241 SR traffic forwarded over the (INT.E) interface as labelled 242 traffic. 244 o SR.INT.E.V4.TC: For each egress interface (INT.E) and a given 245 Traffic Class (TC), N SHOULD maintain counter(s) for the aggregate 246 SR traffic forwarded over the (INT.E) interface as IPv4 traffic 247 (due to the pop operation). 249 o SR.INT.E.V6.TC: For each egress interface (INT.E) and a given 250 Traffic Class (TC), N SHOULD maintain counter(s) for the aggregate 251 SR traffic forwarded over the (INT.E) interface as IPv6 traffic 252 (due to the pop operation). 254 2.2.3. Per interface aggregate ingress SR traffic counter (SR.INT.I) 256 The SR.INT.I counter is defined as follows: 258 For each ingress interface (INT.I), N SHOULD maintain counter(s) for 259 the aggregate SR traffic received on I. 261 2.2.4. Per interface, per TC aggregate ingress SR traffic counter 262 (SR.INT.I.TC) 264 This counter provides per Traffic Class (TC) breakdown of the 265 SR.INT.I. It is defined as follow: 267 For each ingress interface (INT.I) and a given Traffic Class (TC), N 268 MAY maintain counter(s) for the aggregate SR traffic (matching the 269 traffic class TC criteria) received on I. 271 2.3. Prefix SID Counters 273 For a remote prefix SID S, node N maintains the following prefix SID 274 counters. These counters include accounting due to push, pop or swap 275 operations on the SR traffic. 277 2.3.1. Per-prefix SID egress traffic counter (PSID.E) 279 This counter is defined as follows: 281 For a remote prefix SID S, N MUST maintain counter(s) for aggregate 282 traffic forwarded towards S. 284 2.3.2. Per-prefix SID per-TC egress traffic counter (PSID.E.TC) 286 This counter provides per Traffic Class (TC) breakdown of PSID.E. It 287 is defined as follows: 289 For a given Traffic Class (TC) and a remote prefix SID S, N SHOULD 290 maintain counter(s) for traffic forwarded towards S. 292 2.3.3. Per-prefix SID, per egress interface traffic counter 293 (PSID.INT.E) 295 This counter is defined as follows: 297 For a given egress interface (INT.E) and a remote prefix SID S, N 298 SHOULD maintain counter(s) for traffic forwarded towards S over the 299 (INT.E) interface. 301 2.3.4. Per-prefix SID per TC per egress interface traffic counter 302 (PSID.INT.E.TC) 304 This counter provides per Traffic Class (TC) breakdown of PSID.INT.E. 305 It is defined as follows: 307 For a given Traffic Class (TC), an egress interface (INT.E) and a 308 remote prefix SID S, N MAY maintain counter(s) for traffic forwarded 309 towards S over the (INT.E) interface. 311 2.3.5. Per-prefix SID, per ingress interface traffic counter 312 (PSID.INT.I) 314 This counter is defined as follows: 316 For a given ingress interface (INT.I) and a remote prefix SID S, N 317 MAY maintain counter(s) for the traffic received on I and forwarded 318 towards S. 320 2.3.6. Per-prefix SID, per TC, per ingress interface traffic counter 321 (PSID.INT.I.TC) 323 This counter provides per Traffic Class (TC) breakdown of PSID.INT.I. 324 It is defined as follows: 326 For a given Traffic Class (TC), ingress interface (INT.I), and a 327 remote prefix SID S, N MAY maintain counter(s) for the traffic 328 received on I and forwarded towards S. 330 2.4. Traffic Matrix Counters 332 A traffic matrix T(N, M) is the amount of traffic entering the 333 network at node N and leaving the network at node M, where N and M 334 are border nodes at an arbitrarily defined boundary in the network 335 [Traffic-Matrices] is. The TM border defines the arbitrary boundary 336 nodes of a contiguous portion of the network across which service 337 providers wish to measure traffic flows. The traffic matrix (also 338 called demand matrix) contains all the demands crossing the TM 339 border. It has as many rows as ingress edge nodes and as many 340 columns as egress edge nodes at the TM border. The demand D(N, M) is 341 the cell of the matrix at row N and column M. In other words, a 342 Traffic Matrix provides, for every ingress point N into the network 343 and every egress point M out of the network, the volume of traffic 344 T(N, M) from N to M over a given time interval. To measure the 345 traffic matrix, nodes in an SR network designate its interfaces as 346 either internal or external. 348 When Node N receives a packet destined to remote prefix SID M, N 349 maintains the following counters. These counters include accounting 350 due to push, pop or swap operations. 352 2.4.1. Per-Prefix SID Traffic Matrix counter (PSID.E.TM) 354 This counter is defined as follows: 356 For a given remote prefix SID M, N SHOULD maintain counter(s) for all 357 the traffic received on any external interfaces and forwarded towards 358 M. 360 2.4.2. Per-Prefix, Per TC SID Traffic Matrix counter (PSID.E.TM.TC) 362 This counter provides per Traffic Class (TC) breakdown of PSID.E.TM. 363 It is defined as follows: 365 For a given Traffic Class (TC) and a remote prefix SID M, N SHOULD 366 maintain counter(s) for all the traffic received on any external 367 interfaces and forwarded towards M. 369 2.5. SR Policy Counters 371 Per policy counters are only maintained at the policy head-end node. 372 For each SR policy [I-D.filsfils-spring-segment-routing-policy] , the 373 head-end node maintains the following counters. 375 2.5.1. Per-SR Policy Aggregate traffic counter (POL) 377 This counter includes both labelled and unlabelled steered traffic. 378 It is defined as: 380 For each SR policy (P), head-end node N MUST maintain counter(s) for 381 the aggregate traffic steered onto P. 383 2.5.2. Per-SR Policy labelled steered aggregate traffic counter 384 (POL.BSID) 386 This counter is defined as: 388 For each SR policy (P), head-end node N SHOULD maintain counter(s) 389 for the aggregate labelled traffic steered onto P. Please note that 390 labelled steered traffic refers to incoming packets with an active 391 SID matching a local BSID of an SR policy at the head-end. 393 2.5.3. Per-SR Policy, per TC Aggregate traffic counter (POL.TC) 395 This counter provides per Traffic Class (TC) breakdown of POL. It is 396 defined as follows: 398 For each SR policy (P) and a given Traffic Class (TC), head-end node 399 N SHOULD maintain counter(s) for the aggregate traffic (matching the 400 traffic class TC criteria) steered onto P. 402 2.5.4. Per-SR Policy, per TC labelled steered aggregate traffic counter 403 (POL.BSID.TC) 405 This counter provides per Traffic Class (TC) breakdown of POL.BSID. 406 It is defined as follows: 408 For each SR policy (P) and a given Traffic Class (TC), head-end node 409 N MAY maintain counter(s) for the aggregate labelled traffic steered 410 onto P. 412 2.5.5. Per-SR Policy, Per-Segment-List Aggregate traffic counter 413 (POL.SL) 415 This counter is defined as: 417 For each SR policy (P) and a given Segment-List (SL), head-end node N 418 SHOULD maintain counter(s) for the aggregate traffic steered onto the 419 Segment-List (SL) of P. 421 2.5.6. Per-SR Policy, Per-Segment-List labelled steered aggregate 422 traffic counter (POL.SL.BSID) 424 This counter is defined as: 426 For each SR policy (P) and a given Segment-List (SL), head-end node N 427 MAY maintain counter(s) for the aggregate labelled traffic steered 428 onto the Segment-List SL of P. Please note that labelled steered 429 traffic refers to incoming packets with an active SID matching a 430 local BSID of an SR policy at the head-end. 432 3. Security Considerations 434 This document does not define any new protocol extensions and does 435 not impose any additional security challenges. 437 4. IANA Considerations 439 This document has no actions for IANA. 441 5. Acknowledgement 443 The authors like to thank Kris Michielsen for his valuable comments 444 and suggestions. 446 6. Contributors 448 The following people have contributed to this document: 450 Ketan Talaulikar 451 Cisco Systems 452 Email: ketant@cisco.com 454 Siva Sivabalan 455 Cisco Systems 456 Email: msiva@cisco.com 458 Jose Liste 459 Cisco Systems 460 Email: jliste@cisco.com 462 Francois Clad 463 Cisco Systems 464 Email: fclad@cisco.com 466 Kamran Raza 467 Cisco Systems 468 Email: skraza@cisco.com 469 Shraddha Hegde 470 Juniper Networks 471 Email: shraddha@juniper.net 473 Gaurav Dawra 474 LinkedIn 475 Email: gdawra.ietf@gmail.com 477 Rick Morton 478 Bell Canada 479 Email: rick.morton@bell.ca 481 Dirk Steinberg 482 Steinberg Consulting 483 Email: dws@steinbergnet.net 485 Bruno Decraene 486 Orange Business Services 487 Email: bruno.decraene@orange.com 489 Stephane Litkowski 490 Orange Business Services 491 Email: stephane.litkowski@orange.com 493 Luay Jalil 494 Verizon 495 Email: luay.jalil@verizon.com 497 7. References 499 7.1. Normative References 501 [I-D.filsfils-spring-segment-routing-policy] 502 Filsfils, C., Sivabalan, S., Hegde, S., 503 daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, 504 b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., 505 Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste, 506 J., Clad, F., and K. Raza, "Segment Routing Policy 507 Architecture", draft-filsfils-spring-segment-routing- 508 policy-06 (work in progress), May 2018. 510 [I-D.ietf-spring-segment-routing] 511 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 512 Litkowski, S., and R. Shakir, "Segment Routing 513 Architecture", draft-ietf-spring-segment-routing-15 (work 514 in progress), January 2018. 516 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 517 Requirement Levels", BCP 14, RFC 2119, 518 DOI 10.17487/RFC2119, March 1997, 519 . 521 7.2. Informative References 523 [I-D.ali-spring-sr-traffic-accounting] 524 Ali, Z., Filsfils, C., Talaulikar, K., Sivabalan, S., 525 Liste, J., Horneffer, M., Raszuk, R., Litkowski, S., 526 Dawra, G., daniel.voyer@bell.ca, d., and R. Morton, 527 "Traffic Accounting in Segment Routing Networks", draft- 528 ali-spring-sr-traffic-accounting-01 (work in progress), 529 May 2018. 531 [Traffic-Matrices] 532 Schnitter, T-Systems, S. and M. Horneffer, T-Com, "Traffic 533 Matrices for MPLS Networks with LDP Traffic Statistics, 534 Proc. Networks2004, VDE-Verlag 2004", 2015. 536 Authors' Addresses 538 Clarence Filsfils 539 Cisco Systems, Inc. 541 Email: cfilsfil@cisco.com 543 Zafar Ali (editor) 544 Cisco Systems, Inc. 546 Email: zali@cisco.com 548 Martin Horneffer 549 Deutsche Telekom 551 Email: martin.horneffer@telekom.de 553 Daniel Voyer 554 Bell Canada 555 671 de la gauchetiere W 556 Montreal, Quebec H3B 2M8 557 Canada 559 Email: daniel.voyer@bell.ca 560 Muhammad Durrani 561 Equinix 563 Email: mdurrani@equinix.com 565 Robert Raszuk 566 Bloomberg LP 568 Email: robert@raszuk.net