idnits 2.17.1 draft-irtf-nmrg-autonomic-sla-violation-detection-10.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 (July 1, 2017) is 2484 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'LMAP' is mentioned on line 529, but not defined == Missing Reference: 'IPFIX' is mentioned on line 537, but not defined == Missing Reference: 'ALTO' is mentioned on line 546, but not defined == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-06 -- 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: January 2, 2018 Federal University of Rio Grande do Sul 6 A. Clemm 7 Huawei 8 A. Gonzalez Prieto 9 VMware 10 July 1, 2017 12 Autonomic Networking Use Case for Distributed Detection of SLA 13 Violations 14 draft-irtf-nmrg-autonomic-sla-violation-detection-10 16 Abstract 18 This document describes a use case for autonomic networking 19 concerning monitoring of Service Level Agreements (SLAs). The use 20 case aims to detect violations of SLAs in a distributed fashion, 21 striving to optimize and dynamically adapt the autonomic deployment 22 of active measurement probes in a way that maximizes the likelihood 23 of detecting service level violations with a given resource budget to 24 perform active measurements, and is able to do so without any outside 25 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 January 2, 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 2. Definitions and Acronyms 208 Active Measurements: Techniques to measure service levels that 209 involve generating and observing synthetic test traffic 211 Passive Measurements: Techniques used to measure service levels based 212 on observation of production traffic 214 AN: Autonomic Network; a network containing exclusively autonomic 215 nodes, requiring no configuration and deriving all required 216 information through self-knowledge, discovery, or intent. 218 Autonomic Service Agent (ASA): An agent implemented on an autonomic 219 node that implements an autonomic function, either in part (in the 220 case of a distributed function, as in the context of this document), 221 or whole. 223 Measurement Session: A communications association between a Probe and 224 a Responder used to send and reflect synthetic test traffic for 225 active measurements 227 Probe: The source of synthetic test traffic in an active measurement 229 Responder: The destination for synthetic test traffic in an active 230 measurement 232 SLA: Service Level Agreement 234 SLO: Service Level Objective 236 P2P: Peer-to-Peer 238 (Note: definitions of AN and ASA are borrowed from [RFC7575]). 240 3. Current Approaches 242 The current best practice in feasible deployments of active 243 measurement solutions to distribute the available measurement 244 sessions along the network consists in relying entirely on the human 245 administrator expertise to infer which would be the best location to 246 activate such sessions. This is done through several steps. First, 247 it is necessary to collect traffic information in order to grasp the 248 traffic matrix. Then, the administrator uses this information to 249 infer which are the best destinations for measurement sessions. 250 After that, the administrator activates sessions on the chosen subset 251 of destinations considering the available resources. This practice, 252 however, does not scale well because it is still labor intensive and 253 error-prone for the administrator to determine which sessions should 254 be activated given the set of critical flows that needs to be 255 measured. Even worse, this practice completely fails in networks 256 whose critical flows are too short in time and dynamic in terms of 257 traversing network path, like in modern cloud environments. That is 258 so because fast reactions are necessary to reconfigure the sessions 259 and administrators are not just enough in computing and activating 260 the new set of required sessions every time the network traffic 261 pattern changes. Finally, the current active measurements practice 262 usually covers only a fraction of the network flows that should be 263 observed, which invariably leads to the damaging consequence of 264 undetected SLA violations. 266 4. Use Case Description 268 The use case involves a service level provider who needs to monitor 269 the network to detect service level violations using active service 270 level measurements, and wants to be able to do so with minimal human 271 intervention. The goal is to conduct the measurements in an 272 effective manner maximizing the percentage of detected service level 273 violations. The service level provider has a bounded resource budget 274 with regards to measurements that can be performed, specifically, 275 with regards to the number of measurements that can be conducted 276 concurrently from any one network device, and possibly with regards 277 to the total amount of measurement traffic on the network. However, 278 while at any one point in time the number of measurements conducted 279 is limited, it is possible for a device to change which destinations 280 to measure over time. This can be exploited to achieve a balance of 281 eventually covering all possible destinations using a reasonable 282 amount of "sampling" where measurement coverage of a destination 283 cannot be continuous. The solution needs to be dynamic and be able 284 to cope with network conditions which may change over time. The 285 solution should also be embeddable inside network devices that 286 control the deployment of active measurement mechanisms. 288 The goal is to conduct the measurements in a smart manner that 289 ensures that the network is broadly covered and the likelihood of 290 detecting service level violations is maximized. In order to 291 maximize that likelihood, it is reasonable to focus measurement 292 resources on destinations that are more likely to incur a violation, 293 while spending less resources on destinations that are more likely to 294 be in compliance. In order to do so, there are various aspects that 295 can be exploited, including past measurements (destinations close to 296 a service level threshold requiring more focus than destinations 297 further from it), complementation with passive measurements such as 298 flow data (to identify network destinations that are currently 299 popular and critical), an observations from other parts of the 300 network. In addition, measurements can be coordinated among 301 different network devices to avoid hitting the same destination at 302 the same time and to be able to share results that may be useful in 303 future probe placement. 305 Clearly, static solutions will have severe limitations. At the same 306 time, human administrators cannot be in the loop for continuous 307 dynamic measurement probe reconfigurations. Accordingly, an 308 automated or, ideally, autonomic solution is needed in which network 309 measurements are automatically orchestrated and dynamically 310 reconfigured from within the network. This can be accomplished using 311 an autonomic solution that is distributed, using Autonomic Service 312 Agents that are implemented on nodes in the network. 314 5. A Distributed Autonomic Solution 316 The use of Autonomic Networking (AN) [RFC7575] can help such 317 detection through an efficient activation of measurement sessions. 318 Such an approach, along with a detailed assessment confirming its 319 viability, has been described [P2PBNM-Nobre-2012]. The problem to be 320 solved by AN in the present use case is how to steer the process of 321 Measurement Session activation by a complete solution that sets all 322 necessary parameters for this activation to operate efficiently, 323 reliably and securely, with no required human intervention other than 324 setting overall policy. 326 When a node first comes online, it has no information about which 327 measurements are more critical than others. In the absence of 328 information about past measurements and information from measurement 329 peers, it may start with an initial set of measurement sessions, 330 possibly randomly seeding a set of starter measurements, perhaps 331 taking a round robin approach for subsequent measurement rounds. 332 However, as measurements are collected, a node will gain increasing 333 information that it can utilize to refine its strategy of selecting 334 measurement targets going forward. For one, it may take note of 335 which targets returned measurement results very close to service 336 level thresholds that may therefore require closer scrutiny compared 337 to others. Second, it may utilize observations that are made by its 338 measurement peers in order to conclude which measurement targets may 339 be more critical than others, and in order to ensure that proper 340 overall measurement coverage is obtained (so that not every node 341 incidentally measure the same targets, while other targets are not 342 measured at all). 344 We advocate for embedding Peer-to-Peer (P2P) technology in network 345 devices in order to conduct the Measurement Session activation 346 decisions using autonomic control loops. Specifically, we advocate 347 for network devices to implement an autonomic function to monitor 348 service levels for violations of service level objectives, 349 determining which Measurement Sessions to set up at any given point 350 in time based on current and past observations of the node, and of 351 other peer nodes. 353 By performing these functions locally and autonomically on the device 354 itself, which measurements to conduct can be modified quickly based 355 on local observations while taking local resource availability into 356 account. This allows a solution to be more robust and react more 357 dynamically to rapidly changing service levels than a solution that 358 has to rely on central coordination. However, in order to optimize 359 decisions which measurements to conduct, a node will need to 360 communicate with other nodes. This allows a node to take into 361 account other nodes' observations in addition to its own in its 362 decisions. 364 For example, remote destinations whose observed service levels are on 365 the verge of violating stated objectives may require closer 366 monitoring than remote destinations that are comfortably within a 367 range of tolerance. It also allows nodes to coordinate their probing 368 decisions to collectively achieve the best possible measurement 369 coverage. As the amount of resources available for monitoring and 370 for exchange of measurement data and coordination with other nodes 371 are limited, a node may further be interested in identifying other 372 nodes whose observations are most similar to and correlated with its 373 own. This helps a node prioritize and guide with which other nodes 374 to primarily coordinate and exchange data with. All of this requires 375 the use of a P2P overlay. 377 A P2P overlay is essential for several reasons: 379 o It makes it possible for nodes (respectively Autonomic Service 380 Agents that are deployed on those nodes) in the network to 381 autonomically set up Measurement Sessions, without having to rely 382 on central management system or controller to perform 383 configuration operations associated with configuring measurement 384 probes and responders. 386 o It facilitates the exchange of data between different nodes to 387 share measurement results so that each node can refine its 388 measurement strategy based not just its own observations, but 389 observations from its peers. 391 o It allows nodes to coordinate their measurements to obtain the 392 best possible test coverage and avoid measurements that have a 393 very low likelihood of detecting service level violations. 395 The provisioning of the P2P overlay should be transparent for the 396 network administrator. An Autonomic Control Plane such as defined in 397 [I-D.anima-autonomic-control-plane] provides an ideal candidate for 398 the P2P overlay to run on. 400 An autonomic solution for the distributed detection of SLA violations 401 provide several benefits. First, efficiency: this solution should 402 optimize the resource consumption and avoid resource starvation on 403 the network devices. A device that is "self-aware" of its available 404 resources will be able to adjust measurement activities rapidly as 405 needed, without requiring a separate control loop involving resource 406 monitoring by an external system. Secondly, placing logic where to 407 conduct measurements in the node enables rapid control loops in which 408 devices are able to react instantly to observations and adjust their 409 measurement strategy. For example, a device could decide to adjust 410 the amount of synthetic test traffic being sent during the 411 measurement itself depending on results observed so far on this and 412 on other concurrent measurement sessions. As a result, the solution 413 could decrease the time necessary to detect SLA violations. 414 Adaptivity features of an autonomic loop could capture faster the 415 network dynamics than an human administrator and even a central 416 controller. Finally, the solution could help to reduce the workload 417 of human administrator, or, at least, to avoid their need to perform 418 operational tasks. 420 In practice, these factors combine to maximize the likelihood of SLA 421 violations being detected while operating within a given resource 422 budget, allowing to conduct a continuous measurement strategy that 423 takes into account past measurement results, observations of other 424 measures such as link utilization or flow data, sharing of 425 measurement results between network devices, and coordinating future 426 measurement activities among nodes. Combined this can result in 427 efficient measurement decisions that achieve a golden balance between 428 broad network coverage and honing in on service level "hot spots". 430 6. Intended User Experience 432 The autonomic solution should not require any human intervention in 433 the distributed detection of SLA violations. By virtue of the 434 solution being autonomic, human users will not have to plan which 435 measurements to conduct in a network, often a very labor intensive 436 task today that requires detailed analysis of traffic matrices and 437 network topologies and is not prone to easy dynamic adjustment. 438 Likewise, they will not have to configure measurement probes and 439 responders. 441 There are some ways in which a human administrator may still interact 442 with the solution. For one, the human administrator will of course 443 be notified and obtain reports about service level violations that 444 are observed. Second, a human administrator may set a policies 445 regarding how closely to monitor the network for service level 446 violations and how many resources to spend. For example, an 447 administrator may set a resource budget that is assigned to network 448 devices for measurement operations. With that given budget, the 449 number of SLO violations that are detected will be maximized. 450 Alternatively, an administrator may set a target for the percentage 451 of SLO violations that must be detected, i.e. a target for the ratio 452 between the number of detected SLO violations, and the number of 453 total SLO violations that are actually occurring (some of which might 454 go undetected). In that case, the solution will aim to minimize the 455 resources spent (i.e. the amount of test traffic and Measurement 456 Sessions) that are required to achieve that target. 458 7. Implementation Considerations 460 The active measurement model assumes that a typical infrastructure 461 will have multiple network segments and Autonomous Systems (ASs), and 462 a reasonably large number of routers. It also considers that 463 multiple SLOs can be in place at a given time. Since 464 interoperability in a heterogenous network is a goal, features found 465 on different active measurement mechanisms (e.g. OWAMP, TWAMP, and 466 IPSLA) and device programability interfaces (such as Juniper's Junos 467 API or Cisco's Embedded Event Manager) could be used for the 468 implementation. The autonomic solution should include and/or 469 reference specific algorithms, protocols, metrics and technologies 470 for the implementation of distributed detection of SLA violations as 471 a whole. 473 Finally, it should be noted that there are multiple deployment 474 scenarios, including deployment scenarios that involve physical 475 devices hosting autonomic functions, or virtualized infrastructure 476 hosting the same. Co-deployment in conjunction with Virtual Network 477 Functions (VNF) is a possibility for further study. 479 7.1. Device Based Self-Knowledge and Decisions 481 Each device has self-knowledge about the local SLA monitoring. This 482 could be in the form of historical measurement data and SLOs. 483 Besides that, the devices would have algorithms that could decide 484 which probes should be activated in a given time. The choice of 485 which algorithm is better for a specific situation would be also 486 autonomic. 488 7.2. Interaction with other devices 490 Network devices should share information about service level 491 measurement results. This information can speed up the detection of 492 SLA violations and increase the number of detected SLA violations. 493 For example, if one device detects that a remote destination is in 494 danger of violating an SLO, other devices may conduct additional 495 measurements to the same destination or other destinations in its 496 proximity. For any given network device, the exchange of data may be 497 more important with some devices (for example, devices in the same 498 network neighborhood, or devices that are "correlated" by some other 499 means) than with others. The definition of network devices that 500 exchange measurement data, i.e., management peers, creates a new 501 topology. Different approaches could be used to define this topology 502 (e.g., correlated peers [P2PBNM-Nobre-2012]). To bootstrap peer 503 selection, each device should use its known endpoints neighbors 504 (e.g., FIB and RIB tables) as the initial seed to get possible peers. 505 It should be noted that a solution will benefit if topology 506 information and network discovery functions are provided by the 507 underlying autonomic framework. A solution will need to be able to 508 discover measurement peers as well as measurement targets, 509 specifically measurement targets that support active measurement 510 responders and which will be able to respond to measurement requests 511 and reflect measurement traffic as needed. 513 8. Comparison with current solutions 515 There is no standardized solution for distributed autonomic detection 516 of SLA violations. Current solutions are restricted to ad hoc 517 scripts running on a per node fashion to automate some 518 administrator's actions. There are some proposals for passive probe 519 activation (e.g., DECON and CSAMP), but without the focus on 520 autonomic features. 522 9. Related IETF Work 524 The following paragraphs discuss related IETF work and are provided 525 for reference. This section is not exhaustive, rather it provides an 526 overview of the various initiatives and how they relate to autonomic 527 distributed detection of SLA violations. 529 1. [LMAP]: The Large-Scale Measurement of Broadband Performance 530 Working Group aims at the standards for performance management. 531 Since their mechanisms also consist in deploying measurement 532 probes the autonomic solution could be relevant for LMAP 533 specially considering SLA violation screening. Besides that, a 534 solution to decrease the workload of human administrators in 535 service providers is probably highly desirable. 537 2. [IPFIX]: IP Flow Information EXport (IPFIX) aims at the process 538 of standardization of IP flows (i.e., netflows). IPFIX uses 539 measurement probes (i.e., metering exporters) to gather flow 540 data. In this context, the autonomic solution for the activation 541 of active measurement probes could be possibly extended to 542 address also passive measurement probes. Besides that, flow 543 information could be used in the decision making of probe 544 activation. 546 3. [ALTO]: The Application Layer Traffic Optimization Working Group 547 aims to provide topological information at a higher abstraction 548 layer, which can be based upon network policy, and with 549 application-relevant service functions located in it. Their work 550 could be leveraged for the definition of the topology regarding 551 the network devices which exchange measurement data. 553 10. Acknowledgements 555 We wish to acknowledge the helpful contributions, comments, and 556 suggestions that were received from Mohamed Boucadair, Hanlin Fang, 557 Bruno Klauser, Diego Lopez, Vincent Roca, and Eric Voit. 559 11. IANA Considerations 561 This memo includes no request to IANA. 563 12. Security Considerations 565 Security of the solution hinges on the security of the network 566 underlay, i.e. the Autonomic Control Plane. If the Autonomic Control 567 Plane were to be compromised, an attacker could undermine the 568 effectiveness of measurement coordination by reporting fraudulent 569 measurement results to peers. This would cause measurement probes to 570 be deployed in an ineffective manner that would increase the 571 likelihood that violations of service level objectives go undetected. 573 Likewise, security of the solution hinges on the security of the 574 deployment mechanism for autonomic functions, in this case, the 575 autonomic function that conducts the service level measurements. If 576 an attacker were able to hijack an autonomic function, it could try 577 to exhaust or exceed the resources that should be spent on autonomic 578 measurements in order to deplete network resources, including network 579 bandwidth due to higher-than-necessary volumes of synthetic test 580 traffic generated by measurement probes. Again, it could also lead 581 to reporting of misleading results, among other things resulting in 582 non-optimal selection of measurement targets and in turn an increase 583 in the likelihood that service level violations go undetected. 585 13. Informative References 587 [draft-anima-boot] 588 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 589 S., and K. Watsen, "draft-ietf-anima-bootstrapping- 590 keyinfra", draft-ietf-anima-bootstrapping-keyinfra-06 591 (work in progress), May 2017. 593 [draft-ietf-ippm-6man-pdm-option] 594 Elkins, N., Hamilton, R., and M. Ackermann, "draft-ietf- 595 ippm-6man-pdm-option", draft-ietf-ippm-6man-pdm-option-11 596 (work in progress), June 2017. 598 [I-D.anima-autonomic-control-plane] 599 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 600 Control Plane", draft-ietf-anima-autonomic-control- 601 plane-06 (work in progress), March 2017. 603 [P2PBNM-Nobre-2012] 604 Nobre, J., Granville, L., Clemm, A., and A. Gonzalez 605 Prieto, "Decentralized Detection of SLA Violations Using 606 P2P Technology, 8th International Conference Network and 607 Service Management (CNSM)", 2012, 608 . 611 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 612 Registry", BCP 108, RFC 4148, DOI 10.17487/RFC4148, August 613 2005, . 615 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 616 Zekauskas, "A One-way Active Measurement Protocol 617 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 618 . 620 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 621 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 622 RFC 5357, DOI 10.17487/RFC5357, October 2008, 623 . 625 [RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., 626 Grossglauser, M., and J. Rexford, "A Framework for Packet 627 Selection and Reporting", RFC 5474, DOI 10.17487/RFC5474, 628 March 2009, . 630 [RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, 631 S., and E. Yedavalli, "Cisco Service-Level Assurance 632 Protocol", RFC 6812, DOI 10.17487/RFC6812, January 2013, 633 . 635 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 636 "Specification of the IP Flow Information Export (IPFIX) 637 Protocol for the Exchange of Flow Information", STD 77, 638 RFC 7011, DOI 10.17487/RFC7011, September 2013, 639 . 641 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 642 Connectivity Provisioning Profile (CPP)", RFC 7297, 643 DOI 10.17487/RFC7297, July 2014, 644 . 646 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 647 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 648 Networking: Definitions and Design Goals", RFC 7575, 649 DOI 10.17487/RFC7575, June 2015, 650 . 652 Authors' Addresses 654 Jeferson Campos Nobre 655 University of Vale do Rio dos Sinos 656 Porto Alegre 657 Brazil 659 Email: jcnobre@unisinos.br 661 Lisandro Zambenedetti Granvile 662 Federal University of Rio Grande do Sul 663 Porto Alegre 664 Brazil 666 Email: granville@inf.ufrgs.br 667 Alexander Clemm 668 Huawei 669 Santa Clara, California 670 USA 672 Email: ludwig@clemm.org 674 Alberto Gonzalez Prieto 675 VMware 676 Palo Alto, California 677 USA 679 Email: agonzalezpri@vmware.com