idnits 2.17.1 draft-claise-opsawg-service-assurance-yang-04.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 64 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 -- The document date (February 19, 2020) is 1525 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 (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG B. Claise 3 Internet-Draft J. Quilbeuf 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: August 22, 2020 P. Lucente 6 NTT 7 P. Fasano 8 TIM S.p.A 9 February 19, 2020 11 YANG Modules for Service Assurance 12 draft-claise-opsawg-service-assurance-yang-04 14 Abstract 16 This document proposes YANG modules for the Service Assurance for 17 Intent-based Networking Architecture. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 22, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. YANG Models Overview . . . . . . . . . . . . . . . . . . . . 3 56 4. Base ietf-service-assurance YANG module . . . . . . . . . . . 4 57 4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Subservice Extension: ietf-service-assurance-device YANG 61 module . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 62 5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 13 63 5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 13 64 5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 14 65 5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 15 66 6. Subservice Extension: ietf-service-assurance-interface YANG 67 module . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 68 6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 16 69 6.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 17 70 6.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 18 71 6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 18 72 7. Vendor-specific Subservice Extension: example-service- 73 assurance-device-acme YANG module . . . . . . . . . . . . . . 19 74 7.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 19 75 7.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 20 76 7.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 21 77 7.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 21 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 80 9.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 23 81 9.2. The YANG Module Names Registry . . . . . . . . . . . . . 23 82 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 24 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 85 11.2. Informative References . . . . . . . . . . . . . . . . . 24 86 Appendix A. Changes between revisions . . . . . . . . . . . . . 25 87 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 90 1. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in BCP 95 14 [RFC2119] [RFC8174] when, and only when, they appear in all 96 capitals, as shown here. 98 The terms used in this document are defined in draft-claise-opsawg- 99 service-assurance-architecture IETF draft. 101 2. Introduction 103 The "Service Assurance for Intent-based Networking Architecture" 104 draft-claise-opsawg-service-assurance-architecture, specifies the 105 framework and all of its components for service assurance. This 106 document complements the architecture by providing open interfaces 107 between components. More specifically, the goal is to provide YANG 108 modules for the purpose of service assurance in a format that is: 110 o machine readable 112 o vendor independent 114 o augmentable 116 3. YANG Models Overview 118 The main YANG module, ietf-service-assurance, defines objects for 119 assuring network services based on their decomposition into so-called 120 subservices. The subservices are hierarchically organised by 121 dependencies. The subservices, along with the dependencies, 122 constitute an assurance graph. This module should be supported by an 123 agent, able to interact with the devices in order to produce a health 124 status and symptoms for each subservice in the assurance graph. This 125 module is intended for the following use cases: 127 o Assurance graph configuration: 129 * Subservices: configure a set of subservices to assure, by 130 specifying their types and parameters. 132 * Dependencies: configure the dependencies between the 133 subservices, along with their type. 135 o Assurance telemetry: export the health status of the subservices, 136 along with the observed symptoms. 138 The second YANG module, ietf-service-assurance-device, extends the 139 ietf-service-assurance module to add support for the subservice 140 DeviceHealthy. Additional subservice types might be added the same 141 way. 143 The third YANG module, example-service-assurance-device-acme, extends 144 the ietf-service-assurance-device module as an example to add support 145 for the subservice DeviceHealthy, with specifics for the fictional 146 ACME Corporation. Additional vendor-specific parameters might be 147 added the same way. 149 4. Base ietf-service-assurance YANG module 151 4.1. Tree View 153 The following tree diagram [RFC8340] provides an overview of the 154 ietf-service-assurance data model. 156 module: ietf-service-assurance 157 +--ro assurance-graph-version? yang:counter32 158 +--ro assurance-graph-last-change? yang:date-and-time 159 +--rw subservices 160 +--rw subservice* [type id] 161 +--rw type identityref 162 +--rw id string 163 +--ro last-change? yang:date-and-time 164 +--ro label? string 165 +--rw under-maintenance? boolean 166 +--rw maintenance-contact string 167 +--rw (parameter)? 168 | +--:(service-instance-parameter) 169 | +--rw service-instance-parameter 170 | +--rw service? string 171 | +--rw instance-name? string 172 +--ro health-score? uint8 173 +--rw symptoms 174 | +--ro symptom* [start-date-time id] 175 | +--ro id string 176 | +--ro health-score-weight? uint8 177 | +--ro label? string 178 | +--ro start-date-time yang:date-and-time 179 | +--ro stop-date-time? yang:date-and-time 180 +--rw dependencies 181 +--rw dependency* [type id] 182 +--rw type -> /subservices/subservice/type 183 +--rw id -> /subservices/subservice[type=current()/../type]/id 184 +--rw dependency-type? identityref 186 4.2. Concepts 188 The ietf-service-assurance YANG model assumes an identified number of 189 subservices, to be assured independently. A subservice is a feature 190 or a subpart of the network system that a given service instance 191 might depend on. Example of subservices include: 193 o DeviceHealthy: whether a device is healthy, and if not, what are 194 the symptoms. Potential symptoms are "CPU overloaded", "Out of 195 RAM", or "Out of TCAM". 197 o ConnectivityHealthy: given two IP addresses owned by two devices, 198 what is the quality of the connection between them. Potential 199 symptoms are "No route available" or "ECMP Imbalance". 201 The first example is a subservice representing a subpart of the 202 network system, while the second is a subservice representing a 203 feature of the network, In both cases, these subservices might depend 204 on other subservices, for instance, the connectivity might depend on 205 a subservice representing the routing mechanism and on a subservice 206 representing ECMP. 208 The symptoms are listed for each subservice. Each symptom is 209 specified by a unique id and contains a health-score-weight (the 210 impact to the health score incurred by this symptom), a label (text 211 describing what the symptom is), and dates and times at which the 212 symptom was detected and stopped being detected. While the unique id 213 is sufficient as an unique key list, the start-date-time second key 214 help sorting and retrieving relevant symptoms. 216 The assurance of a given service instance can be obtained by 217 composing the assurance of the subservices that it depends on, via 218 the dependency relations. 220 In order to declare a subservice MUST provide: 222 o A type: identity inheriting of the base identity for subservice, 224 o An id: string uniquely identifying the subservice among those with 225 the same identity, 227 o Some parameters, which should be specified in an augmenting model, 228 as described in the next sections. 230 The type and id uniquely identify a given subservice. They are used 231 to indicate the dependencies. Dependencies have types as well. Two 232 types are specified in the model: 234 o Impacting: such a dependency indicates an impact on the health of 235 the dependent, 237 o Informational: such a dependency might explain why the dependent 238 has issues but does not impact its health. 240 To illustrate the difference between "impacting" and "informational", 241 consider the subservice InterfaceHealthy, representing a network 242 interface. If the device to which the network interface belongs goes 243 down, the network interface will transition to a down state as well. 244 Therefore, the dependency of InterfaceHealthy towards DeviceHealthy 245 is "impacting". On the other hand, as a the dependency towards the 246 ECMPLoad subservice, which checks that the load between ECMP remains 247 ce remains stable throughout time, is only "informational". Indeed, 248 services might be perfectly healthy even if the load distribution 249 between ECMP changed. However, such an instability might be a 250 relevant symptom for diagnosing the root cause of a problem. 252 Service instances MUST be modeled as a particular type of subservice 253 with two parameters, a type and an instance name. The type is the 254 name of the service defined in the network orchestrator, for instance 255 "point-to-point-l2vpn". The instance name is the name assigned to 256 the particular instance that we are assuring, for instance the name 257 of the customer using that instance. 259 The "under-maintenance" and "maintenance-contact" flags inhibit the 260 emission of symptoms for that subservice and subservices that depend 261 on them. See Section 3.7 of 262 [draft-claise-opsawg-service-assurance-architecture] for a more 263 detailed discussion. 265 By specifying service instances and their dependencies in terms of 266 subservices, one defines the whole assurance to apply for them. An 267 assurance agent supporting this model should then produce telemetry 268 in return with, for each subservice: a health-status indicating how 269 healthy the subservice is and when the subservice is not healthy, a 270 list of symptoms explaining why the subservice is not healthy. 272 4.3. YANG Module 274 file "ietf-service-assurance@2020-01-13.yang" 276 module ietf-service-assurance { 277 yang-version 1.1; 278 namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance"; 279 prefix service-assurance; 281 import ietf-yang-types { 282 prefix yang; 283 } 284 organization 285 "IETF NETCONF (Network Configuration) Working Group"; 286 contact 287 "WG Web: 288 WG List: 289 Author: Benoit Claise 290 Author: Jean Quilbeuf "; 291 description 292 "This module defines objects for assuring network services based on 293 their decomposition into so-called subservices, according to the SAIN 294 (Service Assurance for Intent-based Networking) architecture. 296 The subservices hierarchically organised by dependencies constitute an 297 assurance graph. This module should be supported by an assurance agent, 298 able to interact with the devices in order to produce a health status 299 and symptoms for each subservice in the assurance graph. 301 This module is intended for the following use cases: 302 * Assurance graph configuration: 303 * subservices: configure a set of subservices to assure, by specifying 304 their types and parameters. 305 * dependencies: configure the dependencies between the subservices, 306 along with their type. 307 * Assurance telemetry: export the health status of the subservices, along 308 with the observed symptoms. 310 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 311 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 312 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 313 are to be interpreted as described in BCP 14 (RFC 2119) 314 (RFC 8174) when, and only when, they appear in all 315 capitals, as shown here. 317 Copyright (c) 2019 IETF Trust and the persons identified as 318 authors of the code. All rights reserved. 320 Redistribution and use in source and binary forms, with or 321 without modification, is permitted pursuant to, and subject 322 to the license terms contained in, the Simplified BSD License 323 set forth in Section 4.c of the IETF Trust's Legal Provisions 324 Relating to IETF Documents 325 (https://trustee.ietf.org/license-info). 327 This version of this YANG module is part of RFC XXXX; see the 328 RFC itself for full legal notices."; 330 revision 2020-01-13 { 331 description 332 "Added the maintenance window concept."; 333 reference 334 "RFC xxxx: Title to be completed"; 335 } 337 revision 2019-11-16 { 338 description 339 "Initial revision."; 340 reference 341 "RFC xxxx: Title to be completed"; 342 } 344 identity subservice-idty { 345 description 346 "Root identity for all subservice types."; 347 } 349 identity service-instance-idty { 350 base subservice-idty; 351 description 352 "Identity representing a service instance."; 353 } 355 identity dependency-type { 356 description 357 "Base identity for representing dependency types."; 358 } 360 identity informational-dependency { 361 base dependency-type; 362 description 363 "Indicates that symptoms of the dependency might be of interest for the 364 dependent, but the status of the dependency should not have any 365 impact on the dependent."; 366 } 368 identity impacting-dependency { 369 base dependency-type; 370 description 371 "Indicates that the status of the dependency directly impacts the status 372 of the dependent."; 373 } 375 grouping symptom { 376 description 377 "Contains the list of symptoms for a specific subservice."; 378 leaf id { 379 type string; 380 description 381 "A unique identifier for the symptom."; 382 } 383 leaf health-score-weight { 384 type uint8 { 385 range "0 .. 100"; 386 } 387 description 388 "The weight to the health score incurred by this symptom. The higher the 389 value, the more of an impact this symptom has. If a subservice health 390 score is not 100, there must be at least one symptom with a health 391 score weight larger than 0."; 392 } 393 leaf label { 394 type string; 395 description 396 "Label of the symptom, i.e. text describing what the symptom is, to 397 be used in a graphical user interfaces. "; 398 } 399 leaf start-date-time { 400 type yang:date-and-time; 401 description 402 "Date and time at which the symptom was detected."; 403 } 404 leaf stop-date-time { 405 type yang:date-and-time; 406 description 407 "Date and time at which the symptom stopped being detected."; 408 } 409 } 411 grouping subservice-dependency { 412 description 413 "Represent a dependency to another subservice."; 414 leaf type { 415 type leafref { 416 path "/subservices/subservice/type"; 417 } 418 description 419 "The type of the subservice to refer to (e.g. DeviceHealthy)."; 420 } 421 leaf id { 422 type leafref { 423 path "/subservices/subservice[type=current()/../type]/id"; 424 } 425 description 426 "The identifier of the subservice to refer to."; 427 } 428 leaf dependency-type { 429 type identityref { 430 base dependency-type; 431 } 432 description 433 "Represents the type of dependency (i.e. informational, impacting)."; 434 } 435 // augment here if more info are needed (i.e. a percentage) depending on the dependency type. 436 } 438 leaf assurance-graph-version { 439 type yang:counter32; 440 config false; 441 description 442 "The assurance graph version, which increases by 1 for each new version."; 443 } 444 leaf assurance-graph-last-change { 445 type yang:date-and-time; 446 config false; 447 description 448 "Date and time at which the assurance graph last changed."; 449 } 450 container subservices { 451 description 452 "Root container for the subservices."; 453 list subservice { 454 key "type id"; 455 description 456 "List of subservice configured."; 457 leaf type { 458 type identityref { 459 base subservice-idty; 460 } 461 description 462 "Name of the subservice, e.g. DeviceHealthy."; 463 } 464 leaf id { 465 type string; 466 description 467 "Unique identifier of the subservice instance, for each type."; 468 } 469 leaf last-change { 470 type yang:date-and-time; 471 config false; 472 description 473 "Date and time at which the assurance graph for this subservice 474 instance last changed."; 475 } 476 leaf label { 477 type string; 478 config false; 479 description 480 "Label of the symptom, i.e. text describing what the symptom is, to 481 be computer-consumable and be displayed on a human interface."; 482 } 483 leaf under-maintenance { 484 type boolean; 485 default false; 486 description 487 "An optional flag indicating whether this particular subservice is under 488 maintenance. Under this circumstance, the subservice symptoms and the 489 symptoms of its dependencies in the assurance graph should not be taken 490 into account. Instead, the subservice should send a 'Under Maintenance' 491 single symptom. 493 The operator changing the under-maintenance value must set the 494 maintenance-contact variable. 496 When the subservice is not under maintenance any longer, the 497 under-maintenance flag must return to its default value and 498 the under-maintenance-owner variable deleted."; 499 } 500 leaf maintenance-contact { 501 when "../under-maintenance"; 502 type string; 503 mandatory true; 504 description 505 "A string used to model an administratively assigned name of the 506 resource that changed the under-maintenance value to 'true. 508 It is suggested that this name contain one or more of the following: 509 IP address, management station name, network manager's name, location, 510 or phone number. In some cases the agent itself will be the owner of 511 an entry. In these cases, this string shall be set to a string 512 starting with 'monitor'."; 513 } 514 choice parameter { 515 description 516 "Specify the required parameters per subservice type."; 517 container service-instance-parameter { 518 when "derived-from-or-self(../type, 'service-instance-idty')"; 519 description 520 "Specify the parameters of a service instance."; 521 leaf service { 522 type string; 523 description "Name of the service."; 525 } 526 leaf instance-name{ 527 type string; 528 description "Name of the instance for that service."; 529 } 530 } 531 // Other modules can augment their own cases into here 532 } 533 leaf health-score { 534 type uint8 { 535 range "0 .. 100"; 536 } 537 config false; 538 description 539 "Score value of the subservice health. A value of 100 means that 540 subservice is healthy. A value of 0 means that the subservice is 541 broken. A value between 0 and 100 means that the subservice is 542 degraded."; 543 } 544 container symptoms { 545 description 546 "Symptoms for the subservice."; 547 list symptom { 548 key "start-date-time id"; 549 config false; 550 description 551 "List of symptoms the subservice. While the start-date-time key is not 552 necessary per se, this would get the entries sorted by start-date-time 553 for easy consumption."; 554 uses symptom; 555 } 556 } 557 container dependencies { 558 description 559 "configure the dependencies between the subservices, along with their types."; 560 list dependency { 561 key "type id"; 562 description 563 "List of soft dependencies of the subservice."; 564 uses subservice-dependency; 565 } 566 } 567 } 568 } 569 } 571 573 5. Subservice Extension: ietf-service-assurance-device YANG module 575 5.1. Tree View 577 The following tree diagram [RFC8340] provides an overview of the 578 ietf-service-assurance-device data model. 580 module: ietf-service-assurance-device 581 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: 582 +--rw device-idty 583 +--rw device? string 585 5.2. Complete Tree View 587 The following tree diagram [RFC8340] provides an overview of the 588 ietf-service-assurance and ietf-service-assurance-device data models. 590 module: ietf-service-assurance 591 +--ro assurance-graph-version? yang:counter32 592 +--ro assurance-graph-last-change? yang:date-and-time 593 +--rw subservices 594 +--rw subservice* [type id] 595 +--rw type identityref 596 +--rw id string 597 +--ro last-change? yang:date-and-time 598 +--ro label? string 599 +--rw under-maintenance? boolean 600 +--rw maintenance-contact string 601 +--rw (parameter)? 602 | +--:(service-instance-parameter) 603 | | +--rw service-instance-parameter 604 | | +--rw service? string 605 | | +--rw instance-name? string 606 | +--:(service-assurance-device:device-idty) 607 | +--rw service-assurance-device:device-idty 608 | +--rw service-assurance-device:device? string 609 +--ro health-score? uint8 610 +--rw symptoms 611 | +--ro symptom* [start-date-time id] 612 | +--ro id string 613 | +--ro health-score-weight? uint8 614 | +--ro label? string 615 | +--ro start-date-time yang:date-and-time 616 | +--ro stop-date-time? yang:date-and-time 617 +--rw dependencies 618 +--rw dependency* [type id] 619 +--rw type -> /subservices/subservice/type 620 +--rw id -> /subservices/subservice[type=current()/../type]/id 621 +--rw dependency-type? identityref 623 5.3. Concepts 625 As the number of subservices will grow over time, the YANG module is 626 designed to be extensible. A new subservice type requires the 627 precise specifications of its type and expected parameters. Let us 628 illustrate the example of the new DeviceHealthy subservice type. As 629 the name implies, it monitors and reports the device health, along 630 with some symptoms in case of degradation. 632 For our DeviceHealthy subservice definition, the new device-idty is 633 specified, as an inheritance from the base identity for subservices. 634 This indicates to the assurance agent that we are now assuring the 635 health of a device. 637 The typical parameter for the configuration of the DeviceHealthy 638 subservice is the name of the device that we want to assure. By 639 augmenting the parameter choice from ietf-service-assurance YANG 640 module for the case of the device-idty subservice type, this new 641 parameter is specified. 643 5.4. YANG Module 645 file "ietf-service-assurance-device@2020-01-13.yang" 647 module ietf-service-assurance-device { 648 yang-version 1.1; 649 namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device"; 650 prefix service-assurance-device; 652 import ietf-service-assurance { 653 prefix "service-assurance"; 654 } 656 organization 657 "IETF NETCONF (Network Configuration) Working Group"; 658 contact 659 "WG Web: 660 WG List: 661 Author: Benoit Claise 662 Author: Jean Quilbeuf "; 663 description 664 "This module extends the ietf-service-assurance module to add 665 support for the subservice DeviceHealthy. 667 Checks whether a network device is healthy. 669 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 670 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 671 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 672 are to be interpreted as described in BCP 14 (RFC 2119) 673 (RFC 8174) when, and only when, they appear in all 674 capitals, as shown here. 676 Copyright (c) 2019 IETF Trust and the persons identified as 677 authors of the code. All rights reserved. 679 Redistribution and use in source and binary forms, with or 680 without modification, is permitted pursuant to, and subject 681 to the license terms contained in, the Simplified BSD License 682 set forth in Section 4.c of the IETF Trust's Legal Provisions 683 Relating to IETF Documents 684 (https://trustee.ietf.org/license-info). 686 This version of this YANG module is part of RFC XXXX; see the 687 RFC itself for full legal notices. "; 689 revision 2020-01-13 { 690 description 691 "Added the maintenance window concept."; 692 reference 693 "RFC xxxx: Title to be completed"; 694 } 696 revision 2019-11-16 { 697 description 698 "Initial revision."; 699 reference 700 "RFC xxxx: Title to be completed"; 701 } 703 identity device-idty { 704 base service-assurance:subservice-idty; 705 description "Network Device is healthy."; 706 } 708 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter { 709 description 710 "Specify the required parameters for a new subservice type"; 711 container device-idty{ 712 when "derived-from-or-self(../service-assurance:type, 'device-idty')"; 713 description 714 "Specify the required parameters for the device-idty subservice type"; 716 leaf device { 717 type string; 718 description "The device to monitor."; 719 } 720 } 721 } 722 } 724 726 6. Subservice Extension: ietf-service-assurance-interface YANG module 728 6.1. Tree View 730 The following tree diagram [RFC8340] provides an overview of the 731 ietf-service-assurance-interface data model. 733 module: ietf-service-assurance-interface 734 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: 735 +--rw device? string 736 +--rw interface? string 738 6.2. Complete Tree View 740 The following tree diagram [RFC8340] provides an overview of the 741 ietf-service-assurance, ietf-service-assurance-device, and ietf- 742 service-assurance-interface data models. 744 module: ietf-service-assurance 745 +--ro assurance-graph-version? yang:counter32 746 +--ro assurance-graph-last-change? yang:date-and-time 747 +--rw subservices 748 +--rw subservice* [type id] 749 +--rw type identityref 750 +--rw id string 751 +--ro last-change? yang:date-and-time 752 +--ro label? string 753 +--rw under-maintenance? boolean 754 +--rw maintenance-contact string 755 +--rw (parameter)? 756 | +--:(service-instance-parameter) 757 | | +--rw service-instance-parameter 758 | | +--rw service? string 759 | | +--rw instance-name? string 760 | +--:(service-assurance-device:device-idty) 761 | | +--rw service-assurance-device:device-idty 762 | | +--rw service-assurance-device:device? string 763 | +--:(service-assurance-interface:device) 764 | | +--rw service-assurance-interface:device? string 765 | +--:(service-assurance-interface:interface) 766 | +--rw service-assurance-interface:interface? string 767 +--ro health-score? uint8 768 +--rw symptoms 769 | +--ro symptom* [start-date-time id] 770 | +--ro id string 771 | +--ro health-score-weight? uint8 772 | +--ro label? string 773 | +--ro start-date-time yang:date-and-time 774 | +--ro stop-date-time? yang:date-and-time 775 +--rw dependencies 776 +--rw dependency* [type id] 777 +--rw type -> /subservices/subservice/type 778 +--rw id -> /subservices/subservice[type=current()/../type]/id 779 +--rw dependency-type? identityref 781 6.3. Concepts 783 For our InterafaceHealthy subservice definition, the new interface- 784 idty is specified, as an inheritance from the base identity for 785 subservices. This indicates to the assurance agent that we are now 786 assuring the health of an interface. 788 The typical parameters for the configuration of the InterfaceHealthy 789 subservice are the name of the device and, on that specific device, a 790 specific interface. By augmenting the parameter choice from ietf- 791 service-assurance YANG module for the case of the interface-idty 792 subservice type, those two new parameter are specified. 794 6.4. YANG Module 796 file "ietf-service-assurance-interface@2020-01-13.yang" 798 module ietf-service-assurance-interface { 799 yang-version 1.1; 800 namespace "urn:ietf:params:xml:ns:yang:Cisco-ietf-service-assurance-interface"; 801 prefix service-assurance-interface; 803 import ietf-service-assurance { 804 prefix "service-assurance"; 805 } 807 organization 808 "IETF NETCONF (Network Configuration) Working Group"; 809 contact 810 "WG Web: 811 WG List: 812 Author: Benoit Claise 813 Author: Jean Quilbeuf "; 814 description 815 "This module extends the ietf-service-assurance module to add 816 support for the subservice InterfaceHealthy. 818 Checks whether an interface is healthy. 820 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 821 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 822 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 823 are to be interpreted as described in BCP 14 (RFC 2119) 824 (RFC 8174) when, and only when, they appear in all 825 capitals, as shown here. 827 Copyright (c) 2019 IETF Trust and the persons identified as 828 authors of the code. All rights reserved. 830 Redistribution and use in source and binary forms, with or 831 without modification, is permitted pursuant to, and subject 832 to the license terms contained in, the Simplified BSD License 833 set forth in Section 4.c of the IETF Trust's Legal Provisions 834 Relating to IETF Documents 835 (https://trustee.ietf.org/license-info). 837 This version of this YANG module is part of RFC XXXX; see the 838 RFC itself for full legal notices. "; 840 revision 2020-01-13 { 841 description 842 "Initial revision."; 843 reference 844 "RFC xxxx: Title to be completed"; 845 } 847 identity interface-idty { 848 base service-assurance:subservice-idty; 849 description "Checks whether an interface is healthy."; 850 } 852 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter { 853 when "derived-from-or-self(service-assurance:type, 'interface-idty')"; 854 description 855 "Specify the required parameters for the interface-idty subservice type"; 857 leaf device { 858 type string; 859 description "Device supporting the interface."; 860 } 861 leaf interface { 862 type string; 863 description "Name of the interface."; 864 } 865 } 866 } 868 870 7. Vendor-specific Subservice Extension: example-service-assurance- 871 device-acme YANG module 873 7.1. Tree View 875 The following tree diagram [RFC8340] provides an overview of the 876 example-service-assurance-device-acme data model. 878 module: example-service-assurance-device-acme 879 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: 880 +--rw acme-device-idty 881 +--rw device? string 882 +--rw acme-specific-parameter? string 884 7.2. Complete Tree View 886 The following tree diagram [RFC8340] provides an overview of the 887 ietf-service-assurance, ietf-service-assurance-device, and example- 888 service-assurance-device-acme data models. 890 module: ietf-service-assurance 891 +--ro assurance-graph-version? yang:counter32 892 +--ro assurance-graph-last-change? yang:date-and-time 893 +--rw subservices 894 +--rw subservice* [type id] 895 +--rw type identityref 896 +--rw id string 897 +--ro last-change? yang:date-and-time 898 +--ro label? string 899 +--rw under-maintenance? boolean 900 +--rw maintenance-contact string 901 +--rw (parameter)? 902 | +--:(service-instance-parameter) 903 | | +--rw service-instance-parameter 904 | | +--rw service? string 905 | | +--rw instance-name? string 906 | +--:(service-assurance-device:device-idty) 907 | | +--rw service-assurance-device:device-idty 908 | | +--rw service-assurance-device:device? string 909 | +--:(example-service-assurance-device-acme:acme-device-idty) 910 | +--rw example-service-assurance-device-acme:acme-device-idty 911 | +--rw example-service-assurance-device-acme:device? string 912 | +--rw example-service-assurance-device-acme:acme-specific-parameter? string 913 +--ro health-score? uint8 914 +--rw symptoms 915 | +--ro symptom* [start-date-time id] 916 | +--ro id string 917 | +--ro health-score-weight? uint8 918 | +--ro label? string 919 | +--ro start-date-time yang:date-and-time 920 | +--ro stop-date-time? yang:date-and-time 921 +--rw dependencies 922 +--rw dependency* [type id] 923 +--rw type -> /subservices/subservice/type 924 +--rw id -> /subservices/subservice[type=current()/../type]/id 925 +--rw dependency-type? identityref 927 7.3. Concepts 929 Under some circumstances, vendor-specific subservice types might be 930 required. As an example of this vendor-specific implementation, this 931 section shows how to augment the ietf-service-assurance-device module 932 to add support for the subservice DeviceHealthy, specific to the ACME 933 Corporation. The new parameter is acme-specific-parameter. 935 7.4. YANG Module 937 module example-service-assurance-device-acme { 938 yang-version 1.1; 939 namespace "urn:ietf:params:xml:ns:yang:example-service-assurance-device-acme"; 940 prefix service-assurance-device; 942 import ietf-service-assurance { 943 prefix "service-assurance"; 944 } 946 organization 947 "IETF NETCONF (Network Configuration) Working Group"; 948 contact 949 "WG Web: 950 WG List: 951 Author: Benoit Claise 952 Author: Jean Quilbeuf "; 953 description 954 "This module extends the ietf-service-assurance module to add 955 support for the subservice DeviceHealthy. 957 Checks whether a network device is healthy. 959 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 960 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 961 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 962 are to be interpreted as described in BCP 14 (RFC 2119) 963 (RFC 8174) when, and only when, they appear in all 964 capitals, as shown here. 966 Copyright (c) 2019 IETF Trust and the persons identified as 967 authors of the code. All rights reserved. 969 Redistribution and use in source and binary forms, with or 970 without modification, is permitted pursuant to, and subject 971 to the license terms contained in, the Simplified BSD License 972 set forth in Section 4.c of the IETF Trust's Legal Provisions 973 Relating to IETF Documents 974 (https://trustee.ietf.org/license-info). 976 This version of this YANG module is part of RFC XXXX; see the 977 RFC itself for full legal notices. "; 979 revision 2020-01-13 { 980 description 981 "Added the maintenance window concept."; 982 reference 983 "RFC xxxx: Title to be completed"; 984 } 986 revision 2019-11-16 { 987 description 988 "Initial revision."; 989 reference 990 "RFC xxxx: Title to be completed"; 991 } 993 identity device-idty { 994 base service-assurance:subservice-idty; 995 description "Network Device is healthy."; 996 } 998 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter { 999 description 1000 "Specify the required parameters for a new subservice type"; 1001 container device-idty{ 1002 when "derived-from-or-self(../service-assurance:type, 'device-idty')"; 1003 description 1004 "Specify the required parameters for the device-idty subservice type"; 1006 leaf device { 1007 type string; 1008 description "The device to monitor."; 1009 } 1010 } 1011 } 1012 } 1014 8. Security Considerations 1016 The YANG module specified in this document defines a schema for data 1017 that is designed to be accessed via network management protocols such 1018 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1019 is the secure transport layer, and the mandatory-to-implement secure 1020 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1021 is HTTPS, and the mandatory-to-implement secure transport is TLS 1022 [RFC8446]. 1024 The Network Configuration Access Control Model (NACM) [RFC8341] 1025 provides the means to restrict access for particular NETCONF or 1026 RESTCONF users to a preconfigured subset of all available NETCONF or 1027 RESTCONF protocol operations and content. 1029 TO BE populated according to https://trac.ietf.org/trac/ops/wiki/ 1030 yang-security-guidelines 1032 9. IANA Considerations 1034 9.1. The IETF XML Registry 1036 This document registers two URIs in the IETF XML registry [RFC3688]. 1037 Following the format in [RFC3688], the following registrations are 1038 requested: 1040 URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance 1041 Registrant Contact: The NETCONF WG of the IETF. 1042 XML: N/A, the requested URI is an XML namespace. 1044 URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device 1045 Registrant Contact: The NETCONF WG of the IETF. 1046 XML: N/A, the requested URI is an XML namespace. 1048 URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface 1049 Registrant Contact: The NETCONF WG of the IETF. 1050 XML: N/A, the requested URI is an XML namespace. 1052 9.2. The YANG Module Names Registry 1054 This document registers three YANG modules in the YANG Module Names 1055 registry [RFC7950]. Following the format in [RFC7950], the the 1056 following registrations are requested: 1058 name: ietf-service-assurance 1059 namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance 1060 prefix: inc 1061 reference: RFC XXXX 1063 name: ietf-service-assurance-device 1064 namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device 1065 prefix: inc 1066 reference: RFC XXXX 1068 name: ietf-service-assurance-interface 1069 namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface 1070 prefix: inc 1071 reference: RFC XXXX 1073 10. Open Issues 1075 -Complete the Security Considerations 1077 11. References 1079 11.1. Normative References 1081 [draft-claise-opsawg-service-assurance-architecture] 1082 Claise, B. and J. Quilbeuf, "draft-claise-opsawg-service- 1083 assurance-architecture", 2019. 1085 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1086 and A. Bierman, Ed., "Network Configuration Protocol 1087 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1088 . 1090 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1091 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1092 . 1094 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1095 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1096 . 1098 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1099 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1100 . 1102 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1103 Access Control Model", STD 91, RFC 8341, 1104 DOI 10.17487/RFC8341, March 2018, 1105 . 1107 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1108 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1109 . 1111 11.2. Informative References 1113 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1114 Requirement Levels", BCP 14, RFC 2119, 1115 DOI 10.17487/RFC2119, March 1997, 1116 . 1118 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1119 DOI 10.17487/RFC3688, January 2004, 1120 . 1122 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1123 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1124 May 2017, . 1126 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1127 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1128 . 1130 Appendix A. Changes between revisions 1132 v00 - v01 1134 o Terminology clarifications 1136 o Provide example of impacting versus impacted dependencies 1138 Acknowledgements 1140 The authors would like to thank Jan Lindblad for his help during the 1141 design of these YANG modules. The authors would like to thank 1142 Stephane Litkowski and Charles Eckel for their reviews. 1144 Authors' Addresses 1146 Benoit Claise 1147 Cisco Systems, Inc. 1148 De Kleetlaan 6a b1 1149 1831 Diegem 1150 Belgium 1152 Email: bclaise@cisco.com 1154 Jean Quilbeuf 1155 Cisco Systems, Inc. 1156 1, rue Camille Desmoulins 1157 92782 Issy Les Moulineaux 1158 France 1160 Email: jquilbeu@cisco.com 1161 Paolo Lucente 1162 NTT 1163 Siriusdreef 70-72 1164 Hoofddorp, WT 2132 1165 Netherlands 1167 Email: paolo@ntt.net 1169 Paolo Fasano 1170 TIM S.p.A 1171 via G. Reiss Romoli, 274 1172 10148 Torino 1173 Italy 1175 Email: paolo2.fasano@telecomitalia.it