idnits 2.17.1 draft-irtf-nmrg-autonomic-sla-violation-detection-11.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 1, 2017) is 2428 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'LMAP' is mentioned on line 533, but not defined == Missing Reference: 'IPFIX' is mentioned on line 541, but not defined == Missing Reference: 'ALTO' is mentioned on line 550, but not defined == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-09 -- Obsolete informational reference (is this intentional?): RFC 4148 (Obsoleted by RFC 6248) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Management Research Group J. Nobre 3 Internet-Draft University of Vale do Rio dos Sinos 4 Intended status: Informational L. Granville 5 Expires: March 5, 2018 Federal University of Rio Grande do Sul 6 A. Clemm 7 Huawei 8 A. Gonzalez Prieto 9 VMware 10 September 1, 2017 12 Autonomic Networking Use Case for Distributed Detection of SLA 13 Violations 14 draft-irtf-nmrg-autonomic-sla-violation-detection-11 16 Abstract 18 This document describes an experimental use case for autonomic 19 networking concerning monitoring of Service Level Agreements (SLAs). 20 The use case aims to detect violations of SLAs in a distributed 21 fashion, striving to optimize and dynamically adapt the autonomic 22 deployment of active measurement probes in a way that maximizes the 23 likelihood of detecting service level violations with a given 24 resource budget to perform active measurements, and is able to do so 25 without any outside guidance or intervention. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 5, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 5 63 3. Current Approaches . . . . . . . . . . . . . . . . . . . . . 6 64 4. Use Case Description . . . . . . . . . . . . . . . . . . . . 6 65 5. A Distributed Autonomic Solution . . . . . . . . . . . . . . 7 66 6. Intended User Experience . . . . . . . . . . . . . . . . . . 10 67 7. Implementation Considerations . . . . . . . . . . . . . . . . 10 68 7.1. Device Based Self-Knowledge and Decisions . . . . . . . . 11 69 7.2. Interaction with other devices . . . . . . . . . . . . . 11 70 8. Comparison with current solutions . . . . . . . . . . . . . . 11 71 9. Related IETF Work . . . . . . . . . . . . . . . . . . . . . . 11 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 13. Informative References . . . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 The Internet has been growing dramatically in terms of size, 81 capacity, and accessibility in the last years. Communication 82 requirements of distributed services and applications running on top 83 of the Internet have become increasingly demanding. Some examples 84 are real-time interactive video or financial trading. Providing such 85 services involves stringent requirements in terms of acceptable 86 latency, loss, or jitter. 88 Performance requirements lead to the articulation of Service Level 89 Objectives (SLOs) which must be met. Those SLOs are part of Service 90 Level Agreements (SLAs) that define a contract between the provider 91 and the consumer of a service. SLOs, in effect, constitute a service 92 level guarantee that the consumer of the service can expect to 93 receive (and often has to pay for). Likewise, the provider of a 94 service needs to ensure that the service level guarantee and 95 associated SLOs are met. Some examples of clauses that relate to 96 service level objectives can be found in [RFC7297]). 98 Violations of SLOs can be associated with significant financial loss, 99 which can by divided into two categories. For one, there is the loss 100 that can be incurred by the user of a service when the agreed service 101 levels are not provided. For example, a financial brokerage's stock 102 orders might suffer losses when it is unable to execute stock 103 transactions in a timely manner. An electronic retailer may lose 104 customers when their online presence is perceived by customers as 105 sluggish. An online gaming provider may not be able to provide fair 106 access to online players, resulting in frustrated players who are 107 lost as customers. In each case, the failure of a service provider 108 to meet promised service level guarantees can have a substantial 109 financial impact on users of the service. By the same token, there 110 is the loss that is incurred by the provider of a service who is 111 unable to meet promised service level objectives. Those losses can 112 take several forms, such as penalties for not meeting the service 113 and, in many cases more important, loss of revenue due to reduced 114 customer satisfaction. Hence, service level objectives are a key 115 concern for the service provider. In order to ensure that SLOs are 116 not being violated, service levels need to be continuously monitored 117 at the network infrastructure layer in order to know, for example, 118 when mitigating actions need to be taken. To that end, service level 119 measurements must take place. 121 Network measurements can be performed using active or passive 122 measurement techniques. In passive measurements, production traffic 123 is observed and no monitoring traffic is created by the measurement 124 process itself. That is, network conditions are checked in a non 125 intrusive way. In the context of IP Flow Information eXport (IPFIX), 126 several documents were produced that define how to export data 127 associated with flow records, i.e. data that is collected as part of 128 passive measurement mechanisms, generally applied against flows of 129 production traffic (e.g., [RFC7011]). In addition, it would be 130 possible to collect real data traffic (not just summarized flow 131 records) with time-stamped packets, possibly sampled (e.g., per 132 [RFC5474], as a means of measuring and inferring service levels. 133 Active measurements, on the other hand, are more intrusive to the 134 network in the sense that it involves injecting synthetic test 135 traffic into the network to measure network service levels, as 136 opposed to simply observing production traffic. The IP Performance 137 Metrics (IPPM) WG produced documents that describe active measurement 138 mechanisms, such as: One-Way Active Measurement Protocol (OWAMP) 139 [RFC4656], Two-Way Active Measurement Protocol (TWAMP) [RFC5357], and 140 Cisco Service Level Assurance Protocol (SLA) [RFC6812]. In addition, 141 there are some mechanisms that do not cleanly fit into either active 142 or passive categories, such as Performance and Diagnostic Metrics 143 Destination Option (PDM) techniques 144 [draft-ietf-ippm-6man-pdm-option]. 146 Active measurement mechanisms offer a high level of control of what 147 and how to measure. They do not require inspecting production 148 traffic. Because of this, active measurements usually offer better 149 accuracy and privacy than passive measurement mechanisms. Traffic 150 encryption and regulations that limit the amount of payload 151 inspection that can occur are non-issues. Furthermore, active 152 measurement mechanisms are able to detect end-to-end network 153 performance problems in a fine-grained way (e.g., simulating the 154 traffic that must be handled considering specific Service Level 155 Objectives - SLOs). As a result, active measurements are often 156 preferred over passive measurement for SLA monitoring. Measurement 157 probes must be hosted in network devices and measurement sessions 158 must be activated to compute the current network metrics (e.g., 159 considering those described in [RFC4148]). This activation should be 160 dynamic in order to follow changes in network conditions, such as 161 those related with routes being added or new customer demands. 163 While offering many advantages, active measurements are expensive in 164 terms of network resource consumption. Active measurements generally 165 involve measurement probes that generate synthetic test traffic that 166 is directed at a responder. The responder needs to timestamp test 167 traffic it receives and reflect it back to the originating 168 measurement probe. The measurement probe subsequently processes the 169 returned packets along with time stamping information in order to 170 compute service levels. Accordingly, active measurements consume 171 substantial CPU cycles as well as memory of network devices to 172 generate and process test traffic. In addition, synthetic traffic 173 increases network load. Active measurements thus compete for 174 resources with other functions, including routing and switching. 176 The resources required and traffic generated by the active 177 measurement sessions are to a large part a function of the number of 178 measured network destinations. (In addition, the amount of traffic 179 generated for each measurement plays a role, which in turn influences 180 the accuracy of the measurement.) The more destinations are being 181 measured, the larger the amount of resources consumed and traffic 182 needed to perform the measurements. Thus, to have a better 183 monitoring coverage it is necessary to deploy more sessions which 184 consequently increases consumed resources. Otherwise, enabling the 185 observation of just a small subset of all network flows can lead to 186 an insufficient coverage. 188 Furthermore, while some end-to-end service levels can be determined 189 by adding up the service levels observed across different path 190 segments, the same is not true for all service levels. For example, 191 the end-to-end delay or packet loss from a node A to a node C routed 192 via a node B can often be computed simply by adding delays (or loss) 193 from A to B, and B to C. This allows to decompose a large set of 194 end-to-end measurements into a much smaller set of segment 195 measurements. However, end-to-end jitter and (for example) Mean 196 Opinion Scores cannot be decomposed as easily and, for higher 197 accuracy, must be measured end-to-end. 199 Hence, the decision how to place measurement probes becomes an 200 important management activity. The goal is to obtain maximum 201 benefits of service level monitoring with a limited amount of 202 measurement overhead. Specifically, the goal is to maximize the 203 number of service level violations that are detected with a limited 204 amount of resources. 206 The use case and the solution approach described in this document 207 address an important practical issue. They are intended to provide a 208 basis for further experimentation to lead into solutions for wider 209 deployment. 211 2. Definitions and Acronyms 213 Active Measurements: Techniques to measure service levels that 214 involve generating and observing synthetic test traffic 216 Passive Measurements: Techniques used to measure service levels based 217 on observation of production traffic 219 AN: Autonomic Network; a network containing exclusively autonomic 220 nodes, requiring no configuration and deriving all required 221 information through self-knowledge, discovery, or intent. 223 Autonomic Service Agent (ASA): An agent implemented on an autonomic 224 node that implements an autonomic function, either in part (in the 225 case of a distributed function, as in the context of this document), 226 or whole. 228 Measurement Session: A communications association between a Probe and 229 a Responder used to send and reflect synthetic test traffic for 230 active measurements 232 Probe: The source of synthetic test traffic in an active measurement 234 Responder: The destination for synthetic test traffic in an active 235 measurement 237 SLA: Service Level Agreement 239 SLO: Service Level Objective 241 P2P: Peer-to-Peer 242 (Note: definitions of AN and ASA are borrowed from [RFC7575]). 244 3. Current Approaches 246 The current best practice in feasible deployments of active 247 measurement solutions to distribute the available measurement 248 sessions along the network consists in relying entirely on the human 249 administrator expertise to infer which would be the best location to 250 activate such sessions. This is done through several steps. First, 251 it is necessary to collect traffic information in order to grasp the 252 traffic matrix. Then, the administrator uses this information to 253 infer which are the best destinations for measurement sessions. 254 After that, the administrator activates sessions on the chosen subset 255 of destinations considering the available resources. This practice, 256 however, does not scale well because it is still labor intensive and 257 error-prone for the administrator to determine which sessions should 258 be activated given the set of critical flows that needs to be 259 measured. Even worse, this practice completely fails in networks 260 whose critical flows are too short in time and dynamic in terms of 261 traversing network path, like in modern cloud environments. That is 262 so because fast reactions are necessary to reconfigure the sessions 263 and administrators are not just enough in computing and activating 264 the new set of required sessions every time the network traffic 265 pattern changes. Finally, the current active measurements practice 266 usually covers only a fraction of the network flows that should be 267 observed, which invariably leads to the damaging consequence of 268 undetected SLA violations. 270 4. Use Case Description 272 The use case involves a service level provider who needs to monitor 273 the network to detect service level violations using active service 274 level measurements, and wants to be able to do so with minimal human 275 intervention. The goal is to conduct the measurements in an 276 effective manner maximizing the percentage of detected service level 277 violations. The service level provider has a bounded resource budget 278 with regards to measurements that can be performed, specifically, 279 with regards to the number of measurements that can be conducted 280 concurrently from any one network device, and possibly with regards 281 to the total amount of measurement traffic on the network. However, 282 while at any one point in time the number of measurements conducted 283 is limited, it is possible for a device to change which destinations 284 to measure over time. This can be exploited to achieve a balance of 285 eventually covering all possible destinations using a reasonable 286 amount of "sampling" where measurement coverage of a destination 287 cannot be continuous. The solution needs to be dynamic and be able 288 to cope with network conditions which may change over time. The 289 solution should also be embeddable inside network devices that 290 control the deployment of active measurement mechanisms. 292 The goal is to conduct the measurements in a smart manner that 293 ensures that the network is broadly covered and the likelihood of 294 detecting service level violations is maximized. In order to 295 maximize that likelihood, it is reasonable to focus measurement 296 resources on destinations that are more likely to incur a violation, 297 while spending less resources on destinations that are more likely to 298 be in compliance. In order to do so, there are various aspects that 299 can be exploited, including past measurements (destinations close to 300 a service level threshold requiring more focus than destinations 301 further from it), complementation with passive measurements such as 302 flow data (to identify network destinations that are currently 303 popular and critical), and observations from other parts of the 304 network. In addition, measurements can be coordinated among 305 different network devices to avoid hitting the same destination at 306 the same time and to be able to share results that may be useful in 307 future probe placement. 309 Clearly, static solutions will have severe limitations. At the same 310 time, human administrators cannot be in the loop for continuous 311 dynamic measurement probe reconfigurations. Accordingly, an 312 automated or, ideally, autonomic solution is needed in which network 313 measurements are automatically orchestrated and dynamically 314 reconfigured from within the network. This can be accomplished using 315 an autonomic solution that is distributed, using Autonomic Service 316 Agents that are implemented on nodes in the network. 318 5. A Distributed Autonomic Solution 320 The use of Autonomic Networking (AN) [RFC7575] can help such 321 detection through an efficient activation of measurement sessions. 322 Such an approach, along with a detailed assessment confirming its 323 viability, has been described [P2PBNM-Nobre-2012]. The problem to be 324 solved by AN in the present use case is how to steer the process of 325 Measurement Session activation by a complete solution that sets all 326 necessary parameters for this activation to operate efficiently, 327 reliably and securely, with no required human intervention other than 328 setting overall policy. 330 When a node first comes online, it has no information about which 331 measurements are more critical than others. In the absence of 332 information about past measurements and information from measurement 333 peers, it may start with an initial set of measurement sessions, 334 possibly randomly seeding a set of starter measurements, perhaps 335 taking a round robin approach for subsequent measurement rounds. 336 However, as measurements are collected, a node will gain increasing 337 information that it can utilize to refine its strategy of selecting 338 measurement targets going forward. For one, it may take note of 339 which targets returned measurement results very close to service 340 level thresholds that may therefore require closer scrutiny compared 341 to others. Second, it may utilize observations that are made by its 342 measurement peers in order to conclude which measurement targets may 343 be more critical than others, and in order to ensure that proper 344 overall measurement coverage is obtained (so that not every node 345 incidentally measure the same targets, while other targets are not 346 measured at all). 348 We advocate for embedding Peer-to-Peer (P2P) technology in network 349 devices in order to conduct the Measurement Session activation 350 decisions using autonomic control loops. Specifically, we advocate 351 for network devices to implement an autonomic function to monitor 352 service levels for violations of service level objectives, 353 determining which Measurement Sessions to set up at any given point 354 in time based on current and past observations of the node, and of 355 other peer nodes. 357 By performing these functions locally and autonomically on the device 358 itself, which measurements to conduct can be modified quickly based 359 on local observations while taking local resource availability into 360 account. This allows a solution to be more robust and react more 361 dynamically to rapidly changing service levels than a solution that 362 has to rely on central coordination. However, in order to optimize 363 decisions which measurements to conduct, a node will need to 364 communicate with other nodes. This allows a node to take into 365 account other nodes' observations in addition to its own in its 366 decisions. 368 For example, remote destinations whose observed service levels are on 369 the verge of violating stated objectives may require closer 370 monitoring than remote destinations that are comfortably within a 371 range of tolerance. It also allows nodes to coordinate their probing 372 decisions to collectively achieve the best possible measurement 373 coverage. As the amount of resources available for monitoring and 374 for exchange of measurement data and coordination with other nodes 375 are limited, a node may further be interested in identifying other 376 nodes whose observations are most similar to and correlated with its 377 own. This helps a node prioritize and guide with which other nodes 378 to primarily coordinate and exchange data with. All of this requires 379 the use of a P2P overlay. 381 A P2P overlay is essential for several reasons: 383 o It makes it possible for nodes (respectively Autonomic Service 384 Agents that are deployed on those nodes) in the network to 385 autonomically set up Measurement Sessions, without having to rely 386 on central management system or controller to perform 387 configuration operations associated with configuring measurement 388 probes and responders. 390 o It facilitates the exchange of data between different nodes to 391 share measurement results so that each node can refine its 392 measurement strategy based not just its own observations, but 393 observations from its peers. 395 o It allows nodes to coordinate their measurements to obtain the 396 best possible test coverage and avoid measurements that have a 397 very low likelihood of detecting service level violations. 399 The provisioning of the P2P overlay should be transparent for the 400 network administrator. An Autonomic Control Plane such as defined in 401 [I-D.anima-autonomic-control-plane] provides an ideal candidate for 402 the P2P overlay to run on. 404 An autonomic solution for the distributed detection of SLA violations 405 provide several benefits. First, efficiency: this solution should 406 optimize the resource consumption and avoid resource starvation on 407 the network devices. A device that is "self-aware" of its available 408 resources will be able to adjust measurement activities rapidly as 409 needed, without requiring a separate control loop involving resource 410 monitoring by an external system. Secondly, placing logic where to 411 conduct measurements in the node enables rapid control loops in which 412 devices are able to react instantly to observations and adjust their 413 measurement strategy. For example, a device could decide to adjust 414 the amount of synthetic test traffic being sent during the 415 measurement itself depending on results observed so far on this and 416 on other concurrent measurement sessions. As a result, the solution 417 could decrease the time necessary to detect SLA violations. 418 Adaptivity features of an autonomic loop could capture faster the 419 network dynamics than an human administrator and even a central 420 controller. Finally, the solution could help to reduce the workload 421 of human administrator, or, at least, to avoid their need to perform 422 operational tasks. 424 In practice, these factors combine to maximize the likelihood of SLA 425 violations being detected while operating within a given resource 426 budget, allowing to conduct a continuous measurement strategy that 427 takes into account past measurement results, observations of other 428 measures such as link utilization or flow data, sharing of 429 measurement results between network devices, and coordinating future 430 measurement activities among nodes. Combined this can result in 431 efficient measurement decisions that achieve a golden balance between 432 broad network coverage and honing in on service level "hot spots". 434 6. Intended User Experience 436 The autonomic solution should not require any human intervention in 437 the distributed detection of SLA violations. By virtue of the 438 solution being autonomic, human users will not have to plan which 439 measurements to conduct in a network, often a very labor intensive 440 task today that requires detailed analysis of traffic matrices and 441 network topologies and is not prone to easy dynamic adjustment. 442 Likewise, they will not have to configure measurement probes and 443 responders. 445 There are some ways in which a human administrator may still interact 446 with the solution. For one, the human administrator will of course 447 be notified and obtain reports about service level violations that 448 are observed. Second, a human administrator may set a policies 449 regarding how closely to monitor the network for service level 450 violations and how many resources to spend. For example, an 451 administrator may set a resource budget that is assigned to network 452 devices for measurement operations. With that given budget, the 453 number of SLO violations that are detected will be maximized. 454 Alternatively, an administrator may set a target for the percentage 455 of SLO violations that must be detected, i.e. a target for the ratio 456 between the number of detected SLO violations, and the number of 457 total SLO violations that are actually occurring (some of which might 458 go undetected). In that case, the solution will aim to minimize the 459 resources spent (i.e. the amount of test traffic and Measurement 460 Sessions) that are required to achieve that target. 462 7. Implementation Considerations 464 The active measurement model assumes that a typical infrastructure 465 will have multiple network segments and Autonomous Systems (ASs), and 466 a reasonably large number of routers. It also considers that 467 multiple SLOs can be in place at a given time. Since 468 interoperability in a heterogenous network is a goal, features found 469 on different active measurement mechanisms (e.g. OWAMP, TWAMP, and 470 IPSLA) and device programability interfaces (such as Juniper's Junos 471 API or Cisco's Embedded Event Manager) could be used for the 472 implementation. The autonomic solution should include and/or 473 reference specific algorithms, protocols, metrics and technologies 474 for the implementation of distributed detection of SLA violations as 475 a whole. 477 Finally, it should be noted that there are multiple deployment 478 scenarios, including deployment scenarios that involve physical 479 devices hosting autonomic functions, or virtualized infrastructure 480 hosting the same. Co-deployment in conjunction with Virtual Network 481 Functions (VNF) is a possibility for further study. 483 7.1. Device Based Self-Knowledge and Decisions 485 Each device has self-knowledge about the local SLA monitoring. This 486 could be in the form of historical measurement data and SLOs. 487 Besides that, the devices would have algorithms that could decide 488 which probes should be activated in a given time. The choice of 489 which algorithm is better for a specific situation would be also 490 autonomic. 492 7.2. Interaction with other devices 494 Network devices should share information about service level 495 measurement results. This information can speed up the detection of 496 SLA violations and increase the number of detected SLA violations. 497 For example, if one device detects that a remote destination is in 498 danger of violating an SLO, other devices may conduct additional 499 measurements to the same destination or other destinations in its 500 proximity. For any given network device, the exchange of data may be 501 more important with some devices (for example, devices in the same 502 network neighborhood, or devices that are "correlated" by some other 503 means) than with others. The definition of network devices that 504 exchange measurement data, i.e., management peers, creates a new 505 topology. Different approaches could be used to define this topology 506 (e.g., correlated peers [P2PBNM-Nobre-2012]). To bootstrap peer 507 selection, each device should use its known endpoints neighbors 508 (e.g., FIB and RIB tables) as the initial seed to get possible peers. 509 It should be noted that a solution will benefit if topology 510 information and network discovery functions are provided by the 511 underlying autonomic framework. A solution will need to be able to 512 discover measurement peers as well as measurement targets, 513 specifically measurement targets that support active measurement 514 responders and which will be able to respond to measurement requests 515 and reflect measurement traffic as needed. 517 8. Comparison with current solutions 519 There is no standardized solution for distributed autonomic detection 520 of SLA violations. Current solutions are restricted to ad hoc 521 scripts running on a per node fashion to automate some 522 administrator's actions. There are some proposals for passive probe 523 activation (e.g., DECON and CSAMP), but without the focus on 524 autonomic features. 526 9. Related IETF Work 528 The following paragraphs discuss related IETF work and are provided 529 for reference. This section is not exhaustive, rather it provides an 530 overview of the various initiatives and how they relate to autonomic 531 distributed detection of SLA violations. 533 1. [LMAP]: The Large-Scale Measurement of Broadband Performance 534 Working Group aims at the standards for performance management. 535 Since their mechanisms also consist in deploying measurement 536 probes the autonomic solution could be relevant for LMAP 537 specially considering SLA violation screening. Besides that, a 538 solution to decrease the workload of human administrators in 539 service providers is probably highly desirable. 541 2. [IPFIX]: IP Flow Information EXport (IPFIX) aims at the process 542 of standardization of IP flows (i.e., netflows). IPFIX uses 543 measurement probes (i.e., metering exporters) to gather flow 544 data. In this context, the autonomic solution for the activation 545 of active measurement probes could be possibly extended to 546 address also passive measurement probes. Besides that, flow 547 information could be used in the decision making of probe 548 activation. 550 3. [ALTO]: The Application Layer Traffic Optimization Working Group 551 aims to provide topological information at a higher abstraction 552 layer, which can be based upon network policy, and with 553 application-relevant service functions located in it. Their work 554 could be leveraged for the definition of the topology regarding 555 the network devices which exchange measurement data. 557 10. Acknowledgements 559 We wish to acknowledge the helpful contributions, comments, and 560 suggestions that were received from Mohamed Boucadair, Brian 561 Carpenter, Hanlin Fang, Bruno Klauser, Diego Lopez, Vincent Roca, and 562 Eric Voit. 564 11. IANA Considerations 566 This memo includes no request to IANA. 568 12. Security Considerations 570 Security of the solution hinges on the security of the network 571 underlay, i.e. the Autonomic Control Plane. If the Autonomic Control 572 Plane were to be compromised, an attacker could undermine the 573 effectiveness of measurement coordination by reporting fraudulent 574 measurement results to peers. This would cause measurement probes to 575 be deployed in an ineffective manner that would increase the 576 likelihood that violations of service level objectives go undetected. 578 Likewise, security of the solution hinges on the security of the 579 deployment mechanism for autonomic functions, in this case, the 580 autonomic function that conducts the service level measurements. If 581 an attacker were able to hijack an autonomic function, it could try 582 to exhaust or exceed the resources that should be spent on autonomic 583 measurements in order to deplete network resources, including network 584 bandwidth due to higher-than-necessary volumes of synthetic test 585 traffic generated by measurement probes. Again, it could also lead 586 to reporting of misleading results, among other things resulting in 587 non-optimal selection of measurement targets and in turn an increase 588 in the likelihood that service level violations go undetected. 590 13. Informative References 592 [draft-anima-boot] 593 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 594 S., and K. Watsen, "draft-ietf-anima-bootstrapping- 595 keyinfra", draft-ietf-anima-bootstrapping-keyinfra-06 596 (work in progress), May 2017. 598 [draft-ietf-ippm-6man-pdm-option] 599 Elkins, N., Hamilton, R., and M. Ackermann, "draft-ietf- 600 ippm-6man-pdm-option", draft-ietf-ippm-6man-pdm-option-11 601 (work in progress), June 2017. 603 [I-D.anima-autonomic-control-plane] 604 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 605 Control Plane", draft-ietf-anima-autonomic-control- 606 plane-09 (work in progress), August 2017. 608 [P2PBNM-Nobre-2012] 609 Nobre, J., Granville, L., Clemm, A., and A. Gonzalez 610 Prieto, "Decentralized Detection of SLA Violations Using 611 P2P Technology, 8th International Conference Network and 612 Service Management (CNSM)", 2012, 613 . 616 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 617 Registry", BCP 108, RFC 4148, DOI 10.17487/RFC4148, August 618 2005, . 620 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 621 Zekauskas, "A One-way Active Measurement Protocol 622 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 623 . 625 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 626 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 627 RFC 5357, DOI 10.17487/RFC5357, October 2008, 628 . 630 [RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., 631 Grossglauser, M., and J. Rexford, "A Framework for Packet 632 Selection and Reporting", RFC 5474, DOI 10.17487/RFC5474, 633 March 2009, . 635 [RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, 636 S., and E. Yedavalli, "Cisco Service-Level Assurance 637 Protocol", RFC 6812, DOI 10.17487/RFC6812, January 2013, 638 . 640 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 641 "Specification of the IP Flow Information Export (IPFIX) 642 Protocol for the Exchange of Flow Information", STD 77, 643 RFC 7011, DOI 10.17487/RFC7011, September 2013, 644 . 646 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 647 Connectivity Provisioning Profile (CPP)", RFC 7297, 648 DOI 10.17487/RFC7297, July 2014, . 651 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 652 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 653 Networking: Definitions and Design Goals", RFC 7575, 654 DOI 10.17487/RFC7575, June 2015, . 657 Authors' Addresses 659 Jeferson Campos Nobre 660 University of Vale do Rio dos Sinos 661 Porto Alegre 662 Brazil 664 Email: jcnobre@unisinos.br 666 Lisandro Zambenedetti Granvile 667 Federal University of Rio Grande do Sul 668 Porto Alegre 669 Brazil 671 Email: granville@inf.ufrgs.br 672 Alexander Clemm 673 Huawei 674 Santa Clara, California 675 USA 677 Email: ludwig@clemm.org 679 Alberto Gonzalez Prieto 680 VMware 681 Palo Alto, California 682 USA 684 Email: agonzalezpri@vmware.com