idnits 2.17.00 (12 Aug 2021) /tmp/idnits62743/draft-bryskin-netconf-automation-yang-01.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 == Line 890 has weird spacing: '...pt-name str...' -- The document date (February 28, 2018) is 1543 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7950' is defined on line 1675, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-subscribed-notifications' is defined on line 1679, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-yang-push' is defined on line 1685, but no explicit reference was found in the text == Outdated reference: draft-ietf-teas-yang-te-topo has been published as RFC 8795 == Outdated reference: draft-ietf-netconf-subscribed-notifications has been published as RFC 8639 == Outdated reference: draft-ietf-netconf-yang-push has been published as RFC 8641 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Bryskin 3 Internet-Draft Huawei Technologies 4 Intended status: Informational X. Liu 5 Expires: September 1, 2018 Jabil 6 A. Clemm 7 Huawei 8 H. Birkholz 9 Fraunhofer SIT 10 T. Zhou 11 Huawei 12 February 28, 2018 14 Generalized Network Control Automation YANG Model 15 draft-bryskin-netconf-automation-yang-01 17 Abstract 19 This document describes a YANG data model for the Generalized Network 20 Control Automation (GNCA), aimed to define an abstract and uniform 21 semantics for NETCONF/YANG scripts in the form of Event-Condition- 22 Action (ECA) containers. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 1, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. GNCA concepts and constructs . . . . . . . . . . . . . . . . 4 61 3.1. Policy Variable (PV) . . . . . . . . . . . . . . . . . . 4 62 3.2. ECA Event . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.3. ECA Condition . . . . . . . . . . . . . . . . . . . . . . 7 64 3.4. ECA Action . . . . . . . . . . . . . . . . . . . . . . . 9 65 3.5. ECA . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4. Where ECA scripts are executed? . . . . . . . . . . . . . . . 12 67 5. ECA script example . . . . . . . . . . . . . . . . . . . . . 13 68 6. Complete Model Tree Structure . . . . . . . . . . . . . . . . 15 69 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 21 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 36 75 11.2. Informative References . . . . . . . . . . . . . . . . . 37 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 78 1. Introduction 80 NETCONF/YANG has proved to be very successful in facilitating 81 interactive network control paradigm, in which a network control 82 application (controller) requests the network server to perform 83 certain (re-)configurations, then, retrieves network states of 84 interest, then asks for more (re-)configurations and so forth. This 85 said, there are multiple use cases that require stringing network 86 configuration requests together with conditioning their order of 87 execution based on certain events detected in the network, as well as 88 current, historical or predicted network states, and pushing such 89 request batches/scripts to the network server in order to control the 90 network close loop automation processes. The Generalized Network 91 Control Automation (GNCA) YANG model introduced by this document 92 defines an abstract and uniform semantics of such NETCONF/YANG 93 scripts in the form of Event-Condition-Action (ECA) containers. 95 2. Purpose 97 The purpose of the Generalized Network Control Automation (GNCA) YANG 98 model is to enable an environment allowing for manipulation of close 99 loop network automation via configuration of abstract Event- 100 Condition-Action (ECA) scripts. The model defines the semantics of 101 said scripts; however, how the scripts are actually implemented by 102 the server is not governed by the model. The server may, for 103 example, based on pushed ECA configuration, generate and execute 104 server specific scripts. How this is done is outside of the scope of 105 this document. 107 Although not all event response behaviors could be delegated to the 108 network server, there are many circumstances where it is highly 109 desirable. For example: 111 a. Reaction to many network events is well understood and does not 112 require additional information (such as broader or higher level 113 network view or analytics input); 115 b. It is often imperative for the network to start acting as quickly 116 as the event is detected. In other words, there might simply be 117 no time for the network-controller communication; 119 c. A paradigm in which a controller micro-manages every network 120 behavior does not scale. Simply put, there are always things 121 that the network has to do autonomously (i.e. when the controller 122 is not looking), which does not mean that the controller should 123 have no say as to how said things need to be done; 125 d. Numerous important use cases and applications can benefit from 126 ability to define in an abstract and uniformly way a programmable 127 logic in one place (e.g. on the controller) and execute it 128 someplace else (e.g. on the server). 130 The main objective of the GNCA is to generalize the ECA network 131 control style, so that it could be applied to arbitrary network 132 events/conditions and manipulate network auto-control of large 133 variety of network resources. Such a generalization would allow, for 134 example, conveying to the network a coherent/ordered/prioritized 135 behavior for recovering from a network failure or failures affecting 136 simultaneously multiple services, instruct the network how to fight 137 rapidly developing congestions, what to do when power outage is 138 detected and so forth. In fact, it could be argued that without some 139 sort of close loop network control automation hierarchical network 140 control realistically could not be achieved. 142 The GNCA YANG model could be also thought of as an attempt to 143 generalize the smart filter subscription machinery by stating that 144 sending a notification is one of possibly multiple actions that 145 network could perform reacting to the specified smart trigger. 146 According to "Smart filters for Push Updates - Problem Statement" 147 [I-D.clemm-netconf-push-smart-filters-ps]: 149 "They [smart filters] are also useful for network automation, in 150 which automated actions are automatically triggered based on when 151 certain events in the network occur while certain conditions hold. A 152 YANG-Push subscription with a smart filter can in effect act as a 153 source for such events. Combined with an optional check for a 154 condition when an event is observed, this can serve as the basis of 155 action." 157 In a nutshell GNCA facilitates an environment in which the network 158 automation logic could be defined in a form of ECA scripts by a 159 client, pushed to the network before the events of interest happen, 160 and executed by the network after the events are detected. 162 Finally, according to the smart filters problem statement, the 163 following smart filters will be considered: 165 "o Filters that involve freely programmable logic" 167 ECA scripts could serve as a vehicle to associate with a smart filter 168 a complex freely programmable logic to detect the event of interest 169 in the first place. 171 3. GNCA concepts and constructs 173 3.1. Policy Variable (PV) 175 Policy Variable (PV) is a structure to keep interim results/meta data 176 during the execution of an ECA script. For example, a PV could be 177 used as an output parameter of an RPC invoked by ECA1 to be used in a 178 condition expression for ECA2. 180 With respect to ECAs the scope of a PV is either global or (ECA) 181 local. Global PVs are permanent. They are kept in the top level PV 182 container and are shared between all ECAs of the script. Local PVs 183 are kept within the internal PV container of an ECA. Local PVs could 184 be either dynamic - appear/disappear with start/stop of the ECA 185 execution, or static - exist as long as the ECA is configured. 187 Each PV has the following attributes: 189 o Globally or ECA scope unique name; 190 o type - either pre-defined (e.g. Boolea, integer, uint64,etc.) or 191 specified via XPath pointing to a data store node or a sub-tree of 192 the required structure. For example, PV named "Link" could be 193 associated with the "/TE_Topologies/TE_Links/TE_Link" XPath in 194 accordance with the TE Topology model [I-D.ietf-teas-yang-te-topo] 195 and hence be capable of accommodating the entire TE Link 196 container; 198 o value - data stored in the PV structured according to the PV type. 200 The following operations are allowed with/on a PV: 202 o initialize (with a constant/enum/identity); 204 o assign (with contents of another same type PV); 206 o read (retrieve data store contents pointed by the specified same 207 type XPath/sub-tree); 209 o write (modify same type CONFIG=TRUE data store state with the PV's 210 content/value); 212 o insert (PV's content into a same type list); 214 o iterate (copy into PV one by one same type list elements) (See 215 examples of definition of and operations with PVs in Section 5). 217 o function calls in a form of F(dst, src), where F is an identity of 218 a function from extendable function library, dst and src are 219 destination and source PVs respectively, the function's input 220 parameters, with the result returned in dst. 222 Arbitrary expressions with PVs are for future study. 224 PVs could be used as input/output of an ECA invoked RPC. PVs could 225 also be a source of information sent to the client in notification 226 messages. 228 PVs could be used in condition expressions (see Section 5). 230 The model structure for the Policy Variable is shown below: 232 +--rw policy-variables 233 | +--rw policy-variable* [name] 234 | +--rw name string 235 | +--rw (type-choice)? 236 | | +--:(common) 237 | | | +--rw type? identityref 238 | | +--:(xpath) 239 | | +--rw xpath? string 240 | +--rw value? 242 3.2. ECA Event 244 ECA Event is any subscribable event notification either explicitly 245 defined in a YANG module supported by the server or a smart filter 246 conveyed to the server via smart filter subscription. Additionally, 247 an event could be associated with a one-time or periodic timer. 249 Event notification contents become in the ECA context implicit local 250 dynamic PVs with automatically generated names. Let's assume 251 Network_Failure_Is_Detected event is defined that carries to a 252 subscriber the detected failure type (failureType), ID (failureID) 253 and the affected by the failure TE link state (teLInk). In the 254 context of the associated with the Networ_Failure_Is_Detected event 255 ECA failureType, failureID and teLink are implicit local dynamic PVs 256 that could be used in the embodied Condition and Action containers 257 along with explicitly defined global and ECA local (static and/or 258 dynamic) PVs. 260 One way to think of NETWONF/YANG Event Notification is as Remote 261 Procedure Call-back, i.e. server->client directed RPC When a 262 subscribable NETWONF/YANG Event and associated with it ECA is pushed 263 to the server within an ECA script, the server is expected to 264 interpret this as follows: take the contents of the event 265 notification and execute the logic defined by the associated 266 Condition-Action chain (as I (client) would do on receipt of the 267 notification) in order to decide how to react to the event. Recall 268 that the whole purpose of ECA scripts is to reduce as much as 269 possible the client-server communication. 271 All events (specified in at least one ECA pushed to the server) are 272 required to be constantly monitored by the server. One way to think 273 of this is that the server subscribes to its own publications with 274 respect to all events that are associated with at least one ECA. 276 3.3. ECA Condition 278 ECA Condition is evaluated to TRUE or FALSE logical expression. 279 There are two ways how an ECA Condition could be specified: 281 o in a form of XPath expression; 283 o as a hierarchy of comparisons and logical combinations of thereof. 285 The former option allows for specifying a condition of arbitrary 286 complexity as a single string with an XPath expression, in which 287 pertinent PVs and data store states are referred to by their 288 respective positions in the YANG tree. 290 The latter option allows for configuring logical hierarchies. The 291 bottom of said hierarchies are primitive comparisons (micro- 292 conditions) specified in a form of: 294 296 where arg1 and arg2 represent either constant/enum/identity, PV or 297 pointed by XPath data store node or sub-tree, 299 relation is one of the comparison operations from the set: ==, !=, 300 >, <, >=, <= 302 Primitive comparisons could be combined hierarchically into macro- 303 conditions via && and || logical operations. 305 Regardless of the choice of their specification, ECA Conditions are 306 associated with ECA Events and evaluated only within event threads 307 triggered by the event detection. 309 When an ECA Condition is evaluated to TRUE, the associated with it 310 ECA Action is executed. 312 The model structure for the ECA Condition is shown below: 314 +--rw conditions 315 | +--rw condition* [name] 316 | +--rw name string 317 | +--rw (expression-choice)? 318 | +--:(logical-operation) 319 | | +--rw logical-operation-type? identityref 320 | | +--rw comparison-operation* [name] 321 | | | +--rw name string 322 | | | +--rw comparision-type? identityref 323 | | | +--rw arg1 324 | | | | +--rw policy-argument 325 | | | | +--rw type? identityref 326 | | | | +--rw (argument-choice)? 327 | | | | +--:(policy-constant) 328 | | | | | +--rw constant? string 329 | | | | +--:(policy-variable) 330 | | | | | +--rw policy-variable? leafref 331 | | | | +--:(local-policy-variable) 332 | | | | | +--rw local-policy-variable? leafref 333 | | | | +--:(xpath) 334 | | | | +--rw xpath? string 335 | | | +--rw arg2 336 | | | +--rw policy-argument 337 | | | +--rw type? identityref 338 | | | +--rw (argument-choice)? 339 | | | +--:(policy-constant) 340 | | | | +--rw constant? string 341 | | | +--:(policy-variable) 342 | | | | +--rw policy-variable? leafref 343 | | | +--:(local-policy-variable) 344 | | | | +--rw local-policy-variable? leafref 345 | | | +--:(xpath) 346 | | | +--rw xpath? string 347 | | +--rw sub-condition* [name] 348 | | +--rw name -> /gnca/conditions/condition/name 349 | +--:(xpath) 350 | +--rw condition-xpath? string 352 The policy arguments arg1 and arg2 have the following structure: 354 +--rw policy-argument 355 +--rw type? identityref 356 +--rw (argument-choice)? 357 +--:(policy-constant) 358 | +--rw constant? string 359 +--:(policy-variable) 360 | +--rw policy-variable? leafref 361 +--:(local-policy-variable) 362 | +--rw local-policy-variable? leafref 363 +--:(xpath) 364 +--rw xpath? string 366 3.4. ECA Action 368 ECA Action is one of the following operations to be carried out by a 369 server: 371 o (-re)configuration - modifying a CONFIG=TRUE data store state 373 o (re-)configuration scheduling - scheduling one time or periodic 374 (re-)configuration in the future 376 o sending one time notification; 378 o adding/removing event notify subscription (essentially, the same 379 action as performed when a client explicitly adds/removes a 380 subscription) 382 o executing an RPC defined by a YANG module supported by the server 383 (the same action as performed when a client interactively calls 384 the RPC); 386 o performing operations and function calls on PVs (such as assign, 387 read, insert, iterate, etc); 389 o starting/stopping timers; 391 o stopping current ECA; 393 o invoking another ECA; 395 o NO-ACTION action - meaningful only within ECA's Cleanup Condition- 396 Action list to indicate that the ECA's Normal Condition-Action 397 thread must be terminated as soon as one of the required Actions 398 is rejected by the server (see more Section 3.4). 400 Two points are worth noting: 402 1. When a NETWONF/YANG RPC appears in an ECA Action body, the server 403 is expected to interpret this as follows: execute the same logic, 404 as when the client explicitly calls said RPC via NETCONF. For 405 example, when TE_Tunnel_Path_Computation RPC is found in the 406 currently executed Action, the server is expected to call its TE 407 path computation engine and pass to it the specified parameters 408 in the Action input. 410 2. When a "Send notification" action is configured as an ECA Action, 411 the notification message to be sent to the client may contain not 412 only elements of the data store (as, for example, YANG PUSH or 413 smart filter notifications do), but also the contents of global 414 and local PVs, which store results of arbitrary operations 415 performed on the data store contents (possibly over arbitrary 416 period of time) to determine, for example, history/evolution of 417 data store changes, median values, ranges and rates of the 418 changes, results of configured function calls and expressions, 419 etc. - in short, any data the client may find interesting about 420 the associated event with all the logic to compute said data 421 delegated to the server. 423 Multiple ECA Condition/Action pairs could be combined into a macro- 424 action. 426 Multiple ECA (macro-)Actions could be triggered by a single ECA 427 event. 429 Any given ECA Condition or Action may appear in more than one ECAs. 431 The model structure for the ECA Action is shown below: 433 +--rw actions 434 | +--rw action* [name] 435 | +--rw name string 436 | +--rw action-element* [name] 437 | | +--rw name string 438 | | +--rw action-type? identityref 439 | | +--rw (action-operation)? 440 | | +--:(action) 441 | | | +--rw action-name? 442 | | | -> /gnca/actions/action/name 443 | | +--:(content-moving) 444 | | | +--rw content-moving 445 | | | +--rw content-moving-type? identityref 446 | | | +--rw src 447 | | | | +--rw policy-argument 448 | | | +--rw dst 449 | | | +--rw policy-argument 450 | | +--:(function-call) 451 | | | +--rw function-call 452 | | | +--rw function-type? identityref 453 | | | +--rw src 454 | | | | +--rw policy-argument 455 | | | +--rw dst 456 | | | +--rw policy-argument 457 | | +--:(rpc-operation) 458 | | | +--rw rpc-operation 459 | | | +--rw name? string 460 | | | +--rw nc-action-xpath? string 461 | | | +--rw policy-variable* [name] 462 | | | +--rw name string 463 | | | +--rw policy-argument 464 | | +--:(notify-operation) 465 | | +--rw notify-operation 466 | | +--rw name? string 467 | | +--rw policy-variable* [name] 468 | | +--rw name string 469 | | +--rw policy-argument 470 | +--rw time-schedule 471 | +--rw start? yang:date-and-time 472 | +--rw repeat-interval? string 474 3.5. ECA 476 An ECA container includes: 478 o Event name 479 o List of local PVs. As mentioned, local PVs could be configured as 480 dynamic (their instances appear/disappear with start/stop of the 481 ECA execution) or static (their instances exisr as long as the ECA 482 is configured). The ECA input (the contents of the associated 483 notification message, such as YANG PUSH or smart filter 484 notification message) are the ECA's implict local dynamic PVs with 485 automatically generated names 487 o Normal CONDITION-ACTION list: configured conditions each with 488 associated actions to be executed if the condition is evaluated to 489 TRUE 491 o Cleanup CONDITION-ACTION list: configured conditions/actions to be 492 evaluated/executed in case any Action from the Normal CONDITION- 493 ACTION list was attempted and rejected by the server. In other 494 words, this list specifies the ECA cleanup/unroll logic after 495 rejection of an Action from the Normal CONDITION-ACTION list. An 496 empty Cleanup CONDITION-ACTION list signifies that the ECA's 497 normal Actions should be executed regardless of whether the 498 previously attempted ECA Actions were rejected or not by the 499 server. Cleanup CONDITION-ACTION list containing a single NO- 500 ACTION Action signifies that the ECA thread is to be immediately 501 terminated on rejection of any attempted Action (without executing 502 any cleanup logic) 504 4. Where ECA scripts are executed? 506 It could be said that the main idea of the GNCA is decoupling the 507 place where the network control logic is defined from the place where 508 it is executed. In previous sections of this document it is assumed 509 that the network control logic is defined by a client and pushed to 510 and executed by the network (server). This is accomplished via ECA 511 scripts, which are essentially bunches of regular NETCONF style 512 operations (such as get, set, call rpc) and event notifications glued 513 together via Policy Variables, PVs. It is worth noting that said ECA 514 scripts could be easily moved around and executed by any entity 515 supporting the GNCA YANG model (i.e. capable of interpreting the ECA 516 scripts). One interesting implication of this is that the ECA 517 scripts could be executed by neither client nor server, but a 3d 518 party entity, for instance, with a special focus on the control of a 519 particular network domain or/and special availability of/proximity to 520 information/ resources that could contribute to the network control 521 decision process. For example, the ECA scripts could be pushed to a 522 Path Computation Element (PCE) adopted to support the GNCA YANG 523 model. Specialized ECA scripts could be fanned out to multiple 524 specialized controllers to take care of different aspects of a 525 network domain control. 527 Another interesting idea is to combine the GNCA with hierarchical 528 T-SDN architecture. In particular, the ECA scripts conveyed by a 529 client to a network orchestrator could be pushed (modified or 530 unmodified) hierarchically down to lower level controllers. After 531 all, the goal of the hierarchical T-SDN is to create a paradigm in 532 which the higher level of a controller in the hierarchy, the broader 533 (topologically and/or functionally) its control on the network and 534 the lesser its involvement in the network's micro-management in real 535 time. On the other hand, it is desirable for a higher level 536 controller to have a say as to how the subordinate controllers and, 537 by extension, the network under control should deal with events and 538 situations that are handled autonomously (i.e. without bothering the 539 higher level controller in real time). The ECA scripts pushed down 540 the T-SDN hierarchy may help to achieve this objective. 542 5. ECA script example 544 Consider a situation on a TE network when a network failure 545 simultaneously affecting multiple TE tunnels. Normally, the TE 546 network relies in this case on TE tunnels pre-configured protection/ 547 restoration capabilities and lets the TE tunnels to auto-recover 548 themselves independently from each other. However, this default 549 behavior may not be desired in some configurations/use cases because: 551 a. Recovery procedures of a "greedy" TE tunnel may block the 552 recovery of other TE tunnels; 554 b. Shared mesh protection/restoration schemes are in place 556 In such cases the network has to perform the recovery of failure 557 affected TE tunnels as a coordinated process. Furthermore, it is 558 quite common that network resources available for the dynamic 559 recovery procedures are limited, in which case it is desirable to 560 convey to the network the policy/order in which the TE tunnels should 561 be recovered. Different policies may be considered, to name a few: 563 1. Recover as many TE tunnels as possible; 565 2. Recover TE tunnels in accordance with their importance/priority; 567 3. Recover all unprotected TE tunnels before recovering broken 568 connections/LSPs of protected TE tunnels (because the latter can 569 tolerate the failure hopefully until it is repaired). 571 Let's describe an ECA script that could be pushed by the controller 572 application instructing the network to perform multiple TE tunnel 573 failure recovery according to policy (3) above. 575 Assumptions: it is assumed that in one or several YANG modules 576 supported by the server the following is defined: 578 o Subscribable "Network_Failure_Is_Detected" event carrying in the 579 notification message the detected failure type (failureType), ID 580 (failureID) and the affected by the failure TE link ID (linkID); 582 o RPC "PathDependsOnLink" taking as an input a TE_Path and 583 TE_Link_ID and returning in its output Boolean indicating whether 584 or not the specified path goes through the link with the specified 585 ID; 587 o RPC "ReplaceTunnelsAwayFromLink" taking as an input a list of TE 588 tunnel key leafrefs and ID of to be avoided link, performing the 589 tunnel replacement away from the link and returning no output. 591 Explicit (global) PVs: 593 o name: Yes type: Boolean 595 o name: lsp xpath: /TE_Tunnels/lsps/lsp 597 o name tunnel xpath: /TE_Tunnels/tunnels/te_tunnel 599 o name: unprotected_tunnels xpath: /TE_Tunnels/tunnels/te_tunnel/ 600 dependent_tunnels 602 o name protected_tunnels xpath: /TE_Tunnels/tunnels/te_tunnel/ 603 dependent_tunnels 605 Actions: 607 name: PopulateTunnelLists 609 body: 611 lsp iterate xpath:/TE_Tunnels/lsps 612 { 613 rpc: PathDependsOnLink(/rro, Yes); 614 if(Yes == TRUE ) 615 { 616 tunnel = /parrent_tunnel; 617 if(/protectionType == UNPROTECTED) 618 /tunnelName insert unprotected_tunnels 619 if(/protectionType != UNPROTECTED) 620 /tunnelName insert protected_tunnels 621 } 622 } 624 name: RepairTunnels 626 Body: 628 rpc: ReplaceTunnelsAwayFromLink(unprotected_tunnels, linkID); 629 rpc: ReplaceTunnelsAwayFromLink(protected_tunnels, linkID); 631 ECA: 633 eventName: Network_Failure_Is_Detected; 635 eventParams: failureType, failureID, linkID 637 Condition: TRUE (always, every time) 639 Actions: 641 unprotected_tunnels = 0; protected_tunnels =0; 643 namedAction:PopulateTunnelLists; 645 namedAction:RepairTunnels 647 Note: RPC "PathDependsOnLink" is used in the example for simplicity. 648 The RPC could be easily replaced by a scripted named action similar 649 to PopulateTunnelListes . 651 6. Complete Model Tree Structure 653 The complete tree structure of the YANG model defined in this 654 document is as follows: 656 module: ietf-gnca 657 +--rw gnca 658 +--rw policy-variables 659 | +--rw policy-variable* [name] 660 | +--rw name string 661 | +--rw (type-choice)? 662 | | +--:(common) 663 | | | +--rw type? identityref 664 | | +--:(xpath) 665 | | +--rw xpath? string 666 | +--rw value? 667 +--rw conditions 668 | +--rw condition* [name] 669 | +--rw name string 670 | +--rw (expression-choice)? 671 | +--:(logical-operation) 672 | | +--rw logical-operation-type? identityref 673 | | +--rw comparison-operation* [name] 674 | | | +--rw name string 675 | | | +--rw comparision-type? identityref 676 | | | +--rw arg1 677 | | | | +--rw policy-argument 678 | | | | +--rw type? 679 identityref 680 | | | | +--rw (argument-choice)? 681 | | | | +--:(policy-constant) 682 | | | | | +--rw constant? 683 string 684 | | | | +--:(policy-variable) 685 | | | | | +--rw policy-variable? 686 leafref 687 | | | | +--:(local-policy-variable) 688 | | | | | +--rw local-policy-variable? 689 leafref 690 | | | | +--:(xpath) 691 | | | | +--rw xpath? 692 string 693 | | | +--rw arg2 694 | | | +--rw policy-argument 695 | | | +--rw type? 696 identityref 697 | | | +--rw (argument-choice)? 698 | | | +--:(policy-constant) 699 | | | | +--rw constant? 700 string 701 | | | +--:(policy-variable) 702 | | | | +--rw policy-variable? 703 leafref 704 | | | +--:(local-policy-variable) 705 | | | | +--rw local-policy-variable? 706 leafref 707 | | | +--:(xpath) 708 | | | +--rw xpath? 709 string 710 | | +--rw sub-condition* [name] 711 | | +--rw name -> /gnca/conditions/condition 712 /name 713 | +--:(xpath) 714 | +--rw condition-xpath? string 715 +--rw actions 716 | +--rw action* [name] 717 | +--rw name string 718 | +--rw action-element* [name] 719 | | +--rw name string 720 | | +--rw action-type? identityref 721 | | +--rw (action-operation)? 722 | | +--:(action) 723 | | | +--rw action-name? 724 | | | -> /gnca/actions/action/name 725 | | +--:(content-moving) 726 | | | +--rw content-moving 727 | | | +--rw content-moving-type? identityref 728 | | | +--rw src 729 | | | | +--rw policy-argument 730 | | | | +--rw type? 731 | | | | | identityref 732 | | | | +--rw (argument-choice)? 733 | | | | +--:(policy-constant) 734 | | | | | +--rw constant? 735 | | | | | string 736 | | | | +--:(policy-variable) 737 | | | | | +--rw policy-variable? 738 leafref 739 | | | | +--:(local-policy-variable) 740 | | | | | +--rw local-policy-variable? 741 leafref 742 | | | | +--:(xpath) 743 | | | | +--rw xpath? 744 | | | | string 745 | | | +--rw dst 746 | | | +--rw policy-argument 747 | | | +--rw type? 748 | | | | identityref 749 | | | +--rw (argument-choice)? 750 | | | +--:(policy-constant) 751 | | | | +--rw constant? 752 | | | | string 753 | | | +--:(policy-variable) 754 | | | | +--rw policy-variable? 755 leafref 756 | | | +--:(local-policy-variable) 757 | | | | +--rw local-policy-variable? 758 leafref 759 | | | +--:(xpath) 760 | | | +--rw xpath? 761 | | | string 762 | | +--:(function-call) 763 | | | +--rw function-call 764 | | | +--rw function-type? identityref 765 | | | +--rw src 766 | | | | +--rw policy-argument 767 | | | | +--rw type? 768 | | | | | identityref 769 | | | | +--rw (argument-choice)? 770 | | | | +--:(policy-constant) 771 | | | | | +--rw constant? 772 | | | | | string 773 | | | | +--:(policy-variable) 774 | | | | | +--rw policy-variable? 775 leafref 776 | | | | +--:(local-policy-variable) 777 | | | | | +--rw local-policy-variable? 778 leafref 779 | | | | +--:(xpath) 780 | | | | +--rw xpath? 781 | | | | string 782 | | | +--rw dst 783 | | | +--rw policy-argument 784 | | | +--rw type? 785 | | | | identityref 786 | | | +--rw (argument-choice)? 787 | | | +--:(policy-constant) 788 | | | | +--rw constant? 789 | | | | string 790 | | | +--:(policy-variable) 791 | | | | +--rw policy-variable? 792 leafref 793 | | | +--:(local-policy-variable) 794 | | | | +--rw local-policy-variable? 795 leafref 796 | | | +--:(xpath) 797 | | | +--rw xpath? 798 | | | string 799 | | +--:(rpc-operation) 800 | | | +--rw rpc-operation 801 | | | +--rw name? string 802 | | | +--rw nc-action-xpath? string 803 | | | +--rw policy-variable* [name] 804 | | | +--rw name string 805 | | | +--rw policy-argument 806 | | | +--rw type? 807 | | | | identityref 808 | | | +--rw (argument-choice)? 809 | | | +--:(policy-constant) 810 | | | | +--rw constant? 811 | | | | string 812 | | | +--:(policy-variable) 813 | | | | +--rw policy-variable? 814 leafref 815 | | | +--:(local-policy-variable) 816 | | | | +--rw local-policy-variable? 817 leafref 818 | | | +--:(xpath) 819 | | | +--rw xpath? 820 | | | string 821 | | +--:(notify-operation) 822 | | +--rw notify-operation 823 | | +--rw name? string 824 | | +--rw policy-variable* [name] 825 | | +--rw name string 826 | | +--rw policy-argument 827 | | +--rw type? 828 | | | identityref 829 | | +--rw (argument-choice)? 830 | | +--:(policy-constant) 831 | | | +--rw constant? 832 | | | string 833 | | +--:(policy-variable) 834 | | | +--rw policy-variable? 835 leafref 836 | | +--:(local-policy-variable) 837 | | | +--rw local-policy-variable? 838 leafref 839 | | +--:(xpath) 840 | | +--rw xpath? 841 | | string 842 | +--rw time-schedule 843 | +--rw start? yang:date-and-time 844 | +--rw repeat-interval? string 845 +--rw ecas 846 | +--rw eca* [name] 847 | +--rw name string 848 | +--rw event-name string 849 | +--rw policy-variable* [name] 850 | | +--rw name string 851 | | +--rw (type-choice)? 852 | | | +--:(common) 853 | | | | +--rw type? identityref 854 | | | +--:(xpath) 855 | | | +--rw xpath? string 856 | | +--rw value? 857 | | +--rw is-static? boolean 858 | +--rw condition-action* [name] 859 | | +--rw name string 860 | | +--rw condition? -> /gnca/conditions/condition/name 861 | | +--rw action? -> /gnca/actions/action/name 862 | +--rw cleanup-condition-action* [name] 863 | | +--rw name string 864 | | +--rw condition? -> /gnca/conditions/condition/name 865 | | +--rw action? -> /gnca/actions/action/name 866 | +---x start 867 | +---x stop 868 | +---x pause 869 | +---x resume 870 | +---x next-action 871 | +--ro execution* [id] 872 | +--ro id uint32 873 | +--ro oper-status? enumeration 874 | +--ro start-time? 875 | | yang:date-and-time 876 | +--ro stop-time? 877 | | yang:date-and-time 878 | +--ro next-scheduled-time? 879 | | yang:date-and-time 880 | +--ro last-condition-action? 881 | | -> ../../condition-action/name 882 | +--ro last-condition? 883 | | -> ../../condition-action/condition 884 | +--ro last-action? 885 | | -> ../../condition-action/action 886 | +--ro last-cleanup-condition-action? 887 | -> ../../cleanup-condition-action/name 888 +--rw eca-scripts 889 | +--rw eca-script* [script-name] 890 | +--rw script-name string 891 | +--rw eca* [eca-name] 892 | +--rw eca-name -> /gnca/ecas/eca/name 893 +--rw running-script? 894 -> /gnca/eca-scripts/eca-script/script-name 896 7. YANG Module 898 file "ietf-gnca@2018-02-28.yang" 899 module ietf-gnca { 900 yang-version 1.1; 901 namespace "urn:ietf:params:xml:ns:yang:ietf-gnca"; 903 prefix "gnca"; 905 import ietf-yang-types { 906 prefix "yang"; 907 } 909 organization 910 "IETF Network Configuration (NETCONF) Working Group"; 912 contact 913 "WG Web: 914 WG List: 916 Editor: Igor Bryskin 917 919 Editor: Xufeng Liu 920 922 Editor: Alexander Clemm 923 "; 925 description 926 "Event Condition Action (ECA) model."; 928 revision 2018-02-28 { 929 description "Initial revision"; 930 reference "RFC XXXX"; 931 } 933 /* 934 * Typedefs 935 */ 936 identity argument-type { 937 description 938 "Possible values are: 939 constant, variable, or datastore state."; 940 } 942 identity comparison-type { 943 description 944 "Possible values are: 945 equal, not-equal, greater, greater-equal, less, less-equal."; 946 } 948 identity logical-operation-type { 949 description 950 "Possible values are: 951 not, or, and."; 952 } 954 identity function-type { 955 description 956 "Possible values are: 957 plus, minus, mult, divide, remain."; 958 } 960 identity content-moving-operation-type { 961 description 962 "Possible values are: 963 copy, iterate, insert."; 964 } 966 identity action-type { 967 description 968 "Possible values are: 969 action, content-move, function-call, rpc, notify."; 970 } 972 identity policy-variable-type { 973 description 974 "Possible values are: 975 boolean, int32, int64, uint32, uint64, string, etc."; 976 } 978 /* 979 * Groupings 980 */ 981 grouping policy-variable-attributes { 982 description 983 "Defining the policy variable attributes, including name, type 984 and value. These attributes are used as part of the Policy 985 Variable (PV) definition."; 986 leaf name { 987 type string; 988 description 989 "A string to uniquely identify a Policy Variable (PV), either 990 globally for a global PV, or within the soope of ECA for a 991 local PV."; 992 } 993 choice type-choice { 994 description 995 "The type of a policy variable may be either a common 996 primative type like boolean or a type from existing 997 schema node referenced by an XPath string."; 998 case common { 999 leaf type { 1000 type identityref { 1001 base policy-variable-type; 1002 } 1003 description 1004 "A common policy variable type, defined as an 1005 identity."; 1006 } 1007 } 1008 case xpath { 1009 leaf xpath { 1010 type string; 1011 description 1012 "A XPath string, referencing a schema node, whose 1013 type is used as the type of the policy variable."; 1014 } 1015 } 1016 } 1017 anydata value { 1018 description 1019 "The value of the policy variable, in a format that is 1020 determined by the policy type."; 1021 } 1022 } // policy-variable-attributes 1024 grouping policy-argument { 1025 description 1026 "Defining a policy argument, which can be used in a comparison 1027 or an action."; 1028 container policy-argument { 1029 description 1030 "Containing the attributes of a policy argument."; 1031 leaf type { 1032 type identityref { 1033 base argument-type; 1034 } 1035 description 1036 "Identifies the argument type."; 1037 } 1038 choice argument-choice { 1039 description 1040 "Argument formation options, depending on the policy 1041 type."; 1042 case policy-constant { 1043 leaf constant { 1044 type string; 1045 description 1046 "The constant value of the policy argument."; 1047 } 1048 } 1049 case policy-variable { 1050 leaf policy-variable { 1051 type leafref { 1052 path "/gnca/policy-variables/" 1053 + "policy-variable/name"; 1054 } 1055 description 1056 "A reference to a global policy variable, which 1057 is shared by all ECA scripts."; 1058 } 1059 } 1060 case local-policy-variable { 1061 leaf local-policy-variable { 1062 type leafref { 1063 path "/gnca/ecas/eca/policy-variable/name"; 1064 } 1065 description 1066 "A reference to a local policy variable, which 1067 is kept within an ECA instance, and appears/ 1068 disappears with start/stop of the ECA execution."; 1069 } 1070 } 1071 case xpath { 1072 leaf xpath { 1073 type string; 1074 description 1075 "An XPath string, referencing the data in the 1076 datastore."; 1077 } 1078 } 1079 } 1080 } 1081 } // policy-argument 1083 grouping action-element-attributes { 1084 description 1085 "Grouping of action element attributes."; 1086 leaf action-type { 1087 type identityref { 1088 base action-type; 1089 } 1090 description 1091 "Identifies the action type."; 1092 } 1093 choice action-operation { 1094 description 1095 "The operation choices that an ECA Action can take."; 1096 case action { 1097 leaf action-name { 1098 type leafref { 1099 path "/gnca/actions/action/name"; 1100 } 1101 description 1102 "The operation is to execute a configured ECA Action."; 1103 } 1104 } // action 1105 case content-moving { 1106 container content-moving { 1107 description 1108 "The operation is to move contents between two policy 1109 arguments."; 1110 leaf content-moving-type { 1111 type identityref { 1112 base content-moving-operation-type; 1113 } 1114 description 1115 "The type of moving operation, which can be copy, 1116 iterate (copy a list of elements one by one), or 1117 insert."; 1118 } 1119 container src { 1120 description 1121 "The source policy argment."; 1122 uses policy-argument; 1123 } 1124 container dst { 1125 description 1126 "The destination policy argument."; 1127 uses policy-argument; 1128 } 1129 } 1130 } // content-moving 1131 case function-call { 1132 container function-call { 1133 description 1134 "The operation is to call a function, which is of one of 1135 a few basic predefined types, such as plus, minus, 1136 multiply, devide, or remainder."; 1137 leaf function-type { 1138 type identityref { 1139 base function-type; 1140 } 1141 description 1142 "One of the predefined basic function types, such as 1143 plus, minus, multiply, devide, or remainder."; 1144 } 1145 container src { 1146 description 1147 "The source policy argument."; 1148 uses policy-argument; 1149 } 1150 container dst { 1151 description 1152 "The distination policy argument."; 1153 uses policy-argument; 1154 } 1155 } 1156 } // function-call 1157 case rpc-operation { 1158 container rpc-operation { 1159 description 1160 "The operation is to call an RPC, which is defined by 1161 a YANG module supported by the server."; 1162 leaf name { 1163 type string; 1164 description 1165 "The name of the YANG RPC or YANG action to be 1166 called."; 1167 } 1168 leaf nc-action-xpath { 1169 type string; 1170 description 1171 "The location where the YANG action is defined. 1172 This is used if and only if a YANG action is called. 1173 This leaf is not set when a YANG RPC is called."; 1174 } 1175 list policy-variable { 1176 key name; 1177 description 1178 "A list of policy arguments used as the input or output 1179 parameters passed to the RPC."; 1180 leaf name { 1181 type string; 1182 description 1183 "A string name used as the list key to form a list 1184 of policy arguments."; 1185 } 1186 uses policy-argument; 1187 } 1188 } 1189 } // rpc-operation 1190 case notify-operation { 1191 container notify-operation { 1192 description 1193 "The operation is to send a YANG notification."; 1194 leaf name { 1195 type string; 1196 description 1197 "Name of the subscribed YANG notification."; 1198 } 1199 list policy-variable { 1200 key name; 1201 description 1202 "A list of policy arguments carried in the notification 1203 message."; 1204 leaf name { 1205 type string; 1206 description 1207 "A string name used as the list key to form a list 1208 of policy arguments."; 1209 } 1210 uses policy-argument; 1211 } 1212 } 1213 } // notify-operation 1214 } 1215 } // action-element-attributes 1217 /* 1218 * Data nodes 1219 */ 1220 container gnca { 1221 description 1222 "Top level container for Generalized Network Control Automation 1223 (GNCA)."; 1225 // policy-variables 1226 container policy-variables { 1227 description 1228 "Container of global Policy Variables (PVs)."; 1229 list policy-variable { 1230 key name; 1231 description 1232 "A list of global Policy Variables (PVs), with a string 1233 name as the entry key."; 1234 uses policy-variable-attributes; 1235 } 1236 } // policy-variables 1238 container conditions { 1239 description 1240 "Container of ECA Conditions."; 1241 list condition { 1242 key name; 1243 description 1244 "A list of ECA Conditions."; 1245 leaf name { 1246 type string; 1247 description 1248 "A string name to uniquely identify an ECA Condition 1249 globally."; 1250 } 1251 choice expression-choice { 1252 description 1253 "The choices of expression format to specify a condition, 1254 which can be either a XPath string or a YANG logical 1255 operation structure."; 1256 case logical-operation { 1257 leaf logical-operation-type { 1258 type identityref { 1259 base logical-operation-type; 1260 } 1261 description 1262 "The logical operation type used to combine the 1263 results from the list comparison-operation and the 1264 list sub-condition, defined below."; 1265 } 1266 list comparison-operation { 1267 key name; 1268 description 1269 "A list of comparison oprations, each of them defines 1270 a comparison in the form of , 1271 where and are policy arguments, while 1272 is the comparison-type, which can be 1273 ==, !=, >, <, >=, <="; 1274 leaf name { 1275 type string; 1276 description 1277 "A string name to uniquely identify a comparison 1278 operation."; 1280 } 1281 leaf comparision-type { 1282 type identityref { 1283 base comparison-type; 1284 } 1285 description 1286 "The comparison operation applied to the two 1287 arguments arg1 and arg2 defined blow."; 1288 } 1289 container arg1 { 1290 description 1291 "The policy argument used as the first parameter of 1292 the comparison opration. 1293 A policy argument represents either a constant, PV 1294 or data store value pointed by XPath."; 1295 uses policy-argument; 1296 } 1297 container arg2 { 1298 description 1299 "The policy argument used as the secone parameter 1300 of the comparison opration. 1301 A policy argument represents either a constant, PV 1302 or data store value pointed by XPath."; 1303 uses policy-argument; 1304 } 1305 } 1306 list sub-condition { 1307 key name; 1308 description 1309 "A list of sub conditions applied by the 1310 logical-operation-type. This list of sub conditions 1311 provides the capability of hierarchically combining 1312 conditions."; 1313 leaf name { 1314 type leafref { 1315 path "/gnca/conditions/condition/name"; 1316 } 1317 description 1318 "A reference to a defined condition, which is used 1319 as a sub-condition for the logical operation at 1320 this hierarchy level."; 1321 } 1322 } // sub-condition 1323 } // logical-operation 1324 case xpath { 1325 leaf condition-xpath { 1326 type string; 1327 description 1328 "A XPath string, representing a logical expression, 1329 which can contain comparisons of datastore values 1330 and logical operations in the XPath format."; 1331 } 1332 } // xpath 1333 } // expression-choice 1334 } // condition 1335 } // conditions 1337 container actions { 1338 description 1339 "Container of ECA Actions."; 1340 list action { 1341 key name; 1342 description 1343 "A list of ECA Actions."; 1344 leaf name { 1345 type string; 1346 description 1347 "A string name to uniquely identify an ECA Action 1348 globally."; 1349 } 1351 list action-element { 1352 key name; 1353 description 1354 "A list of elements contained in an ECA Action. "; 1355 leaf name { 1356 type string; 1357 description 1358 "A string name to uniquely identify the action element 1359 within the scope of an ECA action."; 1360 } 1361 uses action-element-attributes; 1362 } 1364 container time-schedule { 1365 description 1366 "Specifying the time schedule to execute this ECA 1367 Action. 1368 If not specified, the ECA Action is executed immediately 1369 when it is called."; 1370 leaf start { 1371 type yang:date-and-time; 1372 description 1373 "The start time of the ECA Action. 1374 If not specified, the ECA Action is executed 1375 immediately when it is called."; 1377 } 1378 leaf repeat-interval { 1379 type string { 1380 pattern 1381 '(R\d*/)?P(\d+Y)?(\d+M)?(\d+W)?(\d+D)?T(\d+H)?' 1382 + '(\d+M)?(\d+S)?'; 1383 } 1384 description 1385 "The repeat interval to execute this ECA Action. 1386 The repeat interval is a string in ISO 8601 format, 1387 representing a delay duration or a repeated delay 1388 duration. 1389 If not specified, the ECA Action is executed without 1390 delay and without repetition."; 1391 } 1392 } // time-schedule 1393 } 1394 } // actions 1396 container ecas { 1397 description 1398 "Container of ECAs."; 1399 list eca { 1400 key name; 1401 description 1402 "A lis of ECAs"; 1403 leaf name { 1404 type string; 1405 description 1406 "A string name to uniquely identify an ECA globally."; 1407 } 1408 leaf event-name { 1409 type string; 1410 mandatory true; 1411 description 1412 "The name of an event that triggers the execution of 1413 this ECA."; 1414 } 1416 list policy-variable { 1417 key name; 1418 description 1419 "A list of ECA local Policy Variables (PVs), with a 1420 string name as the entry key."; 1421 uses policy-variable-attributes; 1422 leaf is-static { 1423 type boolean; 1424 description 1425 "'true' if the PV is static; 'false' if the PV is 1426 dynamic. 1427 A dynamic PV appears/disappears with the start/stop 1428 of the ECA execution; a static PV exists as long as 1429 the ECA is configured."; 1430 } 1431 } 1433 list condition-action { 1434 key name; 1435 description 1436 "A list of Condition-Actions, which are configured 1437 conditions each with associated actions to be executed 1438 if the condition is evaluated to TRUE"; 1439 leaf name { 1440 type string; 1441 description 1442 "A string name uniquely identify a Condition-Action 1443 within this ECA."; 1444 } 1445 leaf condition { 1446 type leafref { 1447 path "/gnca/conditions/condition/name"; 1448 } 1449 description 1450 "The reference to a configured condition."; 1451 } 1452 leaf action { 1453 type leafref { 1454 path "/gnca/actions/action/name"; 1455 } 1456 description 1457 "The reference to a configured action."; 1458 } 1459 } // condition-action 1461 list cleanup-condition-action { 1462 key name; 1463 description 1464 "A list of Condition-Actions, which are configured 1465 conditions each with associated actions to be executed 1466 if the condition is evaluated to TRUE. 1467 This is the exception handler of this ECA, and is 1468 evaluated and executed in case any Action from the 1469 normal Condition-Action list was attempted and rejected 1470 by the server."; 1471 leaf name { 1472 type string; 1473 description 1474 "A string name uniquely identify a Condition-Action 1475 within this ECA."; 1476 } 1477 leaf condition { 1478 type leafref { 1479 path "/gnca/conditions/condition/name"; 1480 } 1481 description 1482 "The reference to a configured condition."; 1483 } 1484 leaf action { 1485 type leafref { 1486 path "/gnca/actions/action/name"; 1487 } 1488 description 1489 "The reference to a configured action."; 1490 } 1491 } // cleanup-condition-action 1493 action start { 1494 description 1495 "Start to execute this ECA."; 1496 } 1497 action stop { 1498 description 1499 "Stop the execution of this ECA."; 1500 } 1501 action pause { 1502 description 1503 "Pause the execution of this ECA."; 1504 } 1505 action resume { 1506 description 1507 "Resume the execution of this ECA."; 1508 } 1509 action next-action { 1510 description 1511 "Resume the execution of this ECA to complete the next 1512 action."; 1513 } 1514 list execution { 1515 key id; 1516 config false; 1517 description 1518 "A list of executions that this ECA has completed, 1519 are currently running, and will start in the scheduled 1520 future."; 1522 leaf id { 1523 type uint32; 1524 description 1525 "The ID to uniquely identify an execution of the ECA."; 1526 } 1527 leaf oper-status { 1528 type enumeration { 1529 enum completed { 1530 description "Completed with no error."; 1531 } 1532 enum running { 1533 description "Currently with no error."; 1534 } 1535 enum sleeping { 1536 description "Sleeping because of time schedule."; 1537 } 1538 enum paused { 1539 description "Paused by the operator."; 1540 } 1541 enum stoped { 1542 description "Stopped by the operator."; 1543 } 1544 enum failed { 1545 description "Failed with errors."; 1546 } 1547 enum error-handling { 1548 description 1549 "Asking the operator to handle an error."; 1550 } 1551 } 1552 description 1553 "The running status of the execution."; 1554 } 1555 leaf start-time { 1556 type yang:date-and-time; 1557 description 1558 "The time when the ECA started."; 1559 } 1560 leaf stop-time { 1561 type yang:date-and-time; 1562 description 1563 "The time when the ECA completed or stopped."; 1564 } 1565 leaf next-scheduled-time { 1566 type yang:date-and-time; 1567 description 1568 "The next time when the ECA is scheduled to resume."; 1569 } 1570 leaf last-condition-action { 1571 type leafref { 1572 path "../../condition-action/name"; 1573 } 1574 description 1575 "The reference to a condition-action last executed 1576 or being executed."; 1577 } 1578 leaf last-condition { 1579 type leafref { 1580 path "../../condition-action/condition"; 1581 } 1582 description 1583 "The reference to a condition last executed or being 1584 executed."; 1585 } 1586 leaf last-action { 1587 type leafref { 1588 path "../../condition-action/action"; 1589 } 1590 description 1591 "The reference to aa action last executed or being 1592 executed."; 1593 } 1594 leaf last-cleanup-condition-action { 1595 type leafref { 1596 path "../../cleanup-condition-action/name"; 1597 } 1598 description 1599 "The reference to a cleanup-condition-action last 1600 executed or being executed."; 1601 } 1602 } 1603 } 1604 } // ecas 1606 container eca-scripts { 1607 description 1608 "Container of ECA Scripts."; 1609 list eca-script { 1610 key script-name; 1611 description 1612 "A list of ECA Script."; 1613 leaf script-name { 1614 type string; 1615 description 1616 "A string name to uniquely identify an ECA Script."; 1617 } 1618 list eca { 1619 key eca-name; 1620 description 1621 "A list of ECAs contained in this ECA Script."; 1622 leaf eca-name { 1623 type leafref { 1624 path "/gnca/ecas/eca/name"; 1625 } 1626 description 1627 "The reference to a configured ECA."; 1628 } 1629 } 1630 } 1631 } // eca-scripts 1633 leaf running-script { 1634 type leafref { 1635 path "/gnca/eca-scripts/eca-script/script-name"; 1636 } 1637 description 1638 "The reference to the ECA script that is currently running."; 1639 } 1640 } 1641 } 1642 1644 8. IANA Considerations 1646 TBD. 1648 9. Security Considerations 1650 TBD. 1652 10. Acknowledgements 1654 The authors would like to thank Joel Halpern and Robert Wilton for 1655 their helpful comments and valuable contributions. 1657 11. References 1659 11.1. Normative References 1661 [I-D.clemm-netconf-push-smart-filters-ps] 1662 Clemm, A., Voit, E., Liu, X., Bryskin, I., Zhou, T., 1663 Zheng, G., and H. Birkholz, "Smart filters for Push 1664 Updates - Problem Statement", draft-clemm-netconf-push- 1665 smart-filters-ps-00 (work in progress), October 2017. 1667 [I-D.ietf-teas-yang-te-topo] 1668 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1669 O. Dios, "YANG Data Model for Traffic Engineering (TE) 1670 Topologies", draft-ietf-teas-yang-te-topo-14 (work in 1671 progress), February 2018. 1673 11.2. Informative References 1675 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1676 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1677 . 1679 [I-D.ietf-netconf-subscribed-notifications] 1680 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 1681 A. Tripathy, "Custom Subscription to Event Streams", 1682 draft-ietf-netconf-subscribed-notifications-09 (work in 1683 progress), January 2018. 1685 [I-D.ietf-netconf-yang-push] 1686 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 1687 Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore 1688 Subscription", draft-ietf-netconf-yang-push-14 (work in 1689 progress), February 2018. 1691 Authors' Addresses 1693 Igor Bryskin 1694 Huawei Technologies 1696 EMail: Igor.Bryskin@huawei.com 1698 Xufeng Liu 1699 Jabil 1701 EMail: Xufeng_Liu@jabil.com 1703 Alexander Clemm 1704 Huawei 1706 EMail: ludwig@clemm.org 1707 Henk Birkholz 1708 Fraunhofer SIT 1710 EMail: henk.birkholz@sit.fraunhofer.de 1712 Tianran Zhou 1713 Huawei 1715 EMail: zhoutianran@huawei.com