idnits 2.17.1 draft-claise-opsawg-service-assurance-yang-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 77 instances of too long lines in the document, the longest one being 27 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 161 has weird spacing: '...-change yan...' == Line 615 has weird spacing: '...-change yan...' == Line 770 has weird spacing: '...-change yan...' == Line 917 has weird spacing: '...-change yan...' -- The document date (January 2, 2021) is 1203 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG B. Claise 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track J. Quilbeuf 5 Expires: July 6, 2021 Independent 6 P. Lucente 7 NTT 8 P. Fasano 9 TIM S.p.A 10 T. Arumugam 11 Cisco Systems, Inc. 12 January 2, 2021 14 YANG Modules for Service Assurance 15 draft-claise-opsawg-service-assurance-yang-06 17 Abstract 19 This document proposes YANG modules for the Service Assurance for 20 Intent-based Networking Architecture. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 6, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. YANG Models Overview . . . . . . . . . . . . . . . . . . . . 3 59 4. Base ietf-service-assurance YANG module . . . . . . . . . . . 4 60 4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. Subservice Extension: ietf-service-assurance-device YANG 64 module . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 13 66 5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 13 67 5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 14 68 5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 15 69 6. Subservice Extension: ietf-service-assurance-interface YANG 70 module . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 16 72 6.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 17 73 6.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 18 74 6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 18 75 7. Vendor-specific Subservice Extension: example-service- 76 assurance-device-acme YANG module . . . . . . . . . . . . . . 19 77 7.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 19 78 7.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 20 79 7.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 21 80 7.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 22 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 83 9.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 24 84 9.2. The YANG Module Names Registry . . . . . . . . . . . . . 25 85 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 25 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 88 11.2. Informative References . . . . . . . . . . . . . . . . . 26 89 Appendix A. Changes between revisions . . . . . . . . . . . . . 26 90 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 93 1. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in BCP 98 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 The terms used in this document are defined in draft-claise-opsawg- 102 service-assurance-architecture IETF draft. 104 2. Introduction 106 The "Service Assurance for Intent-based Networking Architecture" 107 draft-claise-opsawg-service-assurance-architecture, specifies the 108 framework and all of its components for service assurance. This 109 document complements the architecture by providing open interfaces 110 between components. More specifically, the goal is to provide YANG 111 modules for the purpose of service assurance in a format that is: 113 o machine readable 115 o vendor independent 117 o augmentable 119 3. YANG Models Overview 121 The main YANG module, ietf-service-assurance, defines objects for 122 assuring network services based on their decomposition into so-called 123 subservices. The subservices are hierarchically organised by 124 dependencies. The subservices, along with the dependencies, 125 constitute an assurance graph. This module should be supported by an 126 agent, able to interact with the devices in order to produce a health 127 status and symptoms for each subservice in the assurance graph. This 128 module is intended for the following use cases: 130 o Assurance graph configuration: 132 * Subservices: configure a set of subservices to assure, by 133 specifying their types and parameters. 135 * Dependencies: configure the dependencies between the 136 subservices, along with their type. 138 o Assurance telemetry: export the health status of the subservices, 139 along with the observed symptoms. 141 The second YANG module, ietf-service-assurance-device, extends the 142 ietf-service-assurance module to add support for the subservice 143 DeviceHealthy. Additional subservice types might be added the same 144 way. 146 The third YANG module, example-service-assurance-device-acme, extends 147 the ietf-service-assurance-device module as an example to add support 148 for the subservice DeviceHealthy, with specifics for the fictional 149 ACME Corporation. Additional vendor-specific parameters might be 150 added the same way. 152 4. Base ietf-service-assurance YANG module 154 4.1. Tree View 156 The following tree diagram [RFC8340] provides an overview of the 157 ietf-service-assurance data model. 159 module: ietf-service-assurance 160 +--ro assurance-graph-version yang:counter32 161 +--ro assurance-graph-last-change yang:date-and-time 162 +--rw subservices 163 +--rw subservice* [type id] 164 +--rw type identityref 165 +--rw id string 166 +--ro last-change? yang:date-and-time 167 +--ro label? string 168 +--rw under-maintenance? boolean 169 +--rw maintenance-contact string 170 +--rw (parameter)? 171 | +--:(service-instance-parameter) 172 | +--rw service-instance-parameter 173 | +--rw service? string 174 | +--rw instance-name? string 175 +--ro health-score? uint8 176 +--ro symptoms-history-start? yang:date-and-time 177 +--rw symptoms 178 | +--ro symptom* [start-date-time id] 179 | +--ro id string 180 | +--ro health-score-weight? uint8 181 | +--ro description? string 182 | +--ro start-date-time yang:date-and-time 183 | +--ro stop-date-time? yang:date-and-time 184 +--rw dependencies 185 +--rw dependency* [type id] 186 +--rw type -> /subservices/subservice/type 187 +--rw id -> /subservices/subservice[type=current()/../type]/id 188 +--rw dependency-type? identityref 190 4.2. Concepts 192 The ietf-service-assurance YANG model assumes an identified number of 193 subservices, to be assured independently. A subservice is a feature 194 or a subpart of the network system that a given service instance 195 might depend on. Example of subservices include: 197 o DeviceHealthy: whether a device is healthy, and if not, what are 198 the symptoms. Potential symptoms are "CPU overloaded", "Out of 199 RAM", or "Out of TCAM". 201 o ConnectivityHealthy: given two IP addresses owned by two devices, 202 what is the quality of the connection between them. Potential 203 symptoms are "No route available" or "ECMP Imbalance". 205 The first example is a subservice representing a subpart of the 206 network system, while the second is a subservice representing a 207 feature of the network, In both cases, these subservices might depend 208 on other subservices, for instance, the connectivity might depend on 209 a subservice representing the routing mechanism and on a subservice 210 representing ECMP. 212 The symptoms are listed for each subservice. Each symptom is 213 specified by a unique id and contains a health-score-weight (the 214 impact to the health score incurred by this symptom), a label (text 215 describing what the symptom is), and dates and times at which the 216 symptom was detected and stopped being detected. While the unique id 217 is sufficient as an unique key list, the start-date-time second key 218 help sorting and retrieving relevant symptoms. 220 The assurance of a given service instance can be obtained by 221 composing the assurance of the subservices that it depends on, via 222 the dependency relations. 224 In order to declare a subservice MUST provide: 226 o A type: identity inheriting of the base identity for subservice, 228 o An id: string uniquely identifying the subservice among those with 229 the same identity, 231 o Some parameters, which should be specified in an augmenting model, 232 as described in the next sections. 234 The type and id uniquely identify a given subservice. They are used 235 to indicate the dependencies. Dependencies have types as well. Two 236 types are specified in the model: 238 o Impacting: such a dependency indicates an impact on the health of 239 the dependent, 241 o Informational: such a dependency might explain why the dependent 242 has issues but does not impact its health. 244 To illustrate the difference between "impacting" and "informational", 245 consider the subservice InterfaceHealthy, representing a network 246 interface. If the device to which the network interface belongs goes 247 down, the network interface will transition to a down state as well. 248 Therefore, the dependency of InterfaceHealthy towards DeviceHealthy 249 is "impacting". On the other hand, as a the dependency towards the 250 ECMPLoad subservice, which checks that the load between ECMP remains 251 ce remains stable throughout time, is only "informational". Indeed, 252 services might be perfectly healthy even if the load distribution 253 between ECMP changed. However, such an instability might be a 254 relevant symptom for diagnosing the root cause of a problem. 256 Service instances MUST be modeled as a particular type of subservice 257 with two parameters, a type and an instance name. The type is the 258 name of the service defined in the network orchestrator, for instance 259 "point-to-point-l2vpn". The instance name is the name assigned to 260 the particular instance that we are assuring, for instance the name 261 of the customer using that instance. 263 The "under-maintenance" and "maintenance-contact" flags inhibit the 264 emission of symptoms for that subservice and subservices that depend 265 on them. See Section 3.7 of 266 [draft-claise-opsawg-service-assurance-architecture] for a more 267 detailed discussion. 269 By specifying service instances and their dependencies in terms of 270 subservices, one defines the whole assurance to apply for them. An 271 assurance agent supporting this model should then produce telemetry 272 in return with, for each subservice: a health-status indicating how 273 healthy the subservice is and when the subservice is not healthy, a 274 list of symptoms explaining why the subservice is not healthy. 276 4.3. YANG Module 278 file "ietf-service-assurance@2020-01-13.yang" 280 module ietf-service-assurance { 281 yang-version 1.1; 282 namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance"; 283 prefix service-assurance; 285 import ietf-yang-types { 286 prefix yang; 287 } 289 organization 290 "IETF NETCONF (Network Configuration) Working Group"; 291 contact 292 "WG Web: 293 WG List: 294 Author: Benoit Claise 295 Author: Jean Quilbeuf "; 296 description 297 "This module defines objects for assuring network services based on 298 their decomposition into so-called subservices, according to the SAIN 299 (Service Assurance for Intent-based Networking) architecture. 301 The subservices hierarchically organised by dependencies constitute an 302 assurance graph. This module should be supported by an assurance agent, 303 able to interact with the devices in order to produce a health status 304 and symptoms for each subservice in the assurance graph. 306 This module is intended for the following use cases: 307 * Assurance graph configuration: 308 * subservices: configure a set of subservices to assure, by specifying 309 their types and parameters. 310 * dependencies: configure the dependencies between the subservices, 311 along with their type. 312 * Assurance telemetry: export the health status of the subservices, along 313 with the observed symptoms. 315 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 316 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 317 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 318 are to be interpreted as described in BCP 14 (RFC 2119) 319 (RFC 8174) when, and only when, they appear in all 320 capitals, as shown here. 322 Copyright (c)2020 IETF Trust and the persons identified as 323 authors of the code. All rights reserved. 325 Redistribution and use in source and binary forms, with or 326 without modification, is permitted pursuant to, and subject 327 to the license terms contained in, the Simplified BSD License 328 set forth in Section 4.c of the IETF Trust's Legal Provisions 329 Relating to IETF Documents 330 (https://trustee.ietf.org/license-info). 332 This version of this YANG module is part of RFC XXXX; see the 333 RFC itself for full legal notices. 335 TO DO: 336 - Better type (IETF or OC) for device-id, interface-id, etc. 337 - Have a YANG module for IETF and one for OC?"; 339 revision 2020-01-13 { 340 description 341 "Added the maintenance window concept."; 342 reference 343 "RFC xxxx: Title to be completed"; 344 } 346 revision 2019-11-16 { 347 description 348 "Initial revision."; 349 reference 350 "RFC xxxx: Title to be completed"; 351 } 353 identity subservice-idty { 354 description 355 "Root identity for all subservice types."; 356 } 358 identity service-instance-idty { 359 base subservice-idty; 360 description 361 "Identity representing a service instance."; 362 } 364 identity dependency-type { 365 description 366 "Base identity for representing dependency types."; 367 } 369 identity informational-dependency { 370 base dependency-type; 371 description 372 "Indicates that symptoms of the dependency might be of interest for the 373 dependent, but the status of the dependency should not have any 374 impact on the dependent."; 375 } 377 identity impacting-dependency { 378 base dependency-type; 379 description 380 "Indicates that the status of the dependency directly impacts the status 381 of the dependent."; 382 } 383 grouping symptom { 384 description 385 "Contains the list of symptoms for a specific subservice."; 386 leaf id { 387 type string; 388 description 389 "A unique identifier for the symptom."; 390 } 391 leaf health-score-weight { 392 type uint8 { 393 range "0 .. 100"; 394 } 395 description 396 "The weight to the health score incurred by this symptom. The higher the 397 value, the more of an impact this symptom has. If a subservice health 398 score is not 100, there must be at least one symptom with a health 399 score weight larger than 0."; 400 } 401 leaf description { 402 type string; 403 description 404 "Description of the symptom, i.e. text describing what the symptom is, to 405 be computer-consumable and be displayed on a human interface. "; 406 } 407 leaf start-date-time { 408 type yang:date-and-time; 409 description 410 "Date and time at which the symptom was detected."; 411 } 412 leaf stop-date-time { 413 type yang:date-and-time; 414 description 415 "Date and time at which the symptom stopped being detected."; 416 } 417 } 419 grouping subservice-dependency { 420 description 421 "Represent a dependency to another subservice."; 422 leaf type { 423 type leafref { 424 path "/subservices/subservice/type"; 425 } 426 description 427 "The type of the subservice to refer to (e.g. DeviceHealthy)."; 428 } 429 leaf id { 430 type leafref { 431 path "/subservices/subservice[type=current()/../type]/id"; 432 } 433 description 434 "The identifier of the subservice to refer to."; 435 } 436 leaf dependency-type { 437 type identityref { 438 base dependency-type; 439 } 440 description 441 "Represents the type of dependency (i.e. informational, impacting)."; 442 } 443 // augment here if more info are needed (i.e. a percentage) depending on the dependency type. 444 } 446 leaf assurance-graph-version { 447 type yang:counter32; 448 mandatory true; 449 config false; 450 description 451 "The assurance graph version, which increases by 1 for each new version, after the changes 452 (dependencies and/or maintenance windows parameters) are applied to the subservice(s)."; 453 } 454 leaf assurance-graph-last-change { 455 type yang:date-and-time; 456 mandatory true; 457 config false; 458 description 459 "Date and time at which the assurance graph last changed after the changes (dependencies 460 and/or maintenance windows parameters) are applied to the subservice(s). These date and time 461 must be more recent or equal compared to the more recent value of any changed subservices 462 last-change"; 463 } 464 container subservices { 465 description 466 "Root container for the subservices."; 467 list subservice { 468 key "type id"; 469 description 470 "List of subservice configured."; 471 leaf type { 472 type identityref { 473 base subservice-idty; 474 } 475 description 476 "Name of the subservice, e.g. DeviceHealthy."; 477 } 478 leaf id { 479 type string; 480 description 481 "Unique identifier of the subservice instance, for each type."; 482 } 483 leaf last-change { 484 type yang:date-and-time; 485 config false; 486 description 487 "Date and time at which the assurance graph for this subservice 488 instance last changed, i.e. dependencies and/or maintenance windows parameters."; 489 } 490 leaf label { 491 type string; 492 config false; 493 description 494 "Label of the subservice, i.e. text describing what the subservice is to 495 be displayed on a human interface."; 496 } 497 leaf under-maintenance { 498 type boolean; 499 default false; 500 description 501 "An optional flag indicating whether this particular subservice is under 502 maintenance. Under this circumstance, the subservice symptoms and the 503 symptoms of its dependencies in the assurance graph should not be taken 504 into account. Instead, the subservice should send a 'Under Maintenance' 505 single symptom. 507 The operator changing the under-maintenance value must set the 508 maintenance-contact variable. 510 When the subservice is not under maintenance any longer, the 511 under-maintenance flag must return to its default value and 512 the under-maintenance-owner variable deleted."; 513 } 514 leaf maintenance-contact { 515 when "../under-maintenance = 'true'"; 516 type string; 517 mandatory true; 518 description 519 "A string used to model an administratively assigned name of the 520 resource that changed the under-maintenance value to 'true. 522 It is suggested that this name contain one or more of the following: 523 IP address, management station name, network manager's name, location, 524 or phone number. In some cases the agent itself will be the owner of 525 an entry. In these cases, this string shall be set to a string 526 starting with 'monitor'."; 528 } 529 choice parameter { 530 description 531 "Specify the required parameters per subservice type."; 532 container service-instance-parameter { 533 when "derived-from-or-self(../type, 'service-assurance:service-instance-idty')"; 534 description 535 "Specify the parameters of a service instance."; 536 leaf service { 537 type string; 538 description "Name of the service."; 539 } 540 leaf instance-name{ 541 type string; 542 description "Name of the instance for that service."; 543 } 544 } 545 // Other modules can augment their own cases into here 546 } 547 leaf health-score { 548 type uint8 { 549 range "0 .. 100"; 550 } 551 config false; 552 description 553 "Score value of the subservice health. A value of 100 means that 554 subservice is healthy. A value of 0 means that the subservice is 555 broken. A value between 0 and 100 means that the subservice is 556 degraded."; 557 } 558 leaf symptoms-history-start { 559 type yang:date-and-time; 560 config false; 561 description 562 "Date and time at which the symptoms history starts for this 563 subservice instance, either because the subservice instance 564 started at that date and time or because the symptoms before that 565 were removed due to a garbage collection process."; 566 } 567 container symptoms { 568 description 569 "Symptoms for the subservice."; 570 list symptom { 571 key "start-date-time id"; 572 config false; 573 description 574 "List of symptoms the subservice. While the start-date-time key is not 575 necessary per se, this would get the entries sorted by start-date-time 576 for easy consumption."; 577 uses symptom; 578 } 579 } 580 container dependencies { 581 description 582 "configure the dependencies between the subservices, along with their types."; 583 list dependency { 584 key "type id"; 585 description 586 "List of soft dependencies of the subservice."; 587 uses subservice-dependency; 588 } 589 } 590 } 591 } 592 } 594 596 5. Subservice Extension: ietf-service-assurance-device YANG module 598 5.1. Tree View 600 The following tree diagram [RFC8340] provides an overview of the 601 ietf-service-assurance-device data model. 603 module: ietf-service-assurance-device 604 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: 605 +--rw device-idty 606 +--rw device? string 608 5.2. Complete Tree View 610 The following tree diagram [RFC8340] provides an overview of the 611 ietf-service-assurance and ietf-service-assurance-device data models. 613 module: ietf-service-assurance 614 +--ro assurance-graph-version yang:counter32 615 +--ro assurance-graph-last-change yang:date-and-time 616 +--rw subservices 617 +--rw subservice* [type id] 618 +--rw type identityref 619 +--rw id string 620 +--ro last-change? yang:date-and-time 621 +--ro label? string 622 +--rw under-maintenance? boolean 623 +--rw maintenance-contact string 624 +--rw (parameter)? 625 | +--:(service-instance-parameter) 626 | | +--rw service-instance-parameter 627 | | +--rw service? string 628 | | +--rw instance-name? string 629 | +--:(service-assurance-device:device-idty) 630 | +--rw service-assurance-device:device-idty 631 | +--rw service-assurance-device:device? string 632 +--ro health-score? uint8 633 +--ro symptoms-history-start? yang:date-and-time 634 +--rw symptoms 635 | +--ro symptom* [start-date-time id] 636 | +--ro id string 637 | +--ro health-score-weight? uint8 638 | +--ro description? string 639 | +--ro start-date-time yang:date-and-time 640 | +--ro stop-date-time? yang:date-and-time 641 +--rw dependencies 642 +--rw dependency* [type id] 643 +--rw type -> /subservices/subservice/type 644 +--rw id -> /subservices/subservice[type=current()/../type]/id 645 +--rw dependency-type? identityref 647 5.3. Concepts 649 As the number of subservices will grow over time, the YANG module is 650 designed to be extensible. A new subservice type requires the 651 precise specifications of its type and expected parameters. Let us 652 illustrate the example of the new DeviceHealthy subservice type. As 653 the name implies, it monitors and reports the device health, along 654 with some symptoms in case of degradation. 656 For our DeviceHealthy subservice definition, the new device-idty is 657 specified, as an inheritance from the base identity for subservices. 658 This indicates to the assurance agent that we are now assuring the 659 health of a device. 661 The typical parameter for the configuration of the DeviceHealthy 662 subservice is the name of the device that we want to assure. By 663 augmenting the parameter choice from ietf-service-assurance YANG 664 module for the case of the device-idty subservice type, this new 665 parameter is specified. 667 5.4. YANG Module 669 file "ietf-service-assurance-device@2020-01-13.yang" 671 module ietf-service-assurance-device { 672 yang-version 1.1; 673 namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device"; 674 prefix service-assurance-device; 676 import ietf-service-assurance { 677 prefix "service-assurance"; 678 } 680 organization 681 "IETF NETCONF (Network Configuration) Working Group"; 682 contact 683 "WG Web: 684 WG List: 685 Author: Benoit Claise 686 Author: Jean Quilbeuf "; 687 description 688 "This module extends the ietf-service-assurance module to add 689 support for the subservice DeviceHealthy. 691 Checks whether a network device is healthy. 693 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 694 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 695 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 696 are to be interpreted as described in BCP 14 (RFC 2119) 697 (RFC 8174) when, and only when, they appear in all 698 capitals, as shown here. 700 Copyright (c) 2020 IETF Trust and the persons identified as 701 authors of the code. All rights reserved. 703 Redistribution and use in source and binary forms, with or 704 without modification, is permitted pursuant to, and subject 705 to the license terms contained in, the Simplified BSD License 706 set forth in Section 4.c of the IETF Trust's Legal Provisions 707 Relating to IETF Documents 708 (https://trustee.ietf.org/license-info). 710 This version of this YANG module is part of RFC XXXX; see the 711 RFC itself for full legal notices. "; 713 revision 2020-01-13 { 714 description 715 "Added the maintenance window concept."; 716 reference 717 "RFC xxxx: Title to be completed"; 718 } 720 revision 2019-11-16 { 721 description 722 "Initial revision."; 723 reference 724 "RFC xxxx: Title to be completed"; 725 } 727 identity device-idty { 728 base service-assurance:subservice-idty; 729 description "Network Device is healthy."; 730 } 732 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter { 733 description 734 "Specify the required parameters for a new subservice type"; 735 container device-idty{ 736 when "derived-from-or-self(../service-assurance:type, 'device-idty')"; 737 description 738 "Specify the required parameters for the device-idty subservice type"; 740 leaf device { 741 type string; 742 description "The device to monitor."; 743 } 744 } 745 } 746 } 748 750 6. Subservice Extension: ietf-service-assurance-interface YANG module 752 6.1. Tree View 754 The following tree diagram [RFC8340] provides an overview of the 755 ietf-service-assurance-interface data model. 757 module: ietf-service-assurance-interface 758 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: 759 +--rw device? string 760 +--rw interface? string 762 6.2. Complete Tree View 764 The following tree diagram [RFC8340] provides an overview of the 765 ietf-service-assurance, ietf-service-assurance-device, and ietf- 766 service-assurance-interface data models. 768 module: ietf-service-assurance 769 +--ro assurance-graph-version yang:counter32 770 +--ro assurance-graph-last-change yang:date-and-time 771 +--rw subservices 772 +--rw subservice* [type id] 773 +--rw type identityref 774 +--rw id string 775 +--ro last-change? yang:date-and-time 776 +--ro label? string 777 +--rw under-maintenance? boolean 778 +--rw maintenance-contact string 779 +--rw (parameter)? 780 | +--:(service-instance-parameter) 781 | | +--rw service-instance-parameter 782 | | +--rw service? string 783 | | +--rw instance-name? string 784 | +--:(service-assurance-device:device-idty) 785 | | +--rw service-assurance-device:device-idty 786 | | +--rw service-assurance-device:device? string 787 | +--:(service-assurance-interface:device) 788 | | +--rw service-assurance-interface:device? string 789 | +--:(service-assurance-interface:interface) 790 | +--rw service-assurance-interface:interface? string 791 +--ro health-score? uint8 792 +--ro symptoms-history-start? yang:date-and-time 793 +--rw symptoms 794 | +--ro symptom* [start-date-time id] 795 | +--ro id string 796 | +--ro health-score-weight? uint8 797 | +--ro description? string 798 | +--ro start-date-time yang:date-and-time 799 | +--ro stop-date-time? yang:date-and-time 800 +--rw dependencies 801 +--rw dependency* [type id] 802 +--rw type -> /subservices/subservice/type 803 +--rw id -> /subservices/subservice[type=current()/../type]/id 804 +--rw dependency-type? identityref 806 6.3. Concepts 808 For our InterafaceHealthy subservice definition, the new interface- 809 idty is specified, as an inheritance from the base identity for 810 subservices. This indicates to the assurance agent that we are now 811 assuring the health of an interface. 813 The typical parameters for the configuration of the InterfaceHealthy 814 subservice are the name of the device and, on that specific device, a 815 specific interface. By augmenting the parameter choice from ietf- 816 service-assurance YANG module for the case of the interface-idty 817 subservice type, those two new parameter are specified. 819 6.4. YANG Module 821 file "ietf-service-assurance-interface@2020-01-13.yang" 823 module ietf-service-assurance-interface { 824 yang-version 1.1; 825 namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface"; 826 prefix service-assurance-interface; 828 import ietf-service-assurance { 829 prefix "service-assurance"; 830 } 832 organization 833 "IETF OPSAWG Working Group"; 834 contact 835 "WG Web: 836 WG List: 837 Author: Benoit Claise 838 Author: Jean Quilbeuf "; 839 description 840 "This module extends the ietf-service-assurance module to add 841 support for the subservice InterfaceHealthy. 843 Checks whether an interface is healthy. 845 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 846 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 847 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 848 are to be interpreted as described in BCP 14 (RFC 2119) 849 (RFC 8174) when, and only when, they appear in all 850 capitals, as shown here. 852 Copyright (c) 2020 IETF Trust and the persons identified as 853 authors of the code. All rights reserved. 855 Redistribution and use in source and binary forms, with or 856 without modification, is permitted pursuant to, and subject 857 to the license terms contained in, the Simplified BSD License 858 set forth in Section 4.c of the IETF Trust's Legal Provisions 859 Relating to IETF Documents 860 (https://trustee.ietf.org/license-info). 862 This version of this YANG module is part of RFC XXXX; see the 863 RFC itself for full legal notices. "; 865 revision 2020-01-13 { 866 description 867 "Initial revision."; 868 reference 869 "RFC xxxx: Title to be completed"; 870 } 872 identity interface-idty { 873 base service-assurance:subservice-idty; 874 description "Checks whether an interface is healthy."; 875 } 877 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter { 878 when "derived-from-or-self(service-assurance:type, 'interface-idty')"; 879 description 880 "Specify the required parameters for the interface-idty subservice type"; 882 leaf device { 883 type string; 884 description "Device supporting the interface."; 885 } 886 leaf interface { 887 type string; 888 description "Name of the interface."; 889 } 890 } 891 } 893 895 7. Vendor-specific Subservice Extension: example-service-assurance- 896 device-acme YANG module 898 7.1. Tree View 900 The following tree diagram [RFC8340] provides an overview of the 901 example-service-assurance-device-acme data model. 903 module: example-service-assurance-device-acme 904 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: 905 +--rw acme-device-idty 906 +--rw device? string 907 +--rw acme-specific-parameter? string 909 7.2. Complete Tree View 911 The following tree diagram [RFC8340] provides an overview of the 912 ietf-service-assurance, ietf-service-assurance-device, and example- 913 service-assurance-device-acme data models. 915 module: ietf-service-assurance 916 +--ro assurance-graph-version yang:counter32 917 +--ro assurance-graph-last-change yang:date-and-time 918 +--rw subservices 919 +--rw subservice* [type id] 920 +--rw type identityref 921 +--rw id string 922 +--ro last-change? yang:date-and-time 923 +--ro label? string 924 +--rw under-maintenance? boolean 925 +--rw maintenance-contact string 926 +--rw (parameter)? 927 | +--:(service-instance-parameter) 928 | | +--rw service-instance-parameter 929 | | +--rw service? string 930 | | +--rw instance-name? string 931 | +--:(service-assurance-device:device-idty) 932 | | +--rw service-assurance-device:device-idty 933 | | +--rw service-assurance-device:device? string 934 | +--:(service-assurance-interface:device) 935 | | +--rw service-assurance-interface:device? string 936 | +--:(service-assurance-interface:interface) 937 | | +--rw service-assurance-interface:interface? string 938 | +--:(example-service-assurance-device-acme:acme-device-idty) 939 | +--rw example-service-assurance-device-acme:acme-device-idty 940 | +--rw example-service-assurance-device-acme:device? string 941 | +--rw example-service-assurance-device-acme:acme-specific-parameter? string 942 +--ro health-score? uint8 943 +--ro symptoms-history-start? yang:date-and-time 944 +--rw symptoms 945 | +--ro symptom* [start-date-time id] 946 | +--ro id string 947 | +--ro health-score-weight? uint8 948 | +--ro description? string 949 | +--ro start-date-time yang:date-and-time 950 | +--ro stop-date-time? yang:date-and-time 951 +--rw dependencies 952 +--rw dependency* [type id] 953 +--rw type -> /subservices/subservice/type 954 +--rw id -> /subservices/subservice[type=current()/../type]/id 955 +--rw dependency-type? identityref 957 7.3. Concepts 959 Under some circumstances, vendor-specific subservice types might be 960 required. As an example of this vendor-specific implementation, this 961 section shows how to augment the ietf-service-assurance-device module 962 to add support for the subservice DeviceHealthy, specific to the ACME 963 Corporation. The new parameter is acme-specific-parameter. 965 7.4. YANG Module 967 module example-service-assurance-device-acme { 968 yang-version 1.1; 969 namespace "urn:example:example-service-assurance-device-acme"; 970 prefix example-service-assurance-device-acme; 972 import ietf-service-assurance { 973 prefix "service-assurance"; 974 } 976 import ietf-service-assurance-device { 977 prefix "service-assurance-device"; 978 } 980 organization 981 "IETF NETCONF (Network Configuration) Working Group"; 982 contact 983 "WG Web: 984 WG List: 985 Author: Benoit Claise 986 Author: Jean Quilbeuf "; 987 description 988 "This module extends the ietf-service-assurance-device module to add 989 support for the subservice DeviceHealthy, specific to the ACME Corporation. 991 ACME Network Device is healthy. 993 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 994 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 995 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 996 are to be interpreted as described in BCP 14 (RFC 2119) 997 (RFC 8174) when, and only when, they appear in all 998 capitals, as shown here. 1000 Copyright (c) 2019 IETF Trust and the persons identified as 1001 authors of the code. All rights reserved. 1003 Redistribution and use in source and binary forms, with or 1004 without modification, is permitted pursuant to, and subject 1005 to the license terms contained in, the Simplified BSD License 1006 set forth in Section 4.c of the IETF Trust's Legal Provisions 1007 Relating to IETF Documents 1008 (https://trustee.ietf.org/license-info). 1010 This version of this YANG module is part of RFC XXXX; see the 1011 RFC itself for full legal notices. "; 1013 revision 2020-01-13 { 1014 description 1015 "Added the maintenance window concept."; 1016 reference 1017 "RFC xxxx: Title to be completed"; 1018 } 1020 revision 2019-11-16 { 1021 description 1022 "Initial revision."; 1023 reference 1024 "RFC xxxx: Title to be completed"; 1025 } 1027 identity device-acme-idty { 1028 base service-assurance-device:device-idty; 1029 description "Network Device is healthy."; 1030 } 1032 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter { 1033 description 1034 "Specify the required parameters for a new subservice type"; 1035 container acme-device-idty{ 1036 when "derived-from-or-self(../service-assurance:type, 'device-acme-idty')"; 1037 description 1038 "Specify the required parameters for the device-acme-idty subservice type"; 1040 leaf device { 1041 type string; 1042 description "The device to monitor."; 1043 } 1045 leaf acme-specific-parameter { 1046 type string; 1047 description "The ACME Corporation sepcific parameter."; 1048 } 1049 } 1050 } 1051 } 1053 8. Security Considerations 1055 The YANG module specified in this document defines a schema for data 1056 that is designed to be accessed via network management protocols such 1057 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1058 is the secure transport layer, and the mandatory-to-implement secure 1059 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1060 is HTTPS, and the mandatory-to-implement secure transport is TLS 1061 [RFC8446]. 1063 The Network Configuration Access Control Model (NACM) [RFC8341] 1064 provides the means to restrict access for particular NETCONF or 1065 RESTCONF users to a preconfigured subset of all available NETCONF or 1066 RESTCONF protocol operations and content. 1068 There are a number of data nodes defined in this YANG module that are 1069 writable/ creatable/deletable (i.e., config true, which is the 1070 default). These data nodes may be considered sensitive or vulnerable 1071 in some network environments. Write operations (e.g., edit-config) 1072 to these data nodes without proper protection can have a negative 1073 effect on network operations. These are the subtrees and data nodes 1074 and their sensitivity/vulnerability: 1076 o /subservices/subservice/type 1078 o /subservices/subservice/id 1080 o /subservices/subservice/under-maintenance 1082 o /subservices/subservice/maintenance-contact 1084 9. IANA Considerations 1086 9.1. The IETF XML Registry 1088 This document registers two URIs in the IETF XML registry [RFC3688]. 1089 Following the format in [RFC3688], the following registrations are 1090 requested: 1092 URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance 1093 Registrant Contact: The NETCONF WG of the IETF. 1094 XML: N/A, the requested URI is an XML namespace. 1096 URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device 1097 Registrant Contact: The NETCONF WG of the IETF. 1098 XML: N/A, the requested URI is an XML namespace. 1100 URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface 1101 Registrant Contact: The NETCONF WG of the IETF. 1102 XML: N/A, the requested URI is an XML namespace. 1104 9.2. The YANG Module Names Registry 1106 This document registers three YANG modules in the YANG Module Names 1107 registry [RFC7950]. Following the format in [RFC7950], the the 1108 following registrations are requested: 1110 name: ietf-service-assurance 1111 namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance 1112 prefix: inc 1113 reference: RFC XXXX 1115 name: ietf-service-assurance-device 1116 namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device 1117 prefix: inc 1118 reference: RFC XXXX 1120 name: ietf-service-assurance-interface 1121 namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface 1122 prefix: inc 1123 reference: RFC XXXX 1125 10. Open Issues 1127 -None 1129 11. References 1131 11.1. Normative References 1133 [draft-claise-opsawg-service-assurance-architecture] 1134 Claise, B. and J. Quilbeuf, "draft-claise-opsawg-service- 1135 assurance-architecture", 2020. 1137 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1138 and A. Bierman, Ed., "Network Configuration Protocol 1139 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1140 . 1142 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1143 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1144 . 1146 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1147 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1148 . 1150 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1151 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1152 . 1154 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1155 Access Control Model", STD 91, RFC 8341, 1156 DOI 10.17487/RFC8341, March 2018, 1157 . 1159 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1160 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1161 . 1163 11.2. Informative References 1165 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1166 Requirement Levels", BCP 14, RFC 2119, 1167 DOI 10.17487/RFC2119, March 1997, 1168 . 1170 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1171 DOI 10.17487/RFC3688, January 2004, 1172 . 1174 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1175 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1176 May 2017, . 1178 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1179 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1180 . 1182 Appendix A. Changes between revisions 1184 v04 - v05 1186 o Added the concept of symptoms-history-start 1188 o Changed label to description, under symptoms. This was confusing 1189 as there was two labels in the models 1191 v03 - v04 1193 o Add the interface subservice, with two parameters 1195 v02 - v03 1197 o Added the maintenace window concepts 1198 v01 - v02 1200 o Improved leaf naming 1202 o Clarified some concepts: symptoms, dependency 1204 v00 - v01 1206 o Terminology clarifications 1208 o Provide example of impacting versus impacted dependencies 1210 Acknowledgements 1212 The authors would like to thank Jan Lindblad for his help during the 1213 design of these YANG modules. The authors would like to thank 1214 Stephane Litkowski and Charles Eckel for their reviews. 1216 Authors' Addresses 1218 Benoit Claise 1219 Cisco Systems, Inc. 1220 De Kleetlaan 6a b1 1221 1831 Diegem 1222 Belgium 1224 Email: bclaise@cisco.com 1226 Jean Quilbeuf 1227 Independent 1229 Email: jean@quilbeuf.net 1231 Paolo Lucente 1232 NTT 1233 Siriusdreef 70-72 1234 Hoofddorp, WT 2132 1235 Netherlands 1237 Email: paolo@ntt.net 1238 Paolo Fasano 1239 TIM S.p.A 1240 via G. Reiss Romoli, 274 1241 10148 Torino 1242 Italy 1244 Email: paolo2.fasano@telecomitalia.it 1246 Thangam Arumugam 1247 Cisco Systems, Inc. 1248 Milpitas (California) 1249 United States 1251 Email: tarumuga@cisco.com