idnits 2.17.1 draft-bryskin-netconf-automation-yang-02.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 932 has weird spacing: '...pt-name str...' -- The document date (June 28, 2018) is 2128 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7950' is defined on line 1898, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-subscribed-notifications' is defined on line 1902, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-yang-push' is defined on line 1908, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-16 == Outdated reference: A later version (-26) exists of draft-ietf-netconf-subscribed-notifications-12 == Outdated reference: A later version (-25) exists of draft-ietf-netconf-yang-push-16 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: December 30, 2018 Volta Networks 6 A. Clemm 7 Huawei 8 H. Birkholz 9 Fraunhofer SIT 10 T. Zhou 11 Huawei 12 June 28, 2018 14 Generalized Network Control Automation YANG Model 15 draft-bryskin-netconf-automation-yang-02 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 https://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 December 30, 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 (https://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 . . . . . . . . . . . . . . . . . . . . . 40 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 41 75 11.2. Informative References . . . . . . . . . . . . . . . . . 41 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 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 A client may define an event of interest by making use of YANG PUSH 272 smart filter/subscription. Specifically, the client may configure an 273 ECA event according to the GNCA model specifying the event's name, as 274 well as the name of corresponding PUSH subscrition. In this case the 275 server is expected to: 277 o Register the event recording its name and using the referred PUSH 278 subsription trigger as definition of the event firing trigger; 280 o Auto-configure the event's ECA input in the form of local PVs 281 using the PUSH subscription's filters; 283 o At the moment of event firing intercept the notifications that 284 would be nornally sent to the PUSH subscription's clint(s); copy 285 the data store states pointed by the PUSH subscription's filters 286 into the auto-configured ECA's local PVs and execute the ECA's 287 condition-action chain. 289 All events (specified in at least one ECA pushed to the server) are 290 required to be constantly monitored by the server. One way to think 291 of this is that the server subscribes to its own publications with 292 respect to all events that are associated with at least one ECA. 294 3.3. ECA Condition 296 ECA Condition is evaluated to TRUE or FALSE logical expression. 297 There are two ways how an ECA Condition could be specified: 299 o in a form of XPath expression; 301 o as a hierarchy of comparisons and logical combinations of thereof. 303 The former option allows for specifying a condition of arbitrary 304 complexity as a single string with an XPath expression, in which 305 pertinent PVs and data store states are referred to by their 306 respective positions in the YANG tree. 308 The latter option allows for configuring logical hierarchies. The 309 bottom of said hierarchies are primitive comparisons (micro- 310 conditions) specified in a form of: 312 314 where arg1 and arg2 represent either constant/enum/identity, PV or 315 pointed by XPath data store node or sub-tree, 317 relation is one of the comparison operations from the set: ==, !=, 318 >, <, >=, <= 320 Primitive comparisons could be combined hierarchically into macro- 321 conditions via && and || logical operations. 323 Regardless of the choice of their specification, ECA Conditions are 324 associated with ECA Events and evaluated only within event threads 325 triggered by the event detection. 327 When an ECA Condition is evaluated to TRUE, the associated with it 328 ECA Action is executed. 330 The model structure for the ECA Condition is shown below: 332 +--rw conditions 333 | +--rw condition* [name] 334 | +--rw name string 335 | +--rw (expression-choice)? 336 | +--:(logical-operation) 337 | | +--rw logical-operation-type? identityref 338 | | +--rw comparison-operation* [name] 339 | | | +--rw name string 340 | | | +--rw comparision-type? identityref 341 | | | +--rw arg1 342 | | | | +--rw policy-argument 343 | | | | +--rw type? identityref 344 | | | | +--rw (argument-choice)? 345 | | | | +--:(policy-constant) 346 | | | | | +--rw constant? string 347 | | | | +--:(policy-variable) 348 | | | | | +--rw policy-variable? leafref 349 | | | | +--:(local-policy-variable) 350 | | | | | +--rw local-policy-variable? leafref 351 | | | | +--:(xpath) 352 | | | | +--rw xpath? string 353 | | | +--rw arg2 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 365 | | +--rw sub-condition* [name] 366 | | +--rw name -> /gnca/conditions/condition/name 367 | +--:(xpath) 368 | +--rw condition-xpath? string 370 The policy arguments arg1 and arg2 have the following structure: 372 +--rw policy-argument 373 +--rw type? identityref 374 +--rw (argument-choice)? 375 +--:(policy-constant) 376 | +--rw constant? string 377 +--:(policy-variable) 378 | +--rw policy-variable? leafref 379 +--:(local-policy-variable) 380 | +--rw local-policy-variable? leafref 381 +--:(xpath) 382 +--rw xpath? string 384 3.4. ECA Action 386 ECA Action is one of the following operations to be carried out by a 387 server: 389 o (-re)configuration - modifying a CONFIG=TRUE data store state 391 o (re-)configuration scheduling - scheduling one time or periodic 392 (re-)configuration in the future 394 o sending one time notification; 396 o adding/removing event notify subscription (essentially, the same 397 action as performed when a client explicitly adds/removes a 398 subscription) 400 o executing an RPC defined by a YANG module supported by the server 401 (the same action as performed when a client interactively calls 402 the RPC); 404 o performing operations and function calls on PVs (such as assign, 405 read, insert, iterate, etc); 407 o starting/stopping timers; 409 o stopping current ECA; 411 o invoking another ECA; 413 o NO-ACTION action - meaningful only within ECA's Cleanup Condition- 414 Action list to indicate that the ECA's Normal Condition-Action 415 thread must be terminated as soon as one of the required Actions 416 is rejected by the server (see more Section 3.4). 418 Two points are worth noting: 420 1. When a NETWONF/YANG RPC appears in an ECA Action body, the server 421 is expected to interpret this as follows: execute the same logic, 422 as when the client explicitly calls said RPC via NETCONF. For 423 example, when TE_Tunnel_Path_Computation RPC is found in the 424 currently executed Action, the server is expected to call its TE 425 path computation engine and pass to it the specified parameters 426 in the Action input. 428 2. When a "Send notification" action is configured as an ECA Action, 429 the notification message to be sent to the client may contain not 430 only elements of the data store (as, for example, YANG PUSH or 431 smart filter notifications do), but also the contents of global 432 and local PVs, which store results of arbitrary operations 433 performed on the data store contents (possibly over arbitrary 434 period of time) to determine, for example, history/evolution of 435 data store changes, median values, ranges and rates of the 436 changes, results of configured function calls and expressions, 437 etc. - in short, any data the client may find interesting about 438 the associated event with all the logic to compute said data 439 delegated to the server. Importantly, ECA notifications are the 440 only ECA actions that directly interact with and hence need to be 441 unambiguously understood by the client. Furthermore, the same 442 ECA may originate numerous single or repetitive semantically 443 different notifications within the same or separate event 444 firings. In order to facilitate for the client the correlation 445 of events and ECA notifications received from the server, the 446 GNCA model requires each notification to carry mandatory 447 information, such as event and (event scope unique) notification 448 names. 450 Multiple ECA Condition/Action pairs could be combined into a macro- 451 action. 453 Multiple ECA (macro-)Actions could be triggered by a single ECA 454 event. 456 Any given ECA Condition or Action may appear in more than one ECAs. 458 The model structure for the ECA Action is shown below: 460 +--rw actions 461 | +--rw action* [name] 462 | +--rw name string 463 | +--rw action-element* [name] 464 | | +--rw name string 465 | | +--rw action-type? identityref 466 | | +--rw (action-operation)? 467 | | +--:(action) 468 | | | +--rw action-name? 469 | | | -> /gnca/actions/action/name 470 | | +--:(content-moving) 471 | | | +--rw content-moving 472 | | | +--rw content-moving-type? identityref 473 | | | +--rw src 474 | | | | +--rw policy-argument 475 | | | +--rw dst 476 | | | +--rw policy-argument 477 | | +--:(function-call) 478 | | | +--rw function-call 479 | | | +--rw function-type? identityref 480 | | | +--rw src 481 | | | | +--rw policy-argument 482 | | | +--rw dst 483 | | | +--rw policy-argument 484 | | +--:(rpc-operation) 485 | | | +--rw rpc-operation 486 | | | +--rw name? string 487 | | | +--rw nc-action-xpath? string 488 | | | +--rw policy-variable* [name] 489 | | | +--rw name string 490 | | | +--rw policy-argument 491 | | +--:(notify-operation) 492 | | +--rw notify-operation 493 | | +--rw name? string 494 | | +--rw policy-variable* [name] 495 | | +--rw name string 496 | | +--rw policy-argument 497 | +--rw time-schedule 498 | +--rw start? yang:date-and-time 499 | +--rw repeat-interval? string 501 3.5. ECA 503 An ECA container includes: 505 o Event name 506 o List of local PVs. As mentioned, local PVs could be configured as 507 dynamic (their instances appear/disappear with start/stop of the 508 ECA execution) or static (their instances exisr as long as the ECA 509 is configured). The ECA input (the contents of the associated 510 notification message, such as YANG PUSH or smart filter 511 notification message) are the ECA's implict local dynamic PVs with 512 automatically generated names 514 o Normal CONDITION-ACTION list: configured conditions each with 515 associated actions to be executed if the condition is evaluated to 516 TRUE 518 o Cleanup CONDITION-ACTION list: configured conditions/actions to be 519 evaluated/executed in case any Action from the Normal CONDITION- 520 ACTION list was attempted and rejected by the server. In other 521 words, this list specifies the ECA cleanup/unroll logic after 522 rejection of an Action from the Normal CONDITION-ACTION list. An 523 empty Cleanup CONDITION-ACTION list signifies that the ECA's 524 normal Actions should be executed regardless of whether the 525 previously attempted ECA Actions were rejected or not by the 526 server. Cleanup CONDITION-ACTION list containing a single NO- 527 ACTION Action signifies that the ECA thread is to be immediately 528 terminated on rejection of any attempted Action (without executing 529 any cleanup logic) 531 4. Where ECA scripts are executed? 533 It could be said that the main idea of the GNCA is decoupling the 534 place where the network control logic is defined from the place where 535 it is executed. In previous sections of this document it is assumed 536 that the network control logic is defined by a client and pushed to 537 and executed by the network (server). This is accomplished via ECA 538 scripts, which are essentially bunches of regular NETCONF style 539 operations (such as get, set, call rpc) and event notifications glued 540 together via Policy Variables, PVs. It is worth noting that said ECA 541 scripts could be easily moved around and executed by any entity 542 supporting the GNCA YANG model (i.e. capable of interpreting the ECA 543 scripts). One interesting implication of this is that the ECA 544 scripts could be executed by neither client nor server, but a 3d 545 party entity, for instance, with a special focus on the control of a 546 particular network domain or/and special availability of/proximity to 547 information/ resources that could contribute to the network control 548 decision process. For example, the ECA scripts could be pushed to a 549 Path Computation Element (PCE) adopted to support the GNCA YANG 550 model. Specialized ECA scripts could be fanned out to multiple 551 specialized controllers to take care of different aspects of a 552 network domain control. 554 Another interesting idea is to combine the GNCA with hierarchical 555 T-SDN architecture. In particular, the ECA scripts conveyed by a 556 client to a network orchestrator could be pushed (modified or 557 unmodified) hierarchically down to lower level controllers. After 558 all, the goal of the hierarchical T-SDN is to create a paradigm in 559 which the higher level of a controller in the hierarchy, the broader 560 (topologically and/or functionally) its control on the network and 561 the lesser its involvement in the network's micro-management in real 562 time. On the other hand, it is desirable for a higher level 563 controller to have a say as to how the subordinate controllers and, 564 by extension, the network under control should deal with events and 565 situations that are handled autonomously (i.e. without bothering the 566 higher level controller in real time). The ECA scripts pushed down 567 the T-SDN hierarchy may help to achieve this objective. 569 5. ECA script example 571 Consider a situation on a TE network when a network failure 572 simultaneously affecting multiple TE tunnels. Normally, the TE 573 network relies in this case on TE tunnels pre-configured protection/ 574 restoration capabilities and lets the TE tunnels to auto-recover 575 themselves independently from each other. However, this default 576 behavior may not be desired in some configurations/use cases because: 578 a. Recovery procedures of a "greedy" TE tunnel may block the 579 recovery of other TE tunnels; 581 b. Shared mesh protection/restoration schemes are in place 583 In such cases the network has to perform the recovery of failure 584 affected TE tunnels as a coordinated process. Furthermore, it is 585 quite common that network resources available for the dynamic 586 recovery procedures are limited, in which case it is desirable to 587 convey to the network the policy/order in which the TE tunnels should 588 be recovered. Different policies may be considered, to name a few: 590 1. Recover as many TE tunnels as possible; 592 2. Recover TE tunnels in accordance with their importance/priority; 594 3. Recover all unprotected TE tunnels before recovering broken 595 connections/LSPs of protected TE tunnels (because the latter can 596 tolerate the failure hopefully until it is repaired). 598 Let's describe an ECA script that could be pushed by the controller 599 application instructing the network to perform multiple TE tunnel 600 failure recovery according to policy (3) above. 602 Assumptions: it is assumed that in one or several YANG modules 603 supported by the server the following is defined: 605 o Subscribable "Network_Failure_Is_Detected" event carrying in the 606 notification message the detected failure type (failureType), ID 607 (failureID) and the affected by the failure TE link ID (linkID); 609 o RPC "PathDependsOnLink" taking as an input a TE_Path and 610 TE_Link_ID and returning in its output Boolean indicating whether 611 or not the specified path goes through the link with the specified 612 ID; 614 o RPC "ReplaceTunnelsAwayFromLink" taking as an input a list of TE 615 tunnel key leafrefs and ID of to be avoided link, performing the 616 tunnel replacement away from the link and returning no output. 618 Explicit (global) PVs: 620 o name: Yes type: Boolean 622 o name: lsp xpath: /TE_Tunnels/lsps/lsp 624 o name tunnel xpath: /TE_Tunnels/tunnels/te_tunnel 626 o name: unprotected_tunnels xpath: /TE_Tunnels/tunnels/te_tunnel/ 627 dependent_tunnels 629 o name protected_tunnels xpath: /TE_Tunnels/tunnels/te_tunnel/ 630 dependent_tunnels 632 Actions: 634 name: PopulateTunnelLists 636 body: 638 lsp iterate xpath:/TE_Tunnels/lsps 639 { 640 rpc: PathDependsOnLink(/rro, Yes); 641 if(Yes == TRUE ) 642 { 643 tunnel = /parrent_tunnel; 644 if(/protectionType == UNPROTECTED) 645 /tunnelName insert unprotected_tunnels 646 if(/protectionType != UNPROTECTED) 647 /tunnelName insert protected_tunnels 648 } 649 } 651 name: RepairTunnels 653 Body: 655 rpc: ReplaceTunnelsAwayFromLink(unprotected_tunnels, linkID); 656 rpc: ReplaceTunnelsAwayFromLink(protected_tunnels, linkID); 658 ECA: 660 eventName: Network_Failure_Is_Detected; 662 eventParams: failureType, failureID, linkID 664 Condition: TRUE (always, every time) 666 Actions: 668 unprotected_tunnels = 0; protected_tunnels =0; 670 namedAction:PopulateTunnelLists; 672 namedAction:RepairTunnels 674 Note: RPC "PathDependsOnLink" is used in the example for simplicity. 675 The RPC could be easily replaced by a scripted named action similar 676 to PopulateTunnelListes . 678 6. Complete Model Tree Structure 680 The complete tree structure of the YANG model defined in this 681 document is as follows: 683 module: ietf-gnca 684 +--rw gnca 685 +--rw policy-variables 686 | +--rw policy-variable* [name] 687 | +--rw name string 688 | +--rw (type-choice)? 689 | | +--:(common) 690 | | | +--rw type? identityref 691 | | +--:(xpath) 692 | | +--rw xpath? string 693 | +--rw value? 694 +--rw events 695 | +--rw event* [name] 696 | +--rw name string 697 | +--rw policy-variable? 698 | | -> /gnca/policy-variables/policy-variable/name 699 | +--rw local-policy-variable? 700 | | -> /gnca/ecas/eca/policy-variable/name 701 | +--rw (type-choice)? 702 | +--:(stream) 703 | | +--rw stream 704 | | +--rw name? string 705 | | +--rw filter* string 706 | | +--rw remote-publisher! 707 | | +--rw address? inet:ip-address-no-zone 708 | | +--rw port? inet:port-number 709 | | +--rw transport? sn:transport 710 | +--:(timer) 711 | +--rw time-schedule! 712 | +--rw start? yang:date-and-time 713 | +--rw repeat-interval? string 714 +--rw conditions 715 | +--rw condition* [name] 716 | +--rw name string 717 | +--rw (expression-choice)? 718 | +--:(logical-operation) 719 | | +--rw logical-operation-type? identityref 720 | | +--rw comparison-operation* [name] 721 | | | +--rw name string 722 | | | +--rw comparision-type? identityref 723 | | | +--rw arg1 724 | | | | +--rw policy-argument 725 | | | | +--rw type? 726 | | | | | identityref 727 | | | | +--rw (argument-choice)? 728 | | | | +--:(policy-constant) 729 | | | | | +--rw constant? string 730 | | | | +--:(policy-variable) 731 | | | | | +--rw policy-variable? 732 leafref 733 | | | | +--:(local-policy-variable) 734 | | | | | +--rw local-policy-variable? 735 leafref 736 | | | | +--:(xpath) 737 | | | | +--rw xpath? string 738 | | | +--rw arg2 739 | | | +--rw policy-argument 740 | | | +--rw type? 741 | | | | identityref 742 | | | +--rw (argument-choice)? 743 | | | +--:(policy-constant) 744 | | | | +--rw constant? string 745 | | | +--:(policy-variable) 746 | | | | +--rw policy-variable? 747 leafref 748 | | | +--:(local-policy-variable) 749 | | | | +--rw local-policy-variable? 750 leafref 751 | | | +--:(xpath) 752 | | | +--rw xpath? string 753 | | +--rw sub-condition* [name] 754 | | +--rw name -> /gnca/conditions/condition/name 755 | +--:(xpath) 756 | +--rw condition-xpath? string 757 +--rw actions 758 | +--rw action* [name] 759 | +--rw name string 760 | +--rw action-element* [name] 761 | | +--rw name string 762 | | +--rw action-type? identityref 763 | | +--rw (action-operation)? 764 | | +--:(action) 765 | | | +--rw action-name? 766 | | | -> /gnca/actions/action/name 767 | | +--:(content-moving) 768 | | | +--rw content-moving 769 | | | +--rw content-moving-type? identityref 770 | | | +--rw src 771 | | | | +--rw policy-argument 772 | | | | +--rw type? 773 | | | | | identityref 774 | | | | +--rw (argument-choice)? 775 | | | | +--:(policy-constant) 776 | | | | | +--rw constant? 777 | | | | | string 778 | | | | +--:(policy-variable) 779 | | | | | +--rw policy-variable? 780 leafref 781 | | | | +--:(local-policy-variable) 782 | | | | | +--rw local-policy-variable? 783 leafref 784 | | | | +--:(xpath) 785 | | | | +--rw xpath? 786 | | | | string 787 | | | +--rw dst 788 | | | +--rw policy-argument 789 | | | +--rw type? 790 | | | | identityref 791 | | | +--rw (argument-choice)? 792 | | | +--:(policy-constant) 793 | | | | +--rw constant? 794 | | | | string 795 | | | +--:(policy-variable) 796 | | | | +--rw policy-variable? 797 leafref 798 | | | +--:(local-policy-variable) 799 | | | | +--rw local-policy-variable? 800 leafref 801 | | | +--:(xpath) 802 | | | +--rw xpath? 803 | | | string 804 | | +--:(function-call) 805 | | | +--rw function-call 806 | | | +--rw function-type? identityref 807 | | | +--rw src 808 | | | | +--rw policy-argument 809 | | | | +--rw type? 810 | | | | | identityref 811 | | | | +--rw (argument-choice)? 812 | | | | +--:(policy-constant) 813 | | | | | +--rw constant? 814 | | | | | string 815 | | | | +--:(policy-variable) 816 | | | | | +--rw policy-variable? 817 leafref 818 | | | | +--:(local-policy-variable) 819 | | | | | +--rw local-policy-variable? 820 leafref 821 | | | | +--:(xpath) 822 | | | | +--rw xpath? 823 | | | | string 824 | | | +--rw dst 825 | | | +--rw policy-argument 826 | | | +--rw type? 827 | | | | identityref 828 | | | +--rw (argument-choice)? 829 | | | +--:(policy-constant) 830 | | | | +--rw constant? 831 | | | | string 832 | | | +--:(policy-variable) 833 | | | | +--rw policy-variable? 834 leafref 835 | | | +--:(local-policy-variable) 836 | | | | +--rw local-policy-variable? 837 leafref 838 | | | +--:(xpath) 839 | | | +--rw xpath? 840 | | | string 841 | | +--:(rpc-operation) 842 | | | +--rw rpc-operation 843 | | | +--rw name? string 844 | | | +--rw nc-action-xpath? string 845 | | | +--rw policy-variable* [name] 846 | | | +--rw name string 847 | | | +--rw policy-argument 848 | | | +--rw type? 849 | | | | identityref 850 | | | +--rw (argument-choice)? 851 | | | +--:(policy-constant) 852 | | | | +--rw constant? 853 | | | | string 854 | | | +--:(policy-variable) 855 | | | | +--rw policy-variable? 856 leafref 857 | | | +--:(local-policy-variable) 858 | | | | +--rw local-policy-variable? 859 leafref 860 | | | +--:(xpath) 861 | | | +--rw xpath? 862 | | | string 863 | | +--:(notify-operation) 864 | | +--rw notify-operation 865 | | +--rw name? string 866 | | +--rw policy-variable* [name] 867 | | +--rw name string 868 | | +--rw policy-argument 869 | | +--rw type? 870 | | | identityref 871 | | +--rw (argument-choice)? 872 | | +--:(policy-constant) 873 | | | +--rw constant? 874 | | | string 875 | | +--:(policy-variable) 876 | | | +--rw policy-variable? 877 leafref 878 | | +--:(local-policy-variable) 879 | | | +--rw local-policy-variable? 880 leafref 881 | | +--:(xpath) 882 | | +--rw xpath? 883 | | string 884 | +--rw time-schedule! 885 | +--rw start? yang:date-and-time 886 | +--rw repeat-interval? string 887 +--rw ecas 888 | +--rw eca* [name] 889 | +--rw name string 890 | +--rw event-name string 891 | +--rw policy-variable* [name] 892 | | +--rw name string 893 | | +--rw (type-choice)? 894 | | | +--:(common) 895 | | | | +--rw type? identityref 896 | | | +--:(xpath) 897 | | | +--rw xpath? string 898 | | +--rw value? 899 | | +--rw is-static? boolean 900 | +--rw condition-action* [name] 901 | | +--rw name string 902 | | +--rw condition? -> /gnca/conditions/condition/name 903 | | +--rw action? -> /gnca/actions/action/name 904 | +--rw cleanup-condition-action* [name] 905 | | +--rw name string 906 | | +--rw condition? -> /gnca/conditions/condition/name 907 | | +--rw action? -> /gnca/actions/action/name 908 | +---x start 909 | +---x stop 910 | +---x pause 911 | +---x resume 912 | +---x next-action 913 | +--ro execution* [id] 914 | +--ro id uint32 915 | +--ro oper-status? oper-status 916 | +--ro start-time? 917 | | yang:date-and-time 918 | +--ro stop-time? 919 | | yang:date-and-time 920 | +--ro next-scheduled-time? 921 | | yang:date-and-time 922 | +--ro last-condition-action? 923 | | -> ../../condition-action/name 924 | +--ro last-condition? 925 | | -> ../../condition-action/condition 926 | +--ro last-action? 927 | | -> ../../condition-action/action 928 | +--ro last-cleanup-condition-action? 929 | -> ../../cleanup-condition-action/name 930 +--rw eca-scripts 931 | +--rw eca-script* [script-name] 932 | +--rw script-name string 933 | +--rw eca* [eca-name] 934 | +--rw eca-name -> /gnca/ecas/eca/name 935 +--rw running-script? 936 -> /gnca/eca-scripts/eca-script/script-name 938 notifications: 939 +---n eca-execution 940 +--ro oper-status oper-status 941 +--ro name string 942 +--ro policy-variable* [name] 943 +--ro name string 944 +--ro policy-argument 945 | +--ro type? identityref 946 | +--ro (argument-choice)? 947 | +--:(policy-constant) 948 | | +--ro constant? string 949 | +--:(policy-variable) 950 | | +--ro policy-variable? leafref 951 | +--:(local-policy-variable) 952 | | +--ro local-policy-variable? 953 | | -> /gnca/ecas/eca/policy-variable/name 954 | +--:(xpath) 955 | +--ro xpath? string 956 +--ro value? 958 7. YANG Module 960 file "ietf-gnca@2018-06-22.yang" 961 module ietf-gnca { 962 yang-version 1.1; 963 namespace "urn:ietf:params:xml:ns:yang:ietf-gnca"; 965 prefix "gnca"; 967 import ietf-yang-types { 968 prefix "yang"; 969 } 971 import ietf-inet-types { 972 prefix "inet"; 973 } 975 import ietf-subscribed-notifications { 976 prefix "sn"; 977 } 979 organization 980 "IETF Network Configuration (NETCONF) Working Group"; 982 contact 983 "WG Web: 984 WG List: 986 Editor: Igor Bryskin 987 989 Editor: Xufeng Liu 990 992 Editor: Alexander Clemm 993 "; 995 description 996 "Event Condition Action (ECA) model."; 998 revision 2018-06-22 { 999 description "Initial revision"; 1000 reference "RFC XXXX"; 1001 } 1003 /* 1004 * Typedefs 1005 */ 1006 identity argument-type { 1007 description 1008 "Possible values are: 1009 constant, variable, or datastore state."; 1010 } 1012 identity comparison-type { 1013 description 1014 "Possible values are: 1015 equal, not-equal, greater, greater-equal, less, less-equal."; 1017 } 1019 identity logical-operation-type { 1020 description 1021 "Possible values are: 1022 not, or, and."; 1023 } 1025 identity function-type { 1026 description 1027 "Possible values are: 1028 plus, minus, mult, divide, remain."; 1029 } 1031 identity content-moving-operation-type { 1032 description 1033 "Possible values are: 1034 copy, iterate, insert."; 1035 } 1037 identity action-type { 1038 description 1039 "Possible values are: 1040 action, content-move, function-call, rpc, notify."; 1041 } 1043 identity policy-variable-type { 1044 description 1045 "Possible values are: 1046 boolean, int32, int64, uint32, uint64, string, etc."; 1047 } 1049 /* 1050 * Typedefs 1051 */ 1052 typedef oper-status { 1053 type enumeration { 1054 enum completed { 1055 description "Completed with no error."; 1056 } 1057 enum running { 1058 description "Currently with no error."; 1059 } 1060 enum sleeping { 1061 description "Sleeping because of time schedule."; 1062 } 1063 enum paused { 1064 description "Paused by the operator."; 1066 } 1067 enum stoped { 1068 description "Stopped by the operator."; 1069 } 1070 enum failed { 1071 description "Failed with errors."; 1072 } 1073 enum error-handling { 1074 description 1075 "Asking the operator to handle an error."; 1076 } 1077 } 1078 description 1079 "The operational status of an ECA execution."; 1080 } 1082 /* 1083 * Groupings 1084 */ 1085 grouping policy-variable-attributes { 1086 description 1087 "Defining the policy variable attributes, including name, type 1088 and value. These attributes are used as part of the Policy 1089 Variable (PV) definition."; 1090 leaf name { 1091 type string; 1092 description 1093 "A string to uniquely identify a Policy Variable (PV), either 1094 globally for a global PV, or within the soope of ECA for a 1095 local PV."; 1096 } 1097 choice type-choice { 1098 description 1099 "The type of a policy variable may be either a common 1100 primative type like boolean or a type from existing 1101 schema node referenced by an XPath string."; 1102 case common { 1103 leaf type { 1104 type identityref { 1105 base policy-variable-type; 1106 } 1107 description 1108 "A common policy variable type, defined as an 1109 identity."; 1110 } 1111 } 1112 case xpath { 1113 leaf xpath { 1114 type string; 1115 description 1116 "A XPath string, referencing a schema node, whose 1117 type is used as the type of the policy variable."; 1118 } 1119 } 1120 } 1121 anydata value { 1122 description 1123 "The value of the policy variable, in a format that is 1124 determined by the policy type."; 1125 } 1126 } // policy-variable-attributes 1128 grouping policy-argument { 1129 description 1130 "Defining a policy argument, which can be used in a comparison 1131 or an action."; 1132 container policy-argument { 1133 description 1134 "Containing the attributes of a policy argument."; 1135 leaf type { 1136 type identityref { 1137 base argument-type; 1138 } 1139 description 1140 "Identifies the argument type."; 1141 } 1142 choice argument-choice { 1143 description 1144 "Argument formation options, depending on the policy 1145 type."; 1146 case policy-constant { 1147 leaf constant { 1148 type string; 1149 description 1150 "The constant value of the policy argument."; 1151 } 1152 } 1153 case policy-variable { 1154 leaf policy-variable { 1155 type leafref { 1156 path "/gnca/policy-variables/" 1157 + "policy-variable/name"; 1158 } 1159 description 1160 "A reference to a global policy variable, which 1161 is shared by all ECA scripts."; 1163 } 1164 } 1165 case local-policy-variable { 1166 leaf local-policy-variable { 1167 type leafref { 1168 path "/gnca/ecas/eca/policy-variable/name"; 1169 } 1170 description 1171 "A reference to a local policy variable, which 1172 is kept within an ECA instance, and appears/ 1173 disappears with start/stop of the ECA execution."; 1174 } 1175 } 1176 case xpath { 1177 leaf xpath { 1178 type string; 1179 description 1180 "An XPath string, referencing the data in the 1181 datastore."; 1182 } 1183 } 1184 } 1185 } 1186 } // policy-argument 1188 grouping action-element-attributes { 1189 description 1190 "Grouping of action element attributes."; 1191 leaf action-type { 1192 type identityref { 1193 base action-type; 1194 } 1195 description 1196 "Identifies the action type."; 1197 } 1198 choice action-operation { 1199 description 1200 "The operation choices that an ECA Action can take."; 1201 case action { 1202 leaf action-name { 1203 type leafref { 1204 path "/gnca/actions/action/name"; 1205 } 1206 description 1207 "The operation is to execute a configured ECA Action."; 1208 } 1209 } // action 1210 case content-moving { 1211 container content-moving { 1212 description 1213 "The operation is to move contents between two policy 1214 arguments."; 1215 leaf content-moving-type { 1216 type identityref { 1217 base content-moving-operation-type; 1218 } 1219 description 1220 "The type of moving operation, which can be copy, 1221 iterate (copy a list of elements one by one), or 1222 insert."; 1223 } 1224 container src { 1225 description 1226 "The source policy argment."; 1227 uses policy-argument; 1228 } 1229 container dst { 1230 description 1231 "The destination policy argument."; 1232 uses policy-argument; 1233 } 1234 } 1235 } // content-moving 1236 case function-call { 1237 container function-call { 1238 description 1239 "The operation is to call a function, which is of one of 1240 a few basic predefined types, such as plus, minus, 1241 multiply, devide, or remainder."; 1242 leaf function-type { 1243 type identityref { 1244 base function-type; 1245 } 1246 description 1247 "One of the predefined basic function types, such as 1248 plus, minus, multiply, devide, or remainder."; 1249 } 1250 container src { 1251 description 1252 "The source policy argument."; 1253 uses policy-argument; 1254 } 1255 container dst { 1256 description 1257 "The distination policy argument."; 1258 uses policy-argument; 1260 } 1261 } 1262 } // function-call 1263 case rpc-operation { 1264 container rpc-operation { 1265 description 1266 "The operation is to call an RPC, which is defined by 1267 a YANG module supported by the server."; 1268 leaf name { 1269 type string; 1270 description 1271 "The name of the YANG RPC or YANG action to be 1272 called."; 1273 } 1274 leaf nc-action-xpath { 1275 type string; 1276 description 1277 "The location where the YANG action is defined. 1278 This is used if and only if a YANG action is called. 1279 This leaf is not set when a YANG RPC is called."; 1280 } 1281 list policy-variable { 1282 key name; 1283 description 1284 "A list of policy arguments used as the input or output 1285 parameters passed to the RPC."; 1286 leaf name { 1287 type string; 1288 description 1289 "A string name used as the list key to form a list 1290 of policy arguments."; 1291 } 1292 uses policy-argument; 1293 } 1294 } 1295 } // rpc-operation 1296 case notify-operation { 1297 container notify-operation { 1298 description 1299 "The operation is to send a YANG notification."; 1300 leaf name { 1301 type string; 1302 description 1303 "Name of the subscribed YANG notification."; 1304 } 1305 list policy-variable { 1306 key name; 1307 description 1308 "A list of policy arguments carried in the notification 1309 message."; 1310 leaf name { 1311 type string; 1312 description 1313 "A string name used as the list key to form a list 1314 of policy arguments."; 1315 } 1316 uses policy-argument; 1317 } 1318 } 1319 } // notify-operation 1320 } 1321 } // action-element-attributes 1323 grouping time-schedule-container { 1324 description 1325 "Grouping to define a container of a time schedule."; 1326 container time-schedule { 1327 presence 1328 "Presence indicates that the timer is enabled."; 1329 description 1330 "Specifying the time schedule to execute an ECA Action, or 1331 trigger an event."; 1332 leaf start { 1333 type yang:date-and-time; 1334 description 1335 "The start time of the ECA Action, or the specified event. 1336 If not specified, the ECA Action is executed 1337 immediately when it is called, or the event is triggered 1338 immediately."; 1339 } 1340 leaf repeat-interval { 1341 type string { 1342 pattern 1343 '(R\d*/)?P(\d+Y)?(\d+M)?(\d+W)?(\d+D)?T(\d+H)?' 1344 + '(\d+M)?(\d+S)?'; 1345 } 1346 description 1347 "The repeat interval to execute this ECA Action, or to 1348 trigger the event. 1349 The repeat interval is a string in ISO 8601 format, 1350 representing a delay duration or a repeated delay 1351 duration. 1352 If not specified, the ECA Action or the evetn trigger 1353 is executed without delay and without repetition."; 1354 } 1355 } // time-schedule 1357 } 1359 /* 1360 * Data nodes 1361 */ 1362 container gnca { 1363 description 1364 "Top level container for Generalized Network Control Automation 1365 (GNCA)."; 1367 // policy-variables 1368 container policy-variables { 1369 description 1370 "Container of global Policy Variables (PVs)."; 1371 list policy-variable { 1372 key name; 1373 description 1374 "A list of global Policy Variables (PVs), with a string 1375 name as the entry key."; 1376 uses policy-variable-attributes; 1377 } 1378 } // policy-variables 1380 container events { 1381 description 1382 "Container of ECA events."; 1383 list event { 1384 key name; 1385 description 1386 "A list of events used as the triggers of ECAs."; 1387 leaf name { 1388 type string; 1389 description 1390 "The name of the event."; 1391 } 1392 leaf policy-variable { 1393 type leafref { 1394 path "/gnca/policy-variables/" 1395 + "policy-variable/name"; 1396 } 1397 description 1398 "Optional association to a global policy variable, which 1399 is shared by all ECA scripts."; 1400 } 1401 leaf local-policy-variable { 1402 type leafref { 1403 path "/gnca/ecas/eca/policy-variable/name"; 1404 } 1405 description 1406 "Optional associateion to a local policy variable, which 1407 is kept within an ECA instance, and appears/ 1408 disappears with start/stop of the ECA execution."; 1409 } 1410 choice type-choice { 1411 description 1412 "The type of an event, including subscribed stream."; 1413 case stream { 1414 container stream { 1415 description 1416 "The information of the subscribed stream."; 1417 leaf name { 1418 type string; 1419 description 1420 "The name of a stream subscribed and reported in 1421 the model 1422 ietf-subscribed-notifications."; 1423 } 1424 leaf-list filter { 1425 type string; 1426 description 1427 "A list of filters to be applied to the subscribed 1428 stream."; 1429 } 1430 container remote-publisher { 1431 presence 1432 "The presence indicates the publisher is remote. 1433 Otherwise, the publisher is the local system."; 1434 description 1435 "If the subscribed stream is from a remote server, 1436 this container specifies the information of the 1437 remote server."; 1438 leaf address { 1439 type inet:ip-address-no-zone; 1440 description 1441 "IP address of the remote publisher."; 1442 } 1443 leaf port { 1444 type inet:port-number; 1445 description 1446 "The port number on the publisher for a 1447 subscription request RPC."; 1448 } 1449 leaf transport { 1450 type sn:transport; 1451 description 1452 "The transport used between this system and 1453 remote publisher."; 1454 } 1455 } 1456 } 1457 } 1458 case timer { 1459 uses time-schedule-container { 1460 description 1461 "Specifying the time schedule to trigger the event. 1462 If not specified, the event is not triggered."; 1463 } 1464 } 1465 } 1466 } 1467 } 1469 container conditions { 1470 description 1471 "Container of ECA Conditions."; 1472 list condition { 1473 key name; 1474 description 1475 "A list of ECA Conditions."; 1476 leaf name { 1477 type string; 1478 description 1479 "A string name to uniquely identify an ECA Condition 1480 globally."; 1481 } 1482 choice expression-choice { 1483 description 1484 "The choices of expression format to specify a condition, 1485 which can be either a XPath string or a YANG logical 1486 operation structure."; 1487 case logical-operation { 1488 leaf logical-operation-type { 1489 type identityref { 1490 base logical-operation-type; 1491 } 1492 description 1493 "The logical operation type used to combine the 1494 results from the list comparison-operation and the 1495 list sub-condition, defined below."; 1496 } 1497 list comparison-operation { 1498 key name; 1499 description 1500 "A list of comparison oprations, each of them defines 1501 a comparison in the form of , 1502 where and are policy arguments, while 1503 is the comparison-type, which can be 1504 ==, !=, >, <, >=, <="; 1505 leaf name { 1506 type string; 1507 description 1508 "A string name to uniquely identify a comparison 1509 operation."; 1510 } 1511 leaf comparision-type { 1512 type identityref { 1513 base comparison-type; 1514 } 1515 description 1516 "The comparison operation applied to the two 1517 arguments arg1 and arg2 defined blow."; 1518 } 1519 container arg1 { 1520 description 1521 "The policy argument used as the first parameter of 1522 the comparison opration. 1523 A policy argument represents either a constant, PV 1524 or data store value pointed by XPath."; 1525 uses policy-argument; 1526 } 1527 container arg2 { 1528 description 1529 "The policy argument used as the secone parameter 1530 of the comparison opration. 1531 A policy argument represents either a constant, PV 1532 or data store value pointed by XPath."; 1533 uses policy-argument; 1534 } 1535 } 1536 list sub-condition { 1537 key name; 1538 description 1539 "A list of sub conditions applied by the 1540 logical-operation-type. This list of sub conditions 1541 provides the capability of hierarchically combining 1542 conditions."; 1543 leaf name { 1544 type leafref { 1545 path "/gnca/conditions/condition/name"; 1546 } 1547 description 1548 "A reference to a defined condition, which is used 1549 as a sub-condition for the logical operation at 1550 this hierarchy level."; 1551 } 1552 } // sub-condition 1553 } // logical-operation 1554 case xpath { 1555 leaf condition-xpath { 1556 type string; 1557 description 1558 "A XPath string, representing a logical expression, 1559 which can contain comparisons of datastore values 1560 and logical operations in the XPath format."; 1561 } 1562 } // xpath 1563 } // expression-choice 1564 } // condition 1565 } // conditions 1567 container actions { 1568 description 1569 "Container of ECA Actions."; 1570 list action { 1571 key name; 1572 description 1573 "A list of ECA Actions."; 1574 leaf name { 1575 type string; 1576 description 1577 "A string name to uniquely identify an ECA Action 1578 globally."; 1579 } 1581 list action-element { 1582 key name; 1583 description 1584 "A list of elements contained in an ECA Action. "; 1585 leaf name { 1586 type string; 1587 description 1588 "A string name to uniquely identify the action element 1589 within the scope of an ECA action."; 1590 } 1591 uses action-element-attributes; 1592 } 1594 uses time-schedule-container { 1595 description 1596 "Specifying the time schedule to execute this ECA 1597 Action. 1598 If not specified, the ECA Action is executed immediately 1599 when it is called."; 1600 } 1601 } 1602 } // actions 1604 container ecas { 1605 description 1606 "Container of ECAs."; 1607 list eca { 1608 key name; 1609 description 1610 "A lis of ECAs"; 1611 leaf name { 1612 type string; 1613 description 1614 "A string name to uniquely identify an ECA globally."; 1615 } 1616 leaf event-name { 1617 type string; 1618 mandatory true; 1619 description 1620 "The name of an event that triggers the execution of 1621 this ECA."; 1622 } 1624 list policy-variable { 1625 key name; 1626 description 1627 "A list of ECA local Policy Variables (PVs), with a 1628 string name as the entry key."; 1629 uses policy-variable-attributes; 1630 leaf is-static { 1631 type boolean; 1632 description 1633 "'true' if the PV is static; 'false' if the PV is 1634 dynamic. 1635 A dynamic PV appears/disappears with the start/stop 1636 of the ECA execution; a static PV exists as long as 1637 the ECA is configured."; 1638 } 1639 } 1641 list condition-action { 1642 key name; 1643 description 1644 "A list of Condition-Actions, which are configured 1645 conditions each with associated actions to be executed 1646 if the condition is evaluated to TRUE"; 1647 leaf name { 1648 type string; 1649 description 1650 "A string name uniquely identify a Condition-Action 1651 within this ECA."; 1652 } 1653 leaf condition { 1654 type leafref { 1655 path "/gnca/conditions/condition/name"; 1656 } 1657 description 1658 "The reference to a configured condition."; 1659 } 1660 leaf action { 1661 type leafref { 1662 path "/gnca/actions/action/name"; 1663 } 1664 description 1665 "The reference to a configured action."; 1666 } 1667 } // condition-action 1669 list cleanup-condition-action { 1670 key name; 1671 description 1672 "A list of Condition-Actions, which are configured 1673 conditions each with associated actions to be executed 1674 if the condition is evaluated to TRUE. 1675 This is the exception handler of this ECA, and is 1676 evaluated and executed in case any Action from the 1677 normal Condition-Action list was attempted and rejected 1678 by the server."; 1679 leaf name { 1680 type string; 1681 description 1682 "A string name uniquely identify a Condition-Action 1683 within this ECA."; 1684 } 1685 leaf condition { 1686 type leafref { 1687 path "/gnca/conditions/condition/name"; 1688 } 1689 description 1690 "The reference to a configured condition."; 1691 } 1692 leaf action { 1693 type leafref { 1694 path "/gnca/actions/action/name"; 1695 } 1696 description 1697 "The reference to a configured action."; 1698 } 1699 } // cleanup-condition-action 1701 action start { 1702 description 1703 "Start to execute this ECA."; 1704 } 1705 action stop { 1706 description 1707 "Stop the execution of this ECA."; 1708 } 1709 action pause { 1710 description 1711 "Pause the execution of this ECA."; 1712 } 1713 action resume { 1714 description 1715 "Resume the execution of this ECA."; 1716 } 1717 action next-action { 1718 description 1719 "Resume the execution of this ECA to complete the next 1720 action."; 1721 } 1722 list execution { 1723 key id; 1724 config false; 1725 description 1726 "A list of executions that this ECA has completed, 1727 are currently running, and will start in the scheduled 1728 future."; 1729 leaf id { 1730 type uint32; 1731 description 1732 "The ID to uniquely identify an execution of the ECA."; 1733 } 1734 leaf oper-status { 1735 type oper-status; 1736 description 1737 "The running status of the execution."; 1738 } 1739 leaf start-time { 1740 type yang:date-and-time; 1741 description 1742 "The time when the ECA started."; 1743 } 1744 leaf stop-time { 1745 type yang:date-and-time; 1746 description 1747 "The time when the ECA completed or stopped."; 1748 } 1749 leaf next-scheduled-time { 1750 type yang:date-and-time; 1751 description 1752 "The next time when the ECA is scheduled to resume."; 1753 } 1754 leaf last-condition-action { 1755 type leafref { 1756 path "../../condition-action/name"; 1757 } 1758 description 1759 "The reference to a condition-action last executed 1760 or being executed."; 1761 } 1762 leaf last-condition { 1763 type leafref { 1764 path "../../condition-action/condition"; 1765 } 1766 description 1767 "The reference to a condition last executed or being 1768 executed."; 1769 } 1770 leaf last-action { 1771 type leafref { 1772 path "../../condition-action/action"; 1773 } 1774 description 1775 "The reference to aa action last executed or being 1776 executed."; 1777 } 1778 leaf last-cleanup-condition-action { 1779 type leafref { 1780 path "../../cleanup-condition-action/name"; 1781 } 1782 description 1783 "The reference to a cleanup-condition-action last 1784 executed or being executed."; 1785 } 1786 } 1787 } 1788 } // ecas 1789 container eca-scripts { 1790 description 1791 "Container of ECA Scripts."; 1792 list eca-script { 1793 key script-name; 1794 description 1795 "A list of ECA Script."; 1796 leaf script-name { 1797 type string; 1798 description 1799 "A string name to uniquely identify an ECA Script."; 1800 } 1801 list eca { 1802 key eca-name; 1803 description 1804 "A list of ECAs contained in this ECA Script."; 1805 leaf eca-name { 1806 type leafref { 1807 path "/gnca/ecas/eca/name"; 1808 } 1809 description 1810 "The reference to a configured ECA."; 1811 } 1812 } 1813 } 1814 } // eca-scripts 1816 leaf running-script { 1817 type leafref { 1818 path "/gnca/eca-scripts/eca-script/script-name"; 1819 } 1820 description 1821 "The reference to the ECA script that is currently running."; 1822 } 1823 } 1825 /* 1826 * NOTIFICATIONS 1827 */ 1829 notification eca-execution { 1830 description 1831 "This notification is to send the result of an ECA execution 1832 that is specified to use notify-operation."; 1833 leaf oper-status { 1834 type oper-status; 1835 mandatory true; 1836 description 1837 "The running status of the execution."; 1838 } 1839 leaf name { 1840 type string; 1841 mandatory true; 1842 description 1843 "Name of the subscribed YANG notification."; 1844 } 1845 list policy-variable { 1846 key name; 1847 description 1848 "A list of policy arguments carried in the notification 1849 message."; 1850 leaf name { 1851 type string; 1852 description 1853 "A string name used as the list key to form a list 1854 of policy arguments."; 1855 } 1856 uses policy-argument; 1857 anydata value { 1858 description 1859 "The value of the policy variable, in a format that is 1860 determined by the policy type."; 1861 } 1862 } 1863 } 1864 } 1865 1867 8. IANA Considerations 1869 TBD. 1871 9. Security Considerations 1873 TBD. 1875 10. Acknowledgements 1877 The authors would like to thank Joel Halpern and Robert Wilton for 1878 their helpful comments and valuable contributions. 1880 11. References 1882 11.1. Normative References 1884 [I-D.clemm-netconf-push-smart-filters-ps] 1885 Clemm, A., Voit, E., Liu, X., Bryskin, I., Zhou, T., 1886 Zheng, G., and H. Birkholz, "Smart filters for Push 1887 Updates - Problem Statement", draft-clemm-netconf-push- 1888 smart-filters-ps-00 (work in progress), October 2017. 1890 [I-D.ietf-teas-yang-te-topo] 1891 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1892 O. Dios, "YANG Data Model for Traffic Engineering (TE) 1893 Topologies", draft-ietf-teas-yang-te-topo-16 (work in 1894 progress), June 2018. 1896 11.2. Informative References 1898 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1899 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1900 . 1902 [I-D.ietf-netconf-subscribed-notifications] 1903 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 1904 A. Tripathy, "Customized Subscriptions to a Publisher's 1905 Event Streams", draft-ietf-netconf-subscribed- 1906 notifications-12 (work in progress), April 2018. 1908 [I-D.ietf-netconf-yang-push] 1909 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 1910 Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore 1911 Subscription", draft-ietf-netconf-yang-push-16 (work in 1912 progress), May 2018. 1914 Authors' Addresses 1916 Igor Bryskin 1917 Huawei Technologies 1919 EMail: Igor.Bryskin@huawei.com 1921 Xufeng Liu 1922 Volta Networks 1924 EMail: xufeng.liu.ietf@gmail.com 1925 Alexander Clemm 1926 Huawei 1928 EMail: ludwig@clemm.org 1930 Henk Birkholz 1931 Fraunhofer SIT 1933 EMail: henk.birkholz@sit.fraunhofer.de 1935 Tianran Zhou 1936 Huawei 1938 EMail: zhoutianran@huawei.com