idnits 2.17.1 draft-wwx-netmod-event-yang-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 22 instances of too long lines in the document, the longest one being 14 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 359 has weird spacing: '...nterval uin...' == Line 689 has weird spacing: '...nterval uin...' == Line 1209 has weird spacing: '...ld here may c...' -- The document date (December 10, 2019) is 1598 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC8342' is mentioned on line 152, but not defined == Missing Reference: 'RFC8340' is mentioned on line 579, but not defined == Missing Reference: 'RFC8040' is mentioned on line 1724, but not defined == Missing Reference: 'RFC5246' is mentioned on line 1728, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Missing Reference: 'GNCA' is mentioned on line 1783, but not defined == Unused Reference: 'RFC2981' is defined on line 1870, but no explicit reference was found in the text == Unused Reference: 'RFC6370' is defined on line 1896, but no explicit reference was found in the text == Unused Reference: 'RFC7952' is defined on line 1910, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) ** Downref: Normative reference to an Informational RFC: RFC 8328 Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD Working Group M. Wang 3 Internet-Draft Q. Wu 4 Intended status: Standards Track Huawei 5 Expires: June 12, 2020 I. Bryskin 6 Individual 7 X. Liu 8 Volta Networks 9 B. Claise 10 Cisco 11 December 10, 2019 13 A YANG Data model for ECA Policy Management 14 draft-wwx-netmod-event-yang-06 16 Abstract 18 RFC8328 defines a policy-based management framework that allows 19 definition of a data model to be used to represent high-level, 20 possibly network-wide policies. Policy discussed in RFC8328 are 21 classified into imperative policy and declarative policy, Event 22 Condition Action (ECA) policy is an typical example of imperative 23 policy. This document defines a YANG data model for the ECA policy 24 management. The ECA policy YANG provides the ability for the network 25 management function (within a network element) to control the 26 configuration and monitor state change and take simple and instant 27 action on the server when a trigger condition on the system state is 28 met. 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 June 12, 2020. 47 Copyright Notice 49 Copyright (c) 2019 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. Conventions used in this document . . . . . . . . . . . . . . 4 66 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Relationship to YANG Push . . . . . . . . . . . . . . . . . . 5 69 4. Overview of ECA YANG Data Model . . . . . . . . . . . . . . . 6 70 4.1. ECA Policy Variable and Value . . . . . . . . . . . . . . 6 71 4.2. ECA Event . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.3. ECA Condition . . . . . . . . . . . . . . . . . . . . . . 9 73 4.4. ECA Action . . . . . . . . . . . . . . . . . . . . . . . 11 74 5. ECA YANG Model (Tree Structure) . . . . . . . . . . . . . . . 13 75 6. ECA YANG Module . . . . . . . . . . . . . . . . . . . . . . . 18 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 37 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 78 9. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . 38 79 10. Objectives for existing and possible future extension . . . . 38 80 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39 81 12. Normative References . . . . . . . . . . . . . . . . . . . . 40 82 Appendix A. ECA Model Usage Example . . . . . . . . . . . . . . 42 83 Appendix B. Usage Example of Reusing Trigger-Grouping in smarter 84 filter . . . . . . . . . . . . . . . . . . . . . . . 44 85 Appendix C. Changes between Revisions . . . . . . . . . . . . . 47 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 88 1. Introduction 90 Network management consists of using one or multiple device-, 91 technology-, service specific policies to influence management 92 behavior within the system and make sure policies are enforced or 93 executed correctly. 95 [RFC8328] defines a policy-based management framework that allow 96 definition of a data model to be used to represent high-level, 97 possibly network-wide policies. Policies discussed in [RFC8328] are 98 classified into imperative policy and declarative policy. 99 Declarative policy specifies the goals to be achieved but not how to 100 achieve those goals while imperative policy specifies when Events are 101 triggered and what actions must be performed on the occurrence of an 102 event. Event Condition Action (ECA) policy is a typical example of 103 imperative policy. 105 Event-driven management of states of managed objects across a wide 106 range of devices can be used to monitor state changes of managed 107 objects or resource and automatic trigger of rules in response to 108 events so as to better service assurance for customers and to provide 109 rapid autonomic response that can exhibit self-management properties 110 including self-configuration, self-healing, self-optimization, and 111 self-protection. Following are some of the use-cases where such ECA 112 Policy can be used: 114 o To filter out of objects underneath a requested a subtree, the 115 subscriber may use YANG Push smart filter to request the network 116 server to monitor specific network management data objects and 117 send updates only when the value falls within a certain range. 119 o To filter out of objects underneath a requested a subtree, the 120 subscriber may use YANG Push smart filter to request the network 121 server to monitor specific network management data objects and 122 send updates only when the value exceeds a certain threshold for 123 the first time but not again until the threshold is cleared. 125 o To provide rapid autonomic response that can exhibit self- 126 management properties, the management system delegate event 127 response behaviors (e.g., auto-recover from network failure) to 128 the network device so that the network can react to network change 129 as quickly as the event is detected. The event response behaviors 130 delegation can be done using ECA policy,e.g., to preconfigure 131 protection/ restoration capability on the network device. 133 o To perform troubleshoot failures (i.e., fault verification and 134 localization) and provide root cause analysis, the management 135 system monitoring specific network management data objects may 136 request the network device to export state information of a set of 137 managed data objects when the value of monitored data object 138 exceeds a certain threshold. 140 o To set up an LSP and reserve resources within the network via 141 NETCONF protocol operation, Path Computation API RPC model can be 142 invoked to calculate a path meeting end-to-end network performance 143 criteria. 145 This document defines a ECA Policy management YANG data model. The 146 ECA Policy YANG provides the ability for the network management 147 function (within a network element) to control the configurations and 148 monitor state parameters and take simple and instant action on the 149 server when a trigger condition on the system state is met. 151 The data model in this document is designed to be compliant with the 152 Network Management Datastore Architecture (NMDA) [RFC8342]. 154 2. Conventions used in this document 156 2.1. Terminology 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. In this 161 document, these words will appear with that interpretation only when 162 in ALL CAPS. Lower case uses of these words are not to be 163 interpreted as carrying [RFC2119] significance. 165 The following terms are defined in [RFC7950] [RFC3460] and are not 166 redefined here: 168 o Server 170 o Client 172 o Policy variable 174 o Policy value 176 o Implicit policy variable 178 o explicit policy variable 180 This document uses the following terms: 182 Event: Something that happens which may be of interest or trigger 183 the invocation of the rule. A fault, an alarm, a change in 184 network state, network security threat, hardware malfunction, 185 buffer untilization crossing a threshold, network connection 186 setup, an external input to the system, for example. 188 Condition: Condition can be seen as a logical test that, if 189 satisfied or evaluated to be true, cause the action to be carried 190 out. 192 Action: Updates or invocations on local managed object attributes. 194 2.2. Tree Diagrams 196 Tree diagrams used in this document follow the notation defined in 197 [RFC8340]. 199 3. Relationship to YANG Push 201 YANG-push mechanism provides a subscription service for updates from 202 a datastore. And it supports two types of subscriptions which are 203 distinguished by how updates are triggered: periodic and on-change. 205 The on-change push allow receivers to receive updates whenever 206 changes to target managed objects occur. This document specifies a 207 mechanism that provides three trigger conditions: 209 o Existence: When a specific managed object appears,disappear or 210 object change, the trigger fires, e.g. reserved ports are 211 configured. 213 o Boolean: The user can set the type of boolean operator (e.g. 214 unequal, equal, less, less-or-equal, greater, greater-or-equal, 215 etc) and preconfigured threshold value (e.g. Pre-configured 216 threshold). If the value of a managed object meet Boolean 217 conditions, the trigger fires, e.g., when the boolean operator 218 type is 'less', the trigger will be fired if the value of managed 219 object is less than the pre-configured Boolean value. 221 o Threshold: The user can set the rising threshold,the falling 222 threshold, the delta rising threshold, the delta falling 223 threshold. A threshold test regularly compares the value of the 224 monitored object with the threshold values, e.g., an event is 225 triggered if the value of the monitored object is greater than or 226 equal to the rising threshold or an event is triggered if the 227 difference between the current measurement value and the previous 228 measurement value is smaller than or equal to the delta falling 229 threshold. 231 In these three trigger conditions, existence with type set to object 232 change is similar to on Push change. 234 In addtion, the model defined in this document provides a method for 235 closed loop network management automation which allows automatic 236 trigger of rules in response to events so as to better service 237 assurance for customers and to provide rapid autonomic response that 238 can exhibit self-management properties including self-configuration, 239 self-healing, self-optimization, and self-protection. The details of 240 the usage example is described in Appendix A. 242 4. Overview of ECA YANG Data Model 244 A ECA policy rule is read as: when event occurs in a situation where 245 condition is true, then action is executed. Therefore ECA comprises 246 three key elements: event, associated conditions, and associated 247 actions. These three elements should be pushed down and configured 248 on the server by the client. If the action is rejected by the server 249 duing ECA policy execution, the action should be rolled back and 250 cleaned up. 252 4.1. ECA Policy Variable and Value 254 ECA policy variable (PV) generically represents information that 255 changes (or "varies"), and that is set or evaluated by software. ECA 256 policy Value is used for modeling values and constants used in policy 257 conditions and actions. In policy, conditions and actions can 258 abstract information as "policy variables" to be evaluated in logical 259 expressions, or set by actions, e.g., the Policy Condition has the 260 semantics "variable matches value" while Policy Action has the 261 semantics "set variable to value". 263 In ECA, two type of policy variables are defined, implicit variable 264 and explicit variable. Explicit variables are bound to exact data 265 object instance in the model while implicit variables are defined and 266 evaluated outside of a model. Each ECA policy variable has the 267 following attributes: 269 o Name with Globally unique or ECA unique scope ; 271 o Type either implicit or explicit; The implicit or explicit type 272 can be further broken down into global or local. 274 o Value data stored in the policy variable structured according to 275 the PV type. This structure can be used to keep intermediate 276 results/meta data during the execution of an ECA policy. 278 The following operations are allowed with/on a PV: 280 o initialize (with a constant/enum/identity); 281 o set (with contents of another same type PV); 283 o read (retrieve datastore contents pointed by the specified same 284 type XPath/sub-tree); 286 o write (modify configuration data in the datastore with the PV's 287 content/value); 289 o insert (PV's content into a same type list); 291 o iterate (copy into PV one by one same type list elements) 293 o function calls in a form of F(arg1,arg2,...), where F is an 294 identity of a function from extendable function library, 295 arg1,arg2,etc are PVs respectively, the function's input 296 parameters, with the result returned in result policy variable. 298 PVs could be used as input/output of an ECA invoked RPC and policy 299 argument in the func calls. PVs could also be a source of 300 information sent to the client in notification messages. 302 PVs could be used in condition expressions 304 The model structure for the Policy Variable is shown below: 306 +--rw policy-variables 307 | +--rw policy-variable* [name] 308 | +--rw name string 309 | +--rw type? identityref 310 | +--rw explict-variable? yang:xpath1.0 311 | +--rw implict-variable? identityref 312 | +--rw policy-value? union 314 4.2. ECA Event 316 The ECA event are used to keep track of state of changes associated 317 with one of multiple operational state data objects in the network 318 device. Typical examples of ECA event include a fault, an alarm, a 319 change in network state, network security threat, hardware 320 malfunction, buffer utilization crossing a threshold, network 321 connection setup, and an external input to the system. 323 Each ECA Event has the following attributes: 325 o name, the name of ECA event; 327 o type, either one time or peridic scheduling; 328 o group-id, which can be used to group a set of events that can be 329 executed together,e.g., deliver a service or provide service 330 assurance; 332 o scheduled-time,configuration scheduling - scheduling one time or 333 periodic. 335 Nested-event are supported by allowing one event's trigger to 336 reference other event's definitions using the call-event 337 configuration. Called events apply their triggers and actions before 338 returning to the calling event's trigger and resuming evaluation. If 339 the called event is triggered, then it returns an effective boolean 340 true value to the calling event. For the calling event, this is 341 equivalent to a condition statement evaluating to a true value and 342 evaluation of the event continues. 344 All events specified in the ECA policy model are continuously 345 monitored by the server. 347 The model structure for the ECA Event is shown below: 349 +--rw event* [name type] 350 +--rw name string 351 +--rw type identityref 352 +--rw event-description? string 353 +--rw group-id? group-type 354 +--rw explict-variable* leafref 355 +--rw clear? boolean 356 +--rw scheduled-time 357 | +--rw type? identityref 358 | +--rw periodic 359 | | +--rw interval uint32 360 | | +--rw start? yang:date-and-time 361 | | +--rw end? yang:date-and-time 362 | +--rw calendar-time 363 | +--rw month* string 364 | +--rw day-of-month* uint8 365 | +--rw day-of-week* uint8 366 | +--rw hour* uint8 367 | +--rw minute* uint8 368 | +--rw second* uint8 369 | +--rw start? yang:date-and-time 370 | +--rw end? yang:date-and-time 371 +--ro last-event? -> /eca/event/name 373 4.3. ECA Condition 375 Condition can be seen as a logical test that, if satisfied or 376 evaluated to be true, cause the action to be carried out. In this 377 model, condition can be specified as logical combinations of the 378 following three condition expressions: 380 o Existence: An existence condition monitors and manages the 381 absence, presence, and change of a data object, for example, 382 interface status. When a monitored object is specified, the 383 system reads the value of the monitored object regularly. 385 * If the existence test type is Absent, the system triggers a 386 network event and takes the specified action when the monitored 387 object disappears. 389 * If the existence test type is Present, the system triggers a 390 network event and takes the specified action when the monitored 391 object appears. 393 * If the existence test type is Changed, the system triggers a 394 network event and takes the specified action when the value of 395 the monitored object changes. 397 o Boolean: A Boolean test compares the value of the monitored object 398 with the reference value and takes action according to the 399 comparison result. The comparision hierarchy is logical 400 hierarchies specified in a form of: 402 or 403 405 relation is one of the comparison operations from the set: 406 ==, !=, >, <, >=, <= 408 o The operation types include unequal, equal, less, lessorequal, 409 greater, and greaterorequal. For example, if the comparison type 410 is equal, an event is triggered when the value of the monitored 411 object equals the reference value. The event will not be 412 triggered again until the value becomes unequal and comes back to 413 equal. 415 o Threshold: A threshold trigger condition regularly compares the 416 value of the monitored object with the threshold values , with one 417 of the following mechanisms: 419 * A rising event is triggered if the value of the monitored 420 object is greater than or equal to the rising threshold. 422 * A falling event is triggered if the value of the monitored 423 object is smaller than or equal to the falling threshold. 425 * A rising event is triggered if the difference between the 426 current measurement value and the previous measurement value is 427 greater than or equal to the delta rising threshold. 429 * A falling network event is triggered if the difference between 430 the current measurement value and the previous measurement 431 value is smaller than or equal to the delta falling threshold. 433 * A falling event is triggered if the values of the monitored 434 object, the rising threshold, and the falling threshold are the 435 same. 437 * A falling event is triggered if the delta rising threshold, the 438 delta falling threshold, and the difference between the current 439 sampled value and the previous sampled value is the same. 441 If the value of the monitored object crosses a threshold multiple 442 times in succession, the managed device triggers an event only for 443 the first crossing. 445 In addition, logical operation type can be used to describe complex 446 logical operations between different condition lists under the same 447 event, for example, (condition A & condition B) or condition C. 449 The model structure for the condition is shown below: 451 +--rw condition* [name] 452 | +--rw name string 453 | +--rw condition-description? string 454 | +--rw logical-operation-type? identityref 455 | +--rw call-event? -> ../../name 456 | +--rw (test)? 457 | +--:(existences) 458 | | +--rw existences 459 | | +--rw type? enumeration 460 | | +--rw policy-variable? leafref 461 | +--:(boolean) 462 | | +--rw boolean 463 | | +--rw operator? operator 464 | | +--rw policy-value 465 | | | +--rw policy-argument 466 | | | +--rw (argument)? 467 | | | +--:(explict-variable) 468 | | | | +--rw explict-variable? leafref 469 | | | +--:(implict-variable) 470 | | | | +--rw implict-variable? leafref 471 | | | +--:(value) 472 | | | +--rw policy-value? leafref 473 | | +--rw policy-variable 474 | | +--rw policy-argument 475 | | +--rw (argument)? 476 | | +--:(explict-variable) 477 | | | +--rw explict-variable? leafref 478 | | +--:(implict-variable) 479 | | +--rw implict-variable? leafref 480 | +--:(threshold) 481 | +--rw threshold 482 | +--rw rising-value? leafref 483 | +--rw rising-policy-variable* leafref 484 | +--rw falling-value? leafref 485 | +--rw falling-policy-variable* leafref 486 | +--rw delta-rising-value? leafref 487 | +--rw delta-rising-policy-variable* leafref 488 | +--rw delta-falling-value? leafref 489 | +--rw delta-falling-policy-variable* leafref 490 | +--rw startup? enumeration 492 4.4. ECA Action 494 The action list consists of updates or invocations on local managed 495 object attributes and a set of actions are defined as follows, which 496 will be performed when the corresponding event is triggered: 498 o sending one time log notification 499 o (-re)configuration - modifying a configuration data in the 500 conventional configuration datastore. 502 o adding/removing event notify subscription (essentially, the same 503 action as performed when a client explicitly adds/removes a 504 subscription) 506 o executing an RPC defined by a YANG module supported by the server 507 (the same action as performed when a client interactively calls 508 the RPC); 510 o performing operations and function calls on PVs (such as assign, 511 read, insert, iterate, etc); 513 Multiple ECA Actions could be triggered by a single ECA event. 515 Any given ECA Condition or Action may appear in more than one ECAs. 517 The model structure for the actions is shown below: 519 +--rw actions 520 +--rw action* [name] 521 +--rw name string 522 +--rw (action-type)? 523 +--:(set) 524 | +--rw set 525 | +--rw policy-variable? leafref 526 | +--rw value? 527 +--:(logging) 528 | +--rw logging 529 | +--rw type? logging-type 530 | +--rw policy-variable? leafref 531 +--:(function-call) 532 | +--rw function-call 533 | +--rw function-type? identityref 534 | +--rw policy-argument* [name] 535 | | +--rw name string 536 | | +--rw (argument)? 537 | | +--:(explict-variable) 538 | | | +--rw explict-variable? leafref 539 | | +--:(implict-variable) 540 | | | +--rw implict-variable? leafref 541 | | +--:(value) 542 | | +--rw policy-value? leafref 543 | +--rw result 544 | +--rw (argument)? 545 | +--:(explict-variable) 546 | | +--rw explict-variable? leafref 547 | +--:(implict-variable) 548 | | +--rw implict-variable? leafref 549 | +--:(value) 550 | +--rw policy-value? leafref 551 +--:(rpc-call) 552 +--rw rpc-call 553 +--rw name? string 554 +--rw input 555 | +--rw policy-argument* [name] 556 | +--rw name 557 | | string 558 | +--rw (argument)? 559 | +--:(explict-variable) 560 | | +--rw explict-variable? leafref 561 | +--:(implict-variable) 562 | | +--rw implict-variable? leafref 563 | +--:(value) 564 | +--rw policy-value? leafref 565 +--rw output 566 +--rw policy-argument* [name] 567 +--rw name 568 | string 569 +--rw (argument)? 570 +--:(explict-variable) 571 | +--rw explict-variable? leafref 572 +--:(implict-variable) 573 | +--rw implict-variable? leafref 574 +--:(value) 575 +--rw policy-value? leafref 577 5. ECA YANG Model (Tree Structure) 579 The following tree diagrams [RFC8340] provide an overview of the data 580 model for the "ietf-eca" module. 582 grouping start-end-grouping 583 +-- start? yang:date-and-time 584 +-- end? yang:date-and-time 585 grouping existences-trigger 586 +-- existences 587 +-- type? enumeration 588 +-- policy-variable? 589 -> /policy-variables/policy-variable/name 590 grouping boolean-trigger 591 +-- boolean 592 +-- operator? operator 593 +-- policy-value 594 | +-- policy-argument 595 | +-- (argument)? 596 | +--:(explict-variable) 597 | | +-- explict-variable? leafref 598 | +--:(implict-variable) 599 | | +-- implict-variable? leafref 600 | +--:(value) 601 | +-- policy-value? leafref 602 +-- policy-variable 603 +-- policy-argument 604 +-- (argument)? 605 +--:(explict-variable) 606 | +-- explict-variable? leafref 607 +--:(implict-variable) 608 +-- implict-variable? leafref 609 grouping threshold-trigger 610 +-- threshold 611 +-- rising-value? 612 | -> /policy-variables/policy-variable/policy-value 613 +-- rising-policy-variable* 614 | -> /policy-variables/policy-variable/name 615 +-- falling-value? 616 | -> /policy-variables/policy-variable/policy-value 617 +-- falling-policy-variable* 618 | -> /policy-variables/policy-variable/name 619 +-- delta-rising-value? 620 | -> /policy-variables/policy-variable/policy-value 621 +-- delta-rising-policy-variable* 622 | -> /policy-variables/policy-variable/name 623 +-- delta-falling-value? 624 | -> /policy-variables/policy-variable/policy-value 625 +-- delta-falling-policy-variable* 626 | -> /policy-variables/policy-variable/name 627 +-- startup? enumeration 628 grouping trigger-grouping 629 +-- (test)? 630 +--:(existences) 631 | +-- existences 632 | +-- type? enumeration 633 | +-- policy-variable? 634 | -> /policy-variables/policy-variable/name 635 +--:(boolean) 636 | +-- boolean 637 | +-- operator? operator 638 | +-- policy-value 639 | | +-- policy-argument 640 | | +-- (argument)? 641 | | +--:(explict-variable) 642 | | | +-- explict-variable? leafref 643 | | +--:(implict-variable) 644 | | | +-- implict-variable? leafref 645 | | +--:(value) 646 | | +-- policy-value? leafref 647 | +-- policy-variable 648 | +-- policy-argument 649 | +-- (argument)? 650 | +--:(explict-variable) 651 | | +-- explict-variable? leafref 652 | +--:(implict-variable) 653 | +-- implict-variable? leafref 654 +--:(threshold) 655 +-- threshold 656 +-- rising-value? leafref 657 +-- rising-policy-variable* 658 | -> /policy-variables/policy-variable/name 659 +-- falling-value? leafref 660 +-- falling-policy-variable* 661 | -> /policy-variables/policy-variable/name 662 +-- delta-rising-value? leafref 663 +-- delta-rising-policy-variable* 664 | -> /policy-variables/policy-variable/name 665 +-- delta-falling-value? leafref 666 +-- delta-falling-policy-variable* 667 | -> /policy-variables/policy-variable/name 668 +-- startup? enumeration 670 module: ietf-eca 671 +--rw policy-variables 672 | +--rw policy-variable* [name] 673 | +--rw name string 674 | +--rw type? identityref 675 | +--rw explict-variable? yang:xpath1.0 676 | +--rw implict-variable? identityref 677 | +--rw policy-value? union 678 +--rw eca 679 +--rw event* [name type] 680 +--rw name string 681 +--rw type identityref 682 +--rw event-description? string 683 +--rw group-id? group-type 684 +--rw explict-variable* leafref 685 +--rw clear? boolean 686 +--rw scheduled-time 687 | +--rw type? identityref 688 | +--rw periodic 689 | | +--rw interval uint32 690 | | +--rw start? yang:date-and-time 691 | | +--rw end? yang:date-and-time 692 | +--rw calendar-time 693 | +--rw month* string 694 | +--rw day-of-month* uint8 695 | +--rw day-of-week* uint8 696 | +--rw hour* uint8 697 | +--rw minute* uint8 698 | +--rw second* uint8 699 | +--rw start? yang:date-and-time 700 | +--rw end? yang:date-and-time 701 +--ro last-event? -> /eca/event/name 702 +--ro last-condition? -> /eca/event/condition/name 703 +--ro last-action? 704 | -> /eca/event/actions/action/name 705 +--rw condition* [name] 706 | +--rw name string 707 | +--rw condition-description? string 708 | +--rw logical-operation-type? identityref 709 | +--rw call-event? -> ../../name 710 | +--rw (test)? 711 | +--:(existences) 712 | | +--rw existences 713 | | +--rw type? enumeration 714 | | +--rw policy-variable? leafref 715 | +--:(boolean) 716 | | +--rw boolean 717 | | +--rw operator? operator 718 | | +--rw policy-value 719 | | | +--rw policy-argument 720 | | | +--rw (argument)? 721 | | | +--:(explict-variable) 722 | | | | +--rw explict-variable? leafref 723 | | | +--:(implict-variable) 724 | | | | +--rw implict-variable? leafref 725 | | | +--:(value) 726 | | | +--rw policy-value? leafref 727 | | +--rw policy-variable 728 | | +--rw policy-argument 729 | | +--rw (argument)? 730 | | +--:(explict-variable) 731 | | | +--rw explict-variable? leafref 732 | | +--:(implict-variable) 733 | | +--rw implict-variable? leafref 734 | +--:(threshold) 735 | +--rw threshhold 736 | +--rw rising-value? leafref 737 | +--rw rising-policy-variable* leafref 738 | +--rw falling-value? leafref 739 | +--rw falling-policy-variable* leafref 740 | +--rw delta-rising-value? leafref 741 | +--rw delta-rising-policy-variable* leafref 742 | +--rw delta-falling-value? leafref 743 | +--rw delta-falling-policy-variable* leafref 744 | +--rw startup? 745 | enumeration 746 +--rw actions 747 +--rw action* [name] 748 +--rw name string 749 +--rw (action-type)? 750 +--:(set) 751 | +--rw set 752 | +--rw policy-variable? leafref 753 | +--rw value? 754 +--:(logging) 755 | +--rw logging 756 | +--rw type? logging-type 757 | +--rw policy-variable? leafref 758 +--:(function-call) 759 | +--rw function-call 760 | +--rw function-type? identityref 761 | +--rw policy-argument* [name] 762 | | +--rw name string 763 | | +--rw (argument)? 764 | | +--:(explict-variable) 765 | | | +--rw explict-variable? leafref 766 | | +--:(implict-variable) 767 | | | +--rw implict-variable? leafref 768 | | +--:(value) 769 | | +--rw policy-value? leafref 770 | +--rw result 771 | +--rw (argument)? 772 | +--:(explict-variable) 773 | | +--rw explict-variable? leafref 774 | +--:(implict-variable) 775 | | +--rw implict-variable? leafref 776 | +--:(value) 777 | +--rw policy-value? leafref 778 +--:(rpc-call) 779 +--rw rpc-call 780 +--rw name? string 781 +--rw input 782 | +--rw policy-argument* [name] 783 | +--rw name 784 | | string 785 | +--rw (argument)? 786 | +--:(explict-variable) 787 | | +--rw explict-variable? leafref 788 | +--:(implict-variable) 789 | | +--rw implict-variable? leafref 790 | +--:(value) 791 | +--rw policy-value? leafref 792 +--rw output 793 +--rw policy-argument* [name] 794 +--rw name 795 | string 796 +--rw (argument)? 797 +--:(explict-variable) 798 | +--rw explict-variable? leafref 799 +--:(implict-variable) 800 | +--rw implict-variable? leafref 801 +--:(value) 802 +--rw policy-value? leafref 804 6. ECA YANG Module 806 file "ietf-eca@2019-10-28.yang" 808 module ietf-eca { 809 yang-version 1.1; 810 namespace "urn:ietf:params:xml:ns:yang:ietf-eca"; 811 prefix eca; 813 import ietf-yang-types { 814 prefix yang; 815 } 817 organization 818 "IETF NETMOD Working Group"; 819 contact 820 "Editor: Zitao Wang 821 822 Editor: Qin Wu 823 824 Editor: Igor Bryskin 825 826 Editor: Xufeng Liu 827 828 Editor: Benoit Claise 829 "; 830 description 831 " This module contains YANG specifications for ECA Policy management. 832 Copyright (c) 2019 IETF Trust and the persons identified as 833 authors of the code. All rights reserved. 835 Redistribution and use in source and binary forms, with or 836 without modification, is permitted pursuant to, and subject to 837 the license terms contained in, the Simplified BSD License set 838 forth in Section 4.c of the IETF Trust's Legal Provisions 839 Relating to IETF Documents 840 (https://trustee.ietf.org/license-info). 841 This version of this YANG module is part of RFC xxxx; see the 842 RFC itself for full legal notices."; 844 revision 2019-10-28 { 845 description 846 "Initial revision."; 847 reference 848 "RFC xxxx"; 849 } 850 identity variable-type { 851 description 852 "base variable type"; 853 } 854 identity global-explict { 855 base variable-type; 856 description 857 "Identity for global explict variable"; 858 } 859 identity global-implict { 860 base variable-type; 861 description 862 "Identity for global explict variablae"; 863 } 864 identity local-explict { 865 base variable-type; 866 description 867 "Identity for local explict variable"; 868 } 869 identity local-implict { 870 base variable-type; 871 description 872 "Identity for local implict variable"; 873 } 874 identity function-type { 875 description 876 "Possible values are: 877 plus, minus, mult, divide, remain."; 878 } 880 identity logical-operation-type { 881 description 882 "Possible values are: 884 not, or, and."; 885 } 887 identity policy-variable-type { 888 description 889 "Possible values are: 890 boolean, int32, int64, uint32, uint64, string, etc."; 891 } 893 identity event-type { 894 description 895 "Base identity for event type"; 896 } 898 identity frequency { 899 description 900 "Base identity for frequency"; 901 } 903 identity periodic { 904 base frequency; 905 description 906 "Identity for periodic trigger"; 907 } 909 identity scheduling { 910 base frequency; 911 description 912 "Identity for scheduling trigger"; 913 } 915 identity logging { 916 description 917 "Base identity for logging action"; 918 } 920 identity logging-notification { 921 base logging; 922 description 923 "Logging for event notification"; 924 } 926 identity logging-set { 927 base logging; 928 description 929 "Logging for reset values"; 930 } 931 typedef logging-type { 932 type identityref { 933 base logging; 934 } 935 description 936 "Logging types"; 937 } 939 typedef group-type { 940 type string; 941 description 942 "Group type"; 943 } 945 grouping start-end-grouping { 946 description 947 "A grouping that provides start and end times for 948 Event objects."; 949 leaf start { 950 type yang:date-and-time; 951 description 952 "The date and time when the Event object 953 starts to create triggers."; 954 } 955 leaf end { 956 type yang:date-and-time; 957 description 958 "The date and time when the Event object 959 stops to create triggers. 960 It is generally a good idea to always configure 961 an end time and to refresh the end time as needed 962 to ensure that agents that lose connectivity to 963 their Controller do not continue executing Schedules 964 forever."; 965 } 966 } 968 typedef operator { 969 type enumeration { 970 enum unequal { 971 description 972 "Indicates that the comparision type is unequal to."; 973 } 974 enum equal { 975 description 976 "Indicates that the comparision type is equal to."; 977 } 978 enum less { 979 description 980 "Indicates that the comparision type is less than."; 981 } 982 enum less-or-equal { 983 description 984 "Indicates that the comparision type is less than 985 or equal to."; 986 } 987 enum greater { 988 description 989 "Indicates that the comparision type is greater than."; 990 } 991 enum greater-or-equal { 992 description 993 "Indicates that the comparision type is greater than 994 or equal to."; 995 } 996 } 997 description 998 "definition of the operator"; 999 } 1001 grouping existences-trigger { 1002 description 1003 "A grouping that provides existence trigger"; 1004 container existences { 1005 leaf type { 1006 type enumeration { 1007 enum match { 1008 description "march"; 1009 } 1010 enum mismatch { 1011 description "mismatch"; 1012 } 1013 } 1014 description 1015 "existence type, variable match the value or variable mismatch the value"; 1016 } 1017 leaf policy-variable { 1018 type leafref { 1019 path "/policy-variables/policy-variable/name"; 1020 } 1021 description 1022 "Policy variable"; 1023 } 1024 description 1025 "Container for existence"; 1026 } 1028 } 1030 grouping boolean-trigger { 1031 description 1032 "A grouping that provides boolean trigger"; 1033 container boolean { 1034 leaf operator { 1035 type operator; 1036 description 1037 "Comparison type."; 1038 } 1039 container policy-value { 1040 container policy-argument { 1041 choice argument { 1042 case explict-variable { 1043 leaf explict-variable { 1044 type leafref { 1045 path "/policy-variables/policy-variable/explict-variable"; 1046 } 1047 description 1048 "explict variable"; 1049 } 1050 } 1051 case implict-variable { 1052 leaf implict-variable { 1053 type leafref { 1054 path "/policy-variables/policy-variable/implict-variable"; 1055 } 1056 description 1057 "implict variable"; 1058 } 1059 } 1060 case value { 1061 leaf policy-value { 1062 type leafref { 1063 path "/policy-variables/policy-variable/policy-value"; 1064 } 1065 description 1066 "policy value"; 1067 } 1068 } 1069 description 1070 "Choice one argument format"; 1071 } 1072 description 1073 "Cotainer for policy argument"; 1074 } 1075 description 1076 "Container for policy value"; 1077 } 1078 container policy-variable { 1079 container policy-argument { 1080 choice argument { 1081 case explict-variable { 1082 leaf explict-variable { 1083 type leafref { 1084 path "/policy-variables/policy-variable/explict-variable"; 1085 } 1086 description 1087 "explict variable"; 1088 } 1089 } 1090 case implict-variable { 1091 leaf implict-variable { 1092 type leafref { 1093 path "/policy-variables/policy-variable/implict-variable"; 1094 } 1095 description 1096 "implict variable"; 1097 } 1098 } 1099 description 1100 "Choice one argument format"; 1101 } 1102 description 1103 "Cotainer for policy argument"; 1104 } 1105 description 1106 "Container for policy variable"; 1107 } 1108 description 1109 "Container for boolean test."; 1110 } 1111 } 1113 grouping threshold-trigger { 1114 description 1115 "A grouping that provides threshold trigger"; 1116 container threshold { 1117 leaf rising-value { 1118 type leafref { 1119 path "/policy-variables/policy-variable/policy-value"; 1120 } 1121 description 1122 "Sets the rising threshold to the specified value, 1123 when the current sampled value is greater than or equal to 1124 this threshold, and the value at the last sampling interval 1125 was less than this threshold, the event is triggered. "; 1126 } 1127 leaf-list rising-policy-variable { 1128 type leafref { 1129 path "/policy-variables/policy-variable/name"; 1130 } 1131 description 1132 "List for target variable."; 1133 } 1134 leaf falling-value { 1135 type leafref { 1136 path "/policy-variables/policy-variable/policy-value"; 1137 } 1138 description 1139 "Sets the falling threshold to the specified value."; 1140 } 1141 leaf-list falling-policy-variable { 1142 type leafref { 1143 path "/policy-variables/policy-variable/name"; 1144 } 1145 description 1146 "List for target variable."; 1147 } 1148 leaf delta-rising-value { 1149 type leafref { 1150 path "/policy-variables/policy-variable/policy-value"; 1151 } 1152 description 1153 "Sets the delta rising threshold to the specified value."; 1154 } 1155 leaf-list delta-rising-policy-variable { 1156 type leafref { 1157 path "/policy-variables/policy-variable/name"; 1158 } 1159 description 1160 "List for target variable."; 1161 } 1162 leaf delta-falling-value { 1163 type leafref { 1164 path "/policy-variables/policy-variable/policy-value"; 1165 } 1166 description 1167 "Sets the delta falling threshold to the specified value."; 1168 } 1169 leaf-list delta-falling-policy-variable { 1170 type leafref { 1171 path "/policy-variables/policy-variable/name"; 1173 } 1174 description 1175 "List for target variable."; 1176 } 1177 leaf startup { 1178 type enumeration { 1179 enum rising { 1180 description 1181 "If the first sample after this 1182 managed object becomes active is greater than or equal 1183 to 'rising-value' and the 'startup' is equal to 1184 'rising' then one threshold rising event is 1185 triggered for that managed object."; 1186 } 1187 enum falling { 1188 description 1189 "If the first sample after this managed object becomes 1190 active is less than or equal to 'falling-value' and 1191 the 'startup' is equal to 'falling' then one 1192 threshold falling event is triggered for that managed 1193 object."; 1194 } 1195 enum rising-or-falling { 1196 description 1197 "That event may be triggered when the 1198 'startup' is equal to 'rising-or-falling'. 1199 'rising-or-falling' indicate the state value of the 1200 managed object may less than or greater than the 1201 specified thrshold value."; 1202 } 1203 } 1204 description 1205 "Startup setting."; 1206 } 1207 description 1208 "Container for the threshold trigger condition. 1209 Note that the threshold here may change over time 1210 or the state value changes in either ascend order 1211 or descend order."; 1212 } 1213 } 1215 grouping trigger-grouping { 1216 description 1217 "A grouping that provides event trigger."; 1218 choice test { 1219 description 1220 "Choice test"; 1222 case existences { 1223 uses existences-trigger; 1224 } 1225 case boolean { 1226 uses boolean-trigger; 1227 } 1228 case threshold { 1229 uses threshold-trigger; 1230 } 1231 } 1232 } 1234 container policy-variables { 1235 list policy-variable { 1236 key "name"; 1237 leaf name { 1238 type string; 1239 description 1240 "Policy variable name"; 1241 } 1242 leaf type { 1243 type identityref { 1244 base variable-type; 1245 } 1246 description 1247 "Policy variable type"; 1248 } 1249 leaf explict-variable { 1250 type yang:xpath1.0; 1251 description 1252 "Explict policy variable"; 1253 } 1254 leaf implict-variable { 1255 type identityref { 1256 base policy-variable-type; 1257 } 1258 description 1259 "A common policy variable type, defined as an 1260 identity."; 1261 } 1262 leaf policy-value { 1263 type union { 1264 type yang:xpath1.0; 1265 type yang:object-identifier; 1266 type yang:uuid; 1267 type string; 1268 type boolean; 1269 type int32; 1270 type int64; 1271 type uint32; 1272 type uint64; 1273 } 1274 description 1275 "Policy value"; 1276 } 1277 description 1278 "List for policy variable"; 1279 } 1280 description 1281 "Policy variables"; 1282 } 1283 container eca { 1284 list event { 1285 key "name type"; 1286 leaf name { 1287 type string; 1288 description 1289 "Event name"; 1290 } 1291 leaf type { 1292 type identityref { 1293 base event-type; 1294 } 1295 description 1296 "Type of event"; 1297 } 1298 leaf event-description { 1299 type string; 1300 description 1301 "Event description"; 1302 } 1303 leaf group-id { 1304 type group-type; 1305 description 1306 "Group Identifier"; 1307 } 1308 leaf-list explict-variable { 1309 type leafref { 1310 path "/policy-variables/policy-variable/explict-variable"; 1311 } 1312 description 1313 "Explict variable"; 1314 } 1315 leaf clear { 1316 type boolean; 1317 default "false"; 1318 description 1319 "A flag indicate whether the event be closed"; 1320 } 1321 container scheduled-time { 1322 leaf type { 1323 type identityref { 1324 base frequency; 1325 } 1326 description 1327 "Type of scheduled-time"; 1328 } 1329 container periodic { 1330 when "derived-from-or-self(../type, 'periodic')"; 1331 description 1332 "A periodic timing object triggers periodically 1333 according to a regular interval."; 1334 leaf interval { 1335 type uint32 { 1336 range "1..max"; 1337 } 1338 units "seconds"; 1339 mandatory true; 1340 description 1341 "The number of seconds between two triggers 1342 generated by this periodic timing object."; 1343 } 1344 uses start-end-grouping; 1345 } 1346 container calendar-time { 1347 when "derived-from-or-self(../type, 'scheduling')"; 1348 description 1349 "A scheduling timing object triggers."; 1350 leaf-list month { 1351 type string; 1352 description 1353 "A set of months at which this scheduling timing 1354 will trigger."; 1355 } 1356 leaf-list day-of-month { 1357 type uint8 { 1358 range "0..59"; 1359 } 1360 description 1361 "A set of days of the month at which this 1362 scheduling timing will trigger."; 1363 } 1364 leaf-list day-of-week { 1365 type uint8 { 1366 range "0..59"; 1367 } 1368 description 1369 "A set of weekdays at which this scheduling timing 1370 will trigger."; 1371 } 1372 leaf-list hour { 1373 type uint8 { 1374 range "0..59"; 1375 } 1376 description 1377 "A set of hours at which the scheduling timing will 1378 trigger."; 1379 } 1380 leaf-list minute { 1381 type uint8 { 1382 range "0..59"; 1383 } 1384 description 1385 "A set of minutes at which this scheduling timing 1386 will trigger."; 1387 } 1388 leaf-list second { 1389 type uint8 { 1390 range "0..59"; 1391 } 1392 description 1393 "A set of seconds at which this calendar timing 1394 will trigger."; 1395 } 1396 uses start-end-grouping; 1397 } 1398 description 1399 "Container for frequency"; 1400 } 1401 leaf last-event { 1402 type leafref { 1403 path "/eca/event/name"; 1404 } 1405 config false; 1406 description 1407 "The reference to a event last executed 1408 or being executed."; 1409 } 1410 leaf last-condition { 1411 type leafref { 1412 path "/eca/event/condition/name"; 1413 } 1414 config false; 1415 description 1416 "The reference to a condition last executed or being 1417 executed."; 1418 } 1419 leaf last-action { 1420 type leafref { 1421 path "/eca/event/actions/action/name"; 1422 } 1423 config false; 1424 description 1425 "The reference to aa action last executed or being 1426 executed."; 1427 } 1428 list condition { 1429 key "name"; 1430 leaf name { 1431 type string; 1432 description 1433 "Trigger name"; 1434 } 1435 leaf condition-description { 1436 type string; 1437 description 1438 "Trigger description"; 1439 } 1440 leaf logical-operation-type { 1441 type identityref { 1442 base logical-operation-type; 1443 } 1444 description 1445 "The logical operation type."; 1446 } 1447 leaf call-event { 1448 type leafref { 1449 path "../../name"; 1450 } 1451 description 1452 "This leaf call sub-event."; 1453 } 1454 uses trigger-grouping; 1455 description 1456 "List for trigger"; 1457 } 1458 container actions { 1459 list action { 1460 key "name"; 1461 leaf name { 1462 type string; 1463 description 1464 "Action Name"; 1465 } 1466 choice action-type { 1467 description 1468 "Choice one action type"; 1469 case set { 1470 container set { 1471 leaf policy-variable { 1472 type leafref { 1473 path "/policy-variables/policy-variable/name"; 1474 } 1475 description 1476 "The target objects"; 1477 } 1478 anydata value { 1479 description 1480 "Inline set content."; 1481 } 1482 description 1483 "Set a value to the target"; 1484 } 1485 } 1486 case logging { 1487 container logging { 1488 leaf type { 1489 type logging-type; 1490 description 1491 "Specifies the log action"; 1492 } 1493 leaf policy-variable { 1494 type leafref { 1495 path "/policy-variables/policy-variable/name"; 1496 } 1497 description 1498 "The target objects"; 1499 } 1500 description 1501 "Specifies the log action"; 1502 } 1503 } 1504 case function-call { 1505 container function-call { 1506 description 1507 "The operation is to call a function, which is of one of 1508 a few basic predefined types, such as plus, minus, 1509 multiply, devide, or remainder."; 1511 leaf function-type { 1512 type identityref { 1513 base function-type; 1514 } 1515 description 1516 "One of the predefined basic function types, such as 1517 plus, minus, multiply, devide, or remainder."; 1518 } 1519 list policy-argument { 1520 key "name"; 1521 leaf name { 1522 type string; 1523 description 1524 "Policy argument name"; 1525 } 1526 choice argument { 1527 case explict-variable { 1528 leaf explict-variable { 1529 type leafref { 1530 path "/policy-variables/policy-variable/explict-variable"; 1531 } 1532 description 1533 "explict variable"; 1534 } 1535 } 1536 case implict-variable { 1537 leaf implict-variable { 1538 type leafref { 1539 path "/policy-variables/policy-variable/implict-variable"; 1540 } 1541 description 1542 "implict variable"; 1543 } 1544 } 1545 case value { 1546 leaf policy-value { 1547 type leafref { 1548 path "/policy-variables/policy-variable/policy-value"; 1549 } 1550 description 1551 "policy value"; 1552 } 1553 } 1554 description 1555 "Choice one argument format"; 1556 } 1557 description 1558 "List for policy argument"; 1560 } 1561 container result { 1562 choice argument { 1563 case explict-variable { 1564 leaf explict-variable { 1565 type leafref { 1566 path "/policy-variables/policy-variable/explict-variable"; 1567 } 1568 description 1569 "explict variable"; 1570 } 1571 } 1572 case implict-variable { 1573 leaf implict-variable { 1574 type leafref { 1575 path "/policy-variables/policy-variable/implict-variable"; 1576 } 1577 description 1578 "implict variable"; 1579 } 1580 } 1581 case value { 1582 leaf policy-value { 1583 type leafref { 1584 path "/policy-variables/policy-variable/policy-value"; 1585 } 1586 description 1587 "policy value"; 1588 } 1589 } 1590 description 1591 "Choice one argument format"; 1592 } 1593 description 1594 "Container for result"; 1595 } 1596 } 1597 } 1598 case rpc-call { 1599 container rpc-call { 1600 leaf name { 1601 type string; 1602 description 1603 "The name of the YANG RPC or YANG action to be 1604 called."; 1605 } 1606 container input { 1607 list policy-argument { 1608 key "name"; 1609 leaf name { 1610 type string; 1611 description 1612 "Policy argument name"; 1613 } 1614 choice argument { 1615 case explict-variable { 1616 leaf explict-variable { 1617 type leafref { 1618 path "/policy-variables/policy-variable/explict-variable"; 1619 } 1620 description 1621 "explict variable"; 1622 } 1623 } 1624 case implict-variable { 1625 leaf implict-variable { 1626 type leafref { 1627 path "/policy-variables/policy-variable/implict-variable"; 1628 } 1629 description 1630 "implict variable"; 1631 } 1632 } 1633 case value { 1634 leaf policy-value { 1635 type leafref { 1636 path "/policy-variables/policy-variable/policy-value"; 1637 } 1638 description 1639 "policy value"; 1640 } 1641 } 1642 description 1643 "Choice one argument format"; 1644 } 1645 description 1646 "List for policy argument"; 1647 } 1648 description 1649 "Container for input"; 1650 } 1651 container output { 1652 list policy-argument { 1653 key "name"; 1654 leaf name { 1655 type string; 1656 description 1657 "Policy argument name"; 1658 } 1659 choice argument { 1660 case explict-variable { 1661 leaf explict-variable { 1662 type leafref { 1663 path "/policy-variables/policy-variable/explict-variable"; 1664 } 1665 description 1666 "explict variable"; 1667 } 1668 } 1669 case implict-variable { 1670 leaf implict-variable { 1671 type leafref { 1672 path "/policy-variables/policy-variable/implict-variable"; 1673 } 1674 description 1675 "implict variable"; 1676 } 1677 } 1678 case value { 1679 leaf policy-value { 1680 type leafref { 1681 path "/policy-variables/policy-variable/policy-value"; 1682 } 1683 description 1684 "policy value"; 1685 } 1686 } 1687 description 1688 "Choice one argument format"; 1689 } 1690 description 1691 "List for policy argument"; 1692 } 1693 description 1694 "Container for output"; 1695 } 1696 description 1697 "Container for rpc call"; 1698 } 1699 } 1700 } 1701 description 1702 "List for actions"; 1703 } 1704 description 1705 "Container for Actions"; 1706 } 1707 description 1708 "List for Events"; 1709 } 1710 description 1711 "YANG data module for defining event triggers and actions for 1712 network management purposes"; 1713 } 1714 } 1716 1718 7. Security Considerations 1720 The YANG modules defined in this document MAY be accessed via the 1721 RESTCONF protocol [RFC8040] or NETCONF protocol ([RFC6241]). The 1722 lowest RESTCONF or NETCONF layer requires that the transport-layer 1723 protocol provides both data integrity and confidentiality, see 1724 Section 2 in [RFC8040] and [RFC6241]. The lowest NETCONF layer is 1725 the secure transport layer, and the mandatory-to-implement secure 1726 transport is Secure Shell (SSH)[RFC6242] . The lowest RESTCONF layer 1727 is HTTPS, and the mandatory-to-implement secure transport is TLS 1728 [RFC5246]. 1730 The NETCONF access control model [RFC6536] provides the means to 1731 restrict access for particular NETCONF or RESTCONF users to a 1732 preconfigured subset of all available NETCONF or RESTCONF protocol 1733 operations and content. 1735 There are a number of data nodes defined in this YANG module that are 1736 writable/creatable/deletable (i.e., config true, which is the 1737 default). These data nodes may be considered sensitive or vulnerable 1738 in some network environments. Write operations (e.g., edit-config) 1739 to these data nodes without proper protection can have a negative 1740 effect on network operations. These are the subtrees and data nodes 1741 and their sensitivity/vulnerability: 1743 o /eca/event/name 1745 o /eca/policy-variables/policy-variable/name 1747 o /eca/event/actions/action/name 1749 o /eca/event/condition/name 1751 8. IANA Considerations 1753 This document registers two URIs in the IETF XML registry [RFC3688]. 1754 Following the format in [RFC3688], the following registrations are 1755 requested to be made: 1757 --------------------------------------------------------------------- 1758 URI: urn:ietf:params:xml:ns:yang:ietf-eca 1759 Registrant Contact: The IESG. 1760 XML: N/A, the requested URI is an XML namespace. 1761 --------------------------------------------------------------------- 1763 This document registers one YANG module in the YANG Module Names 1764 registry [RFC6020]. 1766 --------------------------------------------------------------------- 1767 Name: ietf-eca 1768 Namespace: urn:ietf:params:xml:ns:yang:ietf-eca 1769 Prefix: eca 1770 Reference: RFC xxxx 1771 --------------------------------------------------------------------- 1773 9. Acknowledges 1775 This work has benefited from the discussions of ECA Policy over the 1776 years. In particular, the SUPA project [ 1777 https://datatracker.ietf.org/wg/supa/about/ ] provided approaches to 1778 express high-level, possibly network-wide policies to a network 1779 management function (within a controller, an orchestrator, or a 1780 network element). 1782 Igor Bryskin, Xufeng Liu, Alexander Clemm, Henk Birkholz, Tianran 1783 Zhou contributed to an earlier version of [GNCA]. We would like to 1784 thank the authors of that document on event response behaviors 1785 delegation for material that assisted in thinking that helped improve 1786 this document. 1788 10. Objectives for existing and possible future extension 1790 This section describes some of the design objectives for the ECA 1791 Policy management Data Model: 1793 o Clear and precise identification of Event types in the ECA Policy. 1795 o Clear and precise identification of managed object (i.e., policy 1796 variable) in the ECA Policy. 1798 o Allow nested ECA policy,e.g, one event to be able to call another 1799 nested event. 1801 o Allow the client use NETCONF/RESTCONF protocol or any other 1802 management protocol to configure ECA Policy. 1804 o Allow the server send updates only when the value falls within a 1805 certain range. 1807 o Allow the server send updates only when the value exceeds a 1808 certain threshold for the first time but not again until the 1809 threshold is cleared. 1811 o Allow the client optimize the system behavior across the whole 1812 network to meet objectives and provide some performance guarantees 1813 for network services. 1815 o Allow the the server provide rapid autonomic response in the 1816 network device that can exhibit self-management properties 1817 including self-configuration, self-healing, self-optimization, and 1818 self-protection. 1820 o Allow the ECA execution thread in the server use YANG Push/YANG 1821 Push extension to communicate with the client. 1823 11. Contributors 1824 Chongfeng Xie 1825 China Telecom 1826 Email: xiechf@ctbri.com.cn 1828 Xiaopeng Qin 1829 Huawei 1830 Huawei Bld., No.156 Beiqing Rd. 1831 Beijing 100095 1832 China 1833 qinxiaopeng@huawei.com 1835 Alexander Clemm 1836 Futurewei 1837 Email: ludwig@clemm.org 1839 Henk Birkholz 1840 Fraunhofer SIT 1841 Email: henk.birkholz@sit.fraunhofer.de 1843 Tianran Zhou 1844 Huawei 1845 Email: zhoutianran@huawei.com 1847 Aihua Guo 1848 Individual 1849 aihguo1@gmail.com 1851 Nicola Sambo 1852 Scuola Superiore Sant'Anna 1853 Via Moruzzi 1 1854 Pisa 56124 1855 Italy 1856 Email: nicola.sambo@sssup.it 1858 Giuseppe Fioccola 1859 Huawei Technologies 1860 Riesstrasse, 25 1861 Munich 80992 1862 Germany 1863 Email: giuseppe.fioccola@huawei.com 1865 12. Normative References 1867 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1868 Requirement Levels", March 1997. 1870 [RFC2981] Kavasseri, R., Ed., "Event MIB", RFC 2981, 1871 DOI 10.17487/RFC2981, October 2000, 1872 . 1874 [RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) 1875 Extensions", RFC 3460, DOI 10.17487/RFC3460, January 2003, 1876 . 1878 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1879 DOI 10.17487/RFC3688, January 2004, 1880 . 1882 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1883 the Network Configuration Protocol (NETCONF)", RFC 6020, 1884 DOI 10.17487/RFC6020, October 2010, 1885 . 1887 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1888 and A. Bierman, Ed., "Network Configuration Protocol 1889 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1890 . 1892 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1893 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1894 . 1896 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 1897 Profile (MPLS-TP) Identifiers", RFC 6370, 1898 DOI 10.17487/RFC6370, September 2011, 1899 . 1901 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1902 Protocol (NETCONF) Access Control Model", RFC 6536, 1903 DOI 10.17487/RFC6536, March 2012, 1904 . 1906 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1907 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1908 . 1910 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 1911 RFC 7952, DOI 10.17487/RFC7952, August 2016, 1912 . 1914 [RFC8328] Liu, W., Xie, C., Strassner, J., Karagiannis, G., Klyus, 1915 M., Bi, J., Cheng, Y., and D. Zhang, "Policy-Based 1916 Management Framework for the Simplified Use of Policy 1917 Abstractions (SUPA)", RFC 8328, DOI 10.17487/RFC8328, 1918 March 2018, . 1920 Appendix A. ECA Model Usage Example 1922 +---------------------------+ 1923 | Management System | 1924 +---------------------------+ 1925 | 1926 ECA | 1927 Model | 1928 | 1929 V 1930 +----------------------^-----+ 1931 | Managed Device | | 1932 | | | 1933 | //--\\ Condition--+ | 1934 | | Event| / \ | 1935 | | |----->|Actions | 1936 | \\--// \ / | 1937 | ---- | 1938 +----------------------------+ 1940 For Example: 1942 The management system push down one ECA policy to control interface 1943 behavior in the managed device that supports NETCONF protocol 1944 operation. 1946 The explicit policy variable of Event "interface-state-monitoring" is 1947 set to "/if:interfaces/if:interface[if:name='eth0']", the trigger 1948 list contains two conditions: 1)The publisher sends a push-change- 1949 update notification; 2) the value of "in-errors" of 1950 interface[name='eth0'] exceeded the pre-configured threshold. When 1951 these conditions are met, corresponding action will be performed, 1952 i.e. disable interface[name='eth0']. The XML examples are shown as 1953 below: 1955 1956 2017-10-25T08:22:33.44Z 1957 1959 89 1960 1961 1962 0 1963 1964 edit1 1965 replace 1966 /ietf-interfaces:interfaces 1967 1968 1970 1971 eth0 1972 up 1973 1974 1975 1976 1977 1978 1979 1980 1982 1983 1984 interface-state-monitoring 1985 interface-exception 1986 1987 1988 10m 1989 1990 1991 1992 state-push-change 1993 sent a yang push 1994 \changed notification 1995 1996 1997 /yp:notification/yp:push-change-update/yp:id[id=89]\ 1998 /yp:datastore-changes/.../yp:target="/ietf-interfaces:interfaces='eth0'\ 1999 2000 2001 2002 2003 2004 evaluate-in-errors 2005 evaluate the number of 2006 the error packets 2007 2008 2009 greater-or-equal 2010 2011 2012 100 2013 2014 2015 2016 2017 /if:interfaces/if:interface[if:name='eth0']\ 2018 /if:statistic/if:in-errors 2019 2020 2021 2022 2023 2024 2025 foo 2026 2027 /if:interfaces/if:interface[if:name='eth0'] 2028 2029 2030 2031 eth0 2032 false 2033 2034 2035 2036 2037 2038 2039 2041 Appendix B. Usage Example of Reusing Trigger-Grouping in smarter filter 2043 The "ietf-eca.yang" module defines a set of groupings for a generic 2044 condition expression. It is intended that these groupings can be 2045 reused by other models that require the trigger conditions, for 2046 example, in some subscription and notification cases, many 2047 applications do not require every update, only updates that are of 2048 certain interest. The following example describe how to reuse the 2049 "ietf-eca" module to define the subscription and notification smarter 2050 filter. 2052 import ietf-subscribed-notifications { 2053 prefix sn; 2054 } 2055 import ietf-eca { 2056 prefix eca; 2057 } 2059 augment "/sn:subscriptions/sn:subscription" { 2060 description "add the smart filter container"; 2061 container smart-filter { 2062 description "It concludes filter configurations"; 2063 uses eca:trigger-grouping; 2064 } 2065 } 2067 The tree diagrams: 2069 module: ietf-smart-filter 2070 augment /sn:subscriptions/sn:subscription: 2071 +--rw smart-filter 2072 +-- (test)? 2073 +--:(existences) 2074 | +-- existences 2075 | +-- type? enumeration 2076 | +-- policy-variable? 2077 | -> /policy-variables/policy-variable/name 2078 +--:(boolean) 2079 | +-- boolean 2080 | +-- operator? operator 2081 | +-- policy-value 2082 | | +-- policy-argument 2083 | | +-- (argument)? 2084 | | +--:(explict-variable) 2085 | | | +-- explict-variable? leafref 2086 | | +--:(implict-variable) 2087 | | | +-- implict-variable? leafref 2088 | | +--:(value) 2089 | | +-- policy-value? leafref 2090 | +-- policy-variable 2091 | +-- policy-argument 2092 | +-- (argument)? 2093 | +--:(explict-variable) 2094 | | +-- explict-variable? leafref 2095 | +--:(implict-variable) 2096 | +-- implict-variable? leafref 2097 +--:(threshold) 2098 +-- threshold 2099 +-- rising-value? leafref 2100 +-- rising-policy-variable* 2101 | -> /policy-variables/policy-variable/name 2102 +-- falling-value? leafref 2103 +-- falling-policy-variable* 2104 | -> /policy-variables/policy-variable/name 2105 +-- delta-rising-value? leafref 2106 +-- delta-rising-policy-variable* 2107 | -> /policy-variables/policy-variable/name 2108 +-- delta-falling-value? leafref 2109 +-- delta-falling-policy-variable* 2110 | -> /policy-variables/policy-variable/name 2111 +-- startup? enumeration 2113 Appendix C. Changes between Revisions 2115 v05 - v06 2117 o Decouple ECA model from NETCONF protocol and make it applicable to 2118 other network mangement protocols. 2120 o Move objective section to the last section with additional generic 2121 objectives. 2123 v04 - v05 2125 o Harmonize with draft-bryskin and add additional attributes in the 2126 models (e.g., policy variable, func call enhancement, rpc 2127 execution); 2129 o ECA conditions part harmonization; 2131 o ECA Event, Condition, Action, Policy Variable and Value 2132 definition; 2134 o Change ietf-event.yang into ietf-eca.yang and remove ietf-event- 2135 trigger.yang 2137 v02 - v03 2139 o Usage Example Update: add an usage example to introduce how to 2140 reuse the ietf-event-trigger module to define the subscription- 2141 notification smarter filter. 2143 v01 - v02 2145 o Introduce the group-id which allow group a set of events that can 2146 be executed together 2148 o Change threshold trigger condition into variation trigger 2149 condition to further clarify the difference between boolean 2150 trigger condition and variation trigger condition. 2152 o Module structure optimization. 2154 o Usage Example Update. 2156 v00 - v01 2158 o Separate ietf-event-trigger.yang from Event management modeland 2159 ietf-event.yang and make it reusable in other YANG models. 2161 o Clarify the difference between boolean trigger condition and 2162 threshold trigger condition. 2164 o Change evt-smp-min and evt-smp-max into min-data-object and max- 2165 data-object in the data model. 2167 Authors' Addresses 2169 Michael Wang 2170 Huawei Technologies,Co.,Ltd 2171 101 Software Avenue, Yuhua District 2172 Nanjing 210012 2173 China 2175 Email: wangzitao@huawei.com 2177 Qin Wu 2178 Huawei 2179 101 Software Avenue, Yuhua District 2180 Nanjing, Jiangsu 210012 2181 China 2183 Email: bill.wu@huawei.com 2185 Igor Bryskin 2186 Individual 2188 Email: i_bryskin@yahoo.com 2190 Xufeng Liu 2191 Volta Networks 2193 Email: xufeng.liu.ietf@gmail.com 2195 Benoit Claise 2196 Cisco 2198 Email: bclaise@cisco.com