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