idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 246 has weird spacing: '...-change yan...' == Line 259 has weird spacing: '...ce-name str...' == Line 751 has weird spacing: '... device str...' == Line 862 has weird spacing: '...terface str...' == Line 1114 has weird spacing: '...rameter str...' == (6 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (24 June 2022) is 666 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) == Outdated reference: A later version (-13) exists of draft-ietf-opsawg-service-assurance-architecture-05 ** Downref: Normative reference to an Informational draft: draft-ietf-opsawg-service-assurance-architecture (ref. 'I-D.ietf-opsawg-service-assurance-architecture') -- Obsolete informational reference (is this intentional?): RFC 7895 (Obsoleted by RFC 8525) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). 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 Huawei 5 Expires: 26 December 2022 P. Lucente 6 NTT 7 P. Fasano 8 TIM S.p.A 9 T. Arumugam 10 Cisco Systems, Inc. 11 24 June 2022 13 YANG Modules for Service Assurance 14 draft-ietf-opsawg-service-assurance-yang-06 16 Abstract 18 This document specifies YANG modules for representing assurance 19 graphs. These graphs represent the assurance of a given service by 20 decomposing it into atomic assurance elements called subservices. A 21 companion document, Service Assurance for Intent-based Networking 22 Architecture, presents an architecture for implementing the assurance 23 of such services. 25 The YANG data models in this document conforms to the Network 26 Management Datastore Architecture (NMDA) defined in RFC 8342. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 26 December 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. YANG Modules Overview . . . . . . . . . . . . . . . . . . . . 3 64 3. Base IETF Service Assurance YANG Module . . . . . . . . . . . 4 65 3.1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.2. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 9 68 4. Subservice Augmentation: ietf-service-assurance-device YANG 69 module . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 16 71 4.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 17 72 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17 73 5. Subservice Augmentation: ietf-service-assurance-interface YANG 74 module . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 19 76 5.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 19 77 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 19 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 80 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 22 81 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 22 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 22 84 8.2. Informative References . . . . . . . . . . . . . . . . . 24 85 Appendix A. Vendor-specific Subservice Augmentation: 86 example-service-assurance-device-acme YANG module . . . . 24 87 A.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 24 88 A.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 24 89 A.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 24 90 Appendix B. Further Augmentations: IP Connectivity and IS-IS 91 subservices . . . . . . . . . . . . . . . . . . . . . . . 26 92 B.1. IP Connectivity Tree View . . . . . . . . . . . . . . . . 26 93 B.2. IS-IS Tree View . . . . . . . . . . . . . . . . . . . . . 27 94 B.3. Global Tree View . . . . . . . . . . . . . . . . . . . . 27 95 B.4. IP Connectivity YANG Module . . . . . . . . . . . . . . . 29 96 B.5. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . 31 97 Appendix C. Example of YANG instances . . . . . . . . . . . . . 32 98 Appendix D. YANG Library for Service Assurance . . . . . . . . . 36 99 Appendix E. Changes between revisions . . . . . . . . . . . . . 37 100 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 38 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 103 1. Introduction 105 [I-D.ietf-opsawg-service-assurance-architecture] specifies an 106 architecture and a set of involved components for service assurance. 107 This document complements the architecture by specifying a data model 108 for the interfaces between components. More specifically, the 109 document provides YANG modules for the purpose of service assurance 110 in a format that is: 112 * machine readable 114 * vendor independent 116 * augmentable 118 1.1. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 13 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 The terms used in this document are defined in 127 [I-D.ietf-opsawg-service-assurance-architecture]. 129 The meanings of the symbols in the tree diagrams are defined in 130 [RFC8340]. 132 2. YANG Modules Overview 134 The main YANG module, "ietf-service-assurance" (Section 3), defines 135 objects for assuring network services based on their decomposition 136 into so-called subservices. The subservices are hierarchically 137 organised by dependencies. The subservices, along with the 138 dependencies, constitute an assurance graph. This module should be 139 supported by an agent, able to interact with the devices in order to 140 produce a health status and symptoms for each subservice in an 141 assurance graph. This module is intended for the following use 142 cases: 144 * Assurance graph configuration: 146 - Subservices: configure a set of subservices to assure, by 147 specifying their types and parameters. 149 - Dependencies: configure the dependencies between the 150 subservices, along with their type. 152 * Assurance telemetry: export the assurance graph with health status 153 and symptoms for each node. 155 The modules presented in this document conform to the Network 156 Management Datastore Architecture defined in [RFC8342]. 158 The second YANG module, "ietf-service-assurance-device" (Section 4), 159 augments the "ietf-service-assurance" module by adding support for 160 the device subservice. Additional subservice types might be added 161 following a similar approach. 163 The third YANG module, "ietf-service-assurance-interface" 164 (Section 5), is another example that augments the "ietf-service- 165 assurance" module, by adding support for the interface subservice. 167 We provide additional examples in the appendix. The module "example- 168 service-assurance-device-acme" (Appendix A) augments the "ietf- 169 service-assurance-device" module to customize it for devices of the 170 fictional ACME Corporation. Additional vendor-specific parameters 171 might be added following a similar approach. We also provide the 172 modules "example-service-assurance-ip-connectivity" and "example- 173 service-assurance-is-is" (Appendix B) to model the example in 174 Figure 2 from Section 3.1 of 175 [I-D.ietf-opsawg-service-assurance-architecture]. 177 3. Base IETF Service Assurance YANG Module 179 3.1. Concepts 181 The "ietf-service-assurance" YANG module assumes a set of 182 subservices, to be assured independently. A subservice is a feature 183 or a subpart of the network system that a given service instance 184 depends on. Examples of subservices include: 186 * device: whether a device is healthy, and if not, what are the 187 symptoms. Potential symptoms are "CPU overloaded", "Out of RAM", 188 or "Out of TCAM". 190 * ip-connectivity: given two IP addresses bound to two devices, what 191 is the quality of the IP connectivity between them. Potential 192 symptoms are "No route available" or "ECMP Imbalance". 194 The first example is a subservice representing a subpart of the 195 network system, while the second is a subservice representing a 196 feature of the network. In both cases, these subservices might 197 depend on other subservices, for instance, the connectivity might 198 depend on a subservice representing the routing system and on a 199 subservice representing ECMP. 201 The two subservices presented above need different sets of parameters 202 to fully characterize one of their instance. An instance of the 203 device subservice is fully characterized by a single parameter 204 allowing to identify the device to monitor. For ip-connectivity 205 subservice, at least the device and IP address for both ends of the 206 link are needed to fully characterize an instance. Therefore, the 207 "ietf-service-assurance" module is intended to be augmented for each 208 type of subservice, so that the needed parameters are modelled in the 209 augmenting module. 211 The only "built-in" type available represents service instances. A 212 service instance is represented as a subservice instance of type 213 "service". The parameters required to fully identify a service 214 instance are the type of the service and the name of the service 215 instance. 217 The dependencies are modelled as an adjacency list, in the sense that 218 each subservice contains a list of pointers to its dependencies. 219 That list can be empty if the subservice instance does not have any 220 dependencies. 222 By specifying service instances and their dependencies in terms of 223 subservices, one defines a global assurance graph. That assurance 224 graph is the result of merging all the individual assurance graphs 225 for the assured service instances. Each subservice instance is 226 expected to appear only one in the global assurance graph even if 227 several service instances depend on it. For example, an instance of 228 the device subservice is a dependency of every service instance that 229 rely on the corresponding device. The assurance graph of a specific 230 service instance is the subgraph obtained by traversing the global 231 assurance graph through the dependencies starting from the specific 232 service instance. 234 An assurance agent configured with such a graph is expected to 235 produce, for each configured subservice: a health-status indicating 236 how healthy the subservice is and when the subservice is not healthy, 237 a list of symptoms explaining why the subservice is not healthy. 239 3.2. Tree View 241 The following tree diagram [RFC8340] provides an overview of the 242 "ietf-service-assurance" module. 244 module: ietf-service-assurance 245 +--ro assurance-graph-version yang:counter64 246 +--ro assurance-graph-last-change yang:date-and-time 247 +--rw subservices 248 +--rw subservice* [type id] 249 +--rw type identityref 250 +--rw id string 251 +--ro last-change? yang:date-and-time 252 +--ro label? string 253 +--rw under-maintenance? boolean 254 +--rw maintenance-contact string 255 +--rw (parameter) 256 | +--:(service-instance-parameter) 257 | +--rw service-instance-parameter 258 | +--rw service string 259 | +--rw instance-name string 260 +--ro health-score? union 261 +--ro symptoms-history-start? yang:date-and-time 262 +--ro symptoms 263 | +--ro symptom* [start-date-time id] 264 | +--ro id string 265 | +--ro health-score-weight? uint8 266 | +--ro description? string 267 | +--ro start-date-time yang:date-and-time 268 | +--ro stop-date-time? yang:date-and-time 269 +--rw dependencies 270 +--rw dependency* [type id] 271 +--rw type 272 | -> /subservices/subservice/type 273 +--rw id leafref 274 +--rw dependency-type? identityref 276 The current version "assurance-graph-version" and date of last change 277 "assurance-graph-last-change" are read only and must be maintained by 278 the server. The version should be incremented and the date updated 279 each time the graph structure is changed by addition or deletion of 280 subservices, dependencies or modification of their configurable 281 attributes. Such modifications correspond to a structural change in 282 the graph. The current version and the date of last change are 283 useful for a client to quickly check if there is a need to update the 284 graph structure. A change in the health-score or symptoms associated 285 to a service or subservice does not change the structure of the graph 286 and thus has no effect on the version or date of last change. 288 The "subservice" list contains all the subservice instances currently 289 configured on the server. A subservice declaration MUST provide: 291 * A subservice type ("type"): reference to an identity that inherits 292 from "subservice-idty", which is the base identity for any 293 subservice type. 295 * An id ("id"): string uniquely identifying the subservice among 296 those with the same type, 298 The type and id uniquely identify a given subservice. 300 The "last-change" indicates when this particular subservice was 301 modified for the last time. 303 The "label" is a human-readable description of the subservice. 305 The "under-maintenance" and "maintenance-contact" flags inhibit the 306 emission of symptoms for that subservice and subservices that depend 307 on them. See Section 3.7 of 308 [I-D.ietf-opsawg-service-assurance-architecture] for a more detailed 309 discussion. 311 The "parameter" choice is intended to be augmented in order to 312 describe parameters that are specific to the current subservice type. 313 This base module defines only the subservice type representing 314 service instances. Service instances MUST be modeled as a particular 315 type of subservice with two parameters, "service" and "instance- 316 name". The "service" parameter is the name of the service defined in 317 the network orchestrator, for instance "point-to-point-l2vpn". The 318 "instance-name" parameter is the name assigned to the particular 319 instance to be assured, for instance the name of the customer using 320 that instance. 322 The "health-score" contains a value normally between 0 and 100 323 indicating how healthy the subservice is. The special value -1 can 324 be used to specify that no value could be computed for that health- 325 score, for instance if some metric needed for that computation could 326 not be collected. 328 The "symptoms-history-start" is the cutoff date for reporting 329 symptoms. Symptoms that were terminated before that date are not 330 reported anymore in the model. 332 The status of each subservice contains a list of symptoms. Each 333 symptom is specified by 335 * an identifier "id" which MUST be globally unique, 337 * a "health-score-weight" specifying the impact to the health score 338 incurred by this symptom, 340 * a "description" explaining what the symptom is, 342 * a "start-date-time" indicating when the symptom became active and 344 * a "stop-date-time" indicating when the symptom stopped being 345 active, that field is not present if the symptom is still active. 347 While the unique id is sufficient as an unique key list, the start- 348 date-time second key help sorting and retrieving relevant symptoms. 350 The "dependency" list contains the dependencies for the current 351 subservice. Each of them is specified by a leafref to both "type" 352 and "id" of the target dependencies. A dependency has a type 353 indicated in the "dependency-type" field. Two types are specified in 354 the model: 356 * Impacting: such a dependency indicates an impact on the health of 357 the dependent, 359 * Informational: such a dependency might explain why the dependent 360 has issues but does not impact its health. 362 To illustrate the difference between "impacting" and "informational", 363 consider the interface subservice, representing a network interface. 364 If the device to which the network interface belongs goes down, the 365 network interface will transition to a "down" state as well. 366 Therefore, the dependency of the interface subservice towards the 367 device subservice is "impacting". On the other hand, a dependency 368 towards the ecmp-load subservice, which checks that the load between 369 ECMP remains stable throughout time, is only "informational". 371 Indeed, services might be perfectly healthy even if the load 372 distribution between ECMP changed. However, such an instability 373 might be a relevant symptom for diagnosing the root cause of a 374 problem. 376 The relation between the health score ("health-score") and the 377 health-score-weight of the currently active symptoms is not 378 explicitly defined in this document. The only requirement is that a 379 health score that strictly smaller than 100 (the maximal value) must 380 be explained by at least one symptom. A way to enforce that 381 requirement is to first detect symptoms and then compute the health 382 score based on the health-score-weight of the detected symptoms. As 383 an example, such a computation could be to sum the health-score- 384 weight of the active symptoms, subtract that value from 100 and 385 change the value to 0 if negative. The relation between health-score 386 and health-score-weight is left to the implementor (of an agent 387 [I-D.ietf-opsawg-service-assurance-architecture]). 389 3.3. YANG Module 391 file "ietf-service-assurance@2022-04-07.yang" 393 module ietf-service-assurance { 394 yang-version 1.1; 395 namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance"; 396 prefix sain; 398 import ietf-yang-types { 399 prefix yang; 400 reference 401 "RFC 6991: Common YANG Data Types"; 402 } 404 organization 405 "IETF OPSAWG Working Group"; 406 contact 407 "WG Web: 408 WG List: 409 Author: Benoit Claise 410 Author: Jean Quilbeuf "; 411 description 412 "This module defines objects for assuring services based on their 413 decomposition into so-called subservices, according to the SAIN 414 (Service Assurance for Intent-based Networking) architecture. 416 The subservices hierarchically organised by dependencies constitute 417 an assurance graph. This module should be supported by an assurance 418 agent, able to interact with the devices in order to produce a 419 health status and symptoms for each subservice in the assurance 420 graph. 422 This module is intended for the following use cases: 423 * Assurance graph configuration: 424 - subservices: configure a set of subservices to assure, by 425 specifying their types and parameters. 426 - dependencies: configure the dependencies between the 427 subservices, along with their type. 428 * Assurance telemetry: export the health status of the subservices, 429 along with the observed symptoms. 431 Copyright (c) 2022 IETF Trust and the persons identified as 432 authors of the code. All rights reserved. 434 Redistribution and use in source and binary forms, with or 435 without modification, is permitted pursuant to, and subject 436 to the license terms contained in, the Revised BSD License 437 set forth in Section 4.c of the IETF Trust's Legal Provisions 438 Relating to IETF Documents 439 (https://trustee.ietf.org/license-info). 440 This version of this YANG module is part of RFC XXXX; see the 441 RFC itself for full legal notices. "; 443 revision 2022-06-23 { 444 description 445 "Initial version."; 446 reference 447 "RFC xxxx: YANG Modules for Service Assurance"; 448 } 450 identity subservice-idty { 451 description 452 "Base identity for subservice types."; 453 } 455 identity service-instance-idty { 456 base subservice-idty; 457 description 458 "Identity representing a service instance."; 459 } 461 identity dependency-type { 462 description 463 "Base identity for representing dependency types."; 464 } 466 identity informational { 467 base dependency-type; 468 description 469 "Indicates that symptoms of the dependency might be of interest 470 for the dependent, but the status of the dependency should not 471 have any impact on the dependent."; 472 } 474 identity impacting { 475 base dependency-type; 476 description 477 "Indicates that the status of the dependency directly impacts the 478 status of the dependent."; 479 } 481 grouping symptom { 482 description 483 "A grouping for the symptoms for a specific subservice."; 484 leaf id { 485 type string; 486 description 487 "A globally unique identifier for the symptom, to be generated 488 by the SAIN agent that detected the symptom."; 489 } 490 leaf health-score-weight { 491 type uint8 { 492 range "0 .. 100"; 493 } 494 description 495 "The weight to the health score incurred by this symptom. The 496 higher the value, the more of an impact this symptom has. If a 497 subservice health score is not 100, there must be at least one 498 symptom with a health score weight larger than 0."; 499 } 500 leaf description { 501 type string; 502 description 503 "Description of the symptom, i.e., text describing what the 504 symptom is, to be computer-consumable and be displayed on a 505 human interface. It is not intended for random end users but 506 for network/system/software engineers that use their local 507 context to provide and interpret such information. Therefore, 508 no mechanism for language tagging is needed."; 509 } 510 leaf start-date-time { 511 type yang:date-and-time; 512 description 513 "Date and time at which the symptom was detected."; 514 } 515 leaf stop-date-time { 516 type yang:date-and-time; 517 description 518 "Date and time at which the symptom stopped being detected. 519 must after the start-date-time."; 520 } 521 } 523 grouping subservice-dependency { 524 description 525 "Represents a dependency to another subservice."; 526 leaf type { 527 type leafref { 528 path "/subservices/subservice/type"; 529 } 530 description 531 "The type of the subservice to refer to (e.g., device)."; 532 } 533 leaf id { 534 type leafref { 535 path "/subservices/subservice[type=current()/../type]/id"; 536 } 537 description 538 "The identifier of the subservice to refer to."; 539 } 540 leaf dependency-type { 541 type identityref { 542 base dependency-type; 543 } 544 description 545 "Represents the type of dependency (e.g., informational, 546 impacting)."; 547 } 548 } 550 leaf assurance-graph-version { 551 type yang:counter64; 552 config false; 553 mandatory true; 554 description 555 "The assurance graph version, which increases by 1 for each new 556 version, that cause structural changes to the graph. Structural 557 changes include addition or deletion of subservices and 558 modification of a subservice parameters, dependencies or 559 maintenance windows. Structural changes correspond to changes in 560 the nodes that are config true. 562 The counter wraps around when the maximum value is reached."; 564 } 565 leaf assurance-graph-last-change { 566 type yang:date-and-time; 567 config false; 568 mandatory true; 569 description 570 "Date and time at which the assurance graph last changed after the 571 changes (dependencies and/or maintenance windows parameters) are 572 applied to the subservice(s). These date and time must be more 573 recent or equal compared to the more recent value of any changed 574 subservices last-change"; 575 } 576 container subservices { 577 description 578 "Root container for the subservices."; 579 list subservice { 580 key "type id"; 581 description 582 "List of configured subservices."; 583 leaf type { 584 type identityref { 585 base subservice-idty; 586 } 587 description 588 "Type of the subservice, for instance, device or interface."; 589 } 590 leaf id { 591 type string; 592 description 593 "Identifier of the subservice instance. Must be unique among 594 subservices of the same type."; 595 } 596 leaf last-change { 597 type yang:date-and-time; 598 config false; 599 description 600 "Date and time at which the structure for this 601 subservice instance last changed, i.e., dependencies and/or 602 maintenance windows parameters."; 603 } 604 leaf label { 605 type string; 606 config false; 607 description 608 "Label of the subservice, i.e., text describing what the 609 subservice is to be displayed on a human interface. 611 It is not intended for random end users but for 612 network/system/software engineers that use their local 613 context to provide and interpret such information. 614 Therefore, no mechanism for language tagging is needed."; 615 } 616 leaf under-maintenance { 617 type boolean; 618 default "false"; 619 description 620 "A flag indicating whether this particular subservice is 621 under maintenance. Under this circumstance, the subservice 622 symptoms and the symptoms of its dependencies in the 623 assurance graph are not taken into account. Instead, 624 the subservice should report a single symptom 'Under 625 Maintenance'. 627 The operator changing the under-maintenance value must set 628 the maintenance-contact variable. 630 When the subservice is not under maintenance any longer, the 631 under-maintenance flag must return to its default value and 632 the under-maintenance-owner variable deleted."; 633 } 634 leaf maintenance-contact { 635 when "../under-maintenance = 'true'"; 636 type string; 637 mandatory true; 638 description 639 "A string used to model an administratively assigned name of 640 the resource that changed the under-maintenance value to 641 'true'. 643 It is suggested that this name contain one or more of the 644 following: IP address, management station name, 645 network manager's name, location, or phone number. In some 646 cases the agent itself will be the owner of an entry. In 647 these cases, this string shall be set to a string starting 648 with 'monitor'."; 649 } 650 choice parameter { 651 mandatory true; 652 description 653 "Specify the required parameters per subservice type. Each 654 module augmenting this module with a new subservice type, 655 that is a new identity based on subservice-idty should 656 augment this choice as well, by adding a container 657 available only if the current subservice type is 658 the newly added identity."; 659 container service-instance-parameter { 660 when "derived-from-or-self(../type, 661 'sain:service-instance-idty')"; 662 description 663 "Specify the parameters of a service instance."; 664 leaf service { 665 type string; 666 mandatory true; 667 description 668 "Name of the service."; 669 } 670 leaf instance-name { 671 type string; 672 mandatory true; 673 description 674 "Name of the instance for that service."; 675 } 676 } 677 // Other modules can augment their own cases into here 678 } 679 leaf health-score { 680 type union { 681 type uint8 { 682 range "0 .. 100"; 683 } 684 type enumeration { 685 enum missing { 686 value -1; 687 description 688 "Explictly represent the fact that the health score is 689 missing. This could be used when metrics crucial to 690 establish the health score are not collected anymore."; 691 } 692 } 693 } 694 config false; 695 description 696 "Score value of the subservice health. A value of 100 means 697 that subservice is healthy. A value of 0 means that the 698 subservice is broken. A value between 0 and 100 means that 699 the subservice is degraded."; 700 } 701 leaf symptoms-history-start { 702 type yang:date-and-time; 703 config false; 704 description 705 "Date and time at which the symptoms history starts for this 706 subservice instance, either because the subservice instance 707 started at that date and time or because the symptoms before 708 that were removed due to a garbage collection process."; 709 } 710 container symptoms { 711 config false; 712 description 713 "Symptoms for the subservice."; 714 list symptom { 715 key "start-date-time id"; 716 description 717 "List of symptoms the subservice. While the start-date-time 718 key is not necessary per se, this would get the entries 719 sorted by start-date-time for easy consumption."; 720 uses symptom; 721 } 722 } 723 container dependencies { 724 description 725 "Indicates the set of dependencies of the current subservice, 726 along with their types."; 727 list dependency { 728 key "type id"; 729 description 730 "List of dependencies of the subservice."; 731 uses subservice-dependency; 732 } 733 } 734 } 735 } 736 } 738 740 4. Subservice Augmentation: ietf-service-assurance-device YANG module 742 4.1. Tree View 744 The following tree diagram [RFC8340] provides an overview of the 745 "ietf-service-assurance-device" module. 747 module: ietf-service-assurance-device 749 augment /sain:subservices/sain:subservice/sain:parameter: 750 +--rw parameters 751 +--rw device string 753 A complete tree view of the base module with all augmenting modules 754 presented in this draft is available in Appendix B.3. 756 4.2. Concepts 758 As the number of subservices will grow over time, the YANG module is 759 designed to be extensible. A new subservice type requires the 760 precise specifications of its type and expected parameters. Let us 761 illustrate the example of the new device subservice type. As the 762 name implies, it monitors and reports the device health, along with 763 some symptoms in case of degradation. 765 For our device subservice definition, the new identity "device-idty" 766 is specified, as an inheritance from the base identity for 767 subservices. This indicates to the assurance agent that we are now 768 assuring the health of a device. 770 The typical parameter for the configuration of the device subservice 771 is the name of the device that we want to assure. By augmenting the 772 parameter choice from ietf-service-assurance YANG module for the case 773 of the "device-idty" subservice type, this new parameter is 774 specified. 776 4.3. YANG Module 778 file "ietf-service-assurance-device@2022-04-07.yang" 780 module ietf-service-assurance-device { 781 yang-version 1.1; 782 namespace 783 "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device"; 784 prefix sain-device; 786 import ietf-service-assurance { 787 prefix sain; 788 reference 789 "RFC xxxx: YANG Modules for Service Assurance"; 790 } 792 organization 793 "IETF OPSAWG Working Group"; 794 contact 795 "WG Web: 796 WG List: 797 Author: Benoit Claise 798 Author: Jean Quilbeuf "; 799 description 800 "This module augments the ietf-service-assurance module with support 801 of the device subservice. 803 Copyright (c) 2022 IETF Trust and the persons identified as 804 authors of the code. All rights reserved. 806 Redistribution and use in source and binary forms, with or 807 without modification, is permitted pursuant to, and subject 808 to the license terms contained in, the Revised BSD License 809 set forth in Section 4.c of the IETF Trust's Legal Provisions 810 Relating to IETF Documents 811 (https://trustee.ietf.org/license-info). 812 This version of this YANG module is part of RFC XXXX; see the 813 RFC itself for full legal notices. "; 815 revision 2022-06-23 { 816 description 817 "Initial revision."; 818 reference 819 "RFC xxxx: YANG Modules for Service Assurance"; 820 } 822 identity device-idty { 823 base sain:subservice-idty; 824 description 825 "Identity of device subservice."; 826 } 828 augment "/sain:subservices/sain:subservice/sain:parameter" { 829 when "derived-from-or-self(sain:type, 'device-idty')"; 830 description 831 "Augments the parameter choice from ietf-service-assurance 832 module with a case specific to the device subservice."; 833 container parameters { 834 description 835 "Parameters for the device subservice type"; 836 leaf device { 837 type string; 838 mandatory true; 839 description 840 "Identifier of the device to monitor. The 841 identifier (device id, hostname, management IP) depends 842 on the context."; 843 } 844 } 845 } 846 } 847 849 5. Subservice Augmentation: ietf-service-assurance-interface YANG 850 module 852 5.1. Tree View 854 The following tree diagram [RFC8340] provides an overview of the 855 ietf-service-assurance-interface data model. 857 module: ietf-service-assurance-interface 859 augment /sain:subservices/sain:subservice/sain:parameter: 860 +--rw parameters 861 +--rw device string 862 +--rw interface string 864 A complete tree view of the base module with all augmenting modules 865 presented in this draft is available in Appendix B.3. 867 5.2. Concepts 869 For the interface subservice definition, the new interface-idty is 870 specified, as an inheritance from the base identity for subservices. 871 This indicates to the assurance agent that we are now assuring the 872 health of an interface. 874 The typical parameters for the configuration of the interface 875 subservice are the name of the device and, on that specific device, a 876 specific interface. By augmenting the parameter choice from ietf- 877 service-assurance YANG module for the case of the interface-idty 878 subservice type, those two new parameters are specified. 880 5.3. YANG Module 882 file "ietf-service-assurance-interface@2022-04-07.yang" 884 module ietf-service-assurance-interface { 885 yang-version 1.1; 886 namespace 887 "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface"; 888 prefix sain-interface; 890 import ietf-service-assurance { 891 prefix sain; 892 reference 893 "RFC xxxx: YANG Modules for Service Assurance"; 895 } 897 organization 898 "IETF OPSAWG Working Group"; 899 contact 900 "WG Web: 901 WG List: 902 Author: Benoit Claise 903 Author: Jean Quilbeuf "; 904 description 905 "This module extends the ietf-service-assurance module to add 906 support for the interface subservice. 908 Checks whether an interface is healthy. 910 Copyright (c) 2022 IETF Trust and the persons identified as 911 authors of the code. All rights reserved. 912 Redistribution and use in source and binary forms, with or 913 without modification, is permitted pursuant to, and subject 914 to the license terms contained in, the Revised BSD License 915 set forth in Section 4.c of the IETF Trust's Legal Provisions 916 Relating to IETF Documents 917 (https://trustee.ietf.org/license-info). 919 This version of this YANG module is part of RFC XXXX; see the 920 RFC itself for full legal notices. "; 922 revision 2022-06-23 { 923 description 924 "Initial revision."; 925 reference 926 "RFC xxxx: YANG Modules for Service Assurance"; 927 } 929 identity interface-idty { 930 base sain:subservice-idty; 931 description 932 "Checks whether an interface is healthy."; 933 } 935 augment "/sain:subservices/sain:subservice/sain:parameter" { 936 when "derived-from-or-self(sain:type, 'interface-idty')"; 937 description 938 "Augments the parameter choice from ietf-service-assurance 939 module with a case specific to the interface subservice."; 940 container parameters { 941 description 942 "Parameters for the interface subservice type."; 944 leaf device { 945 type string; 946 mandatory true; 947 description 948 "Device supporting the interface."; 949 } 950 leaf interface { 951 type string; 952 mandatory true; 953 description 954 "Name of the interface."; 955 } 956 } 957 } 958 } 960 962 6. Security Considerations 964 The YANG module specified in this document defines a schema for data 965 that is designed to be accessed via network management protocols such 966 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 967 is the secure transport layer, and the mandatory-to-implement secure 968 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 969 is HTTPS, and the mandatory-to-implement secure transport is TLS 970 [RFC8446]. 972 The Network Configuration Access Control Model (NACM) [RFC8341] 973 provides the means to restrict access for particular NETCONF or 974 RESTCONF users to a preconfigured subset of all available NETCONF or 975 RESTCONF protocol operations and content. 977 There are a number of data nodes defined in this YANG module that are 978 writable/ creatable/deletable (i.e., config true, which is the 979 default). These data nodes may be considered sensitive or vulnerable 980 in some network environments. Write operations (e.g., edit-config) 981 to these data nodes without proper protection can have a negative 982 effect on network operations. These are the subtrees and data nodes 983 and their sensitivity/vulnerability: 985 * /subservices/subservice/type 987 * /subservices/subservice/id 989 * /subservices/subservice/under-maintenance 990 * /subservices/subservice/maintenance-contact 992 7. IANA Considerations 994 7.1. The IETF XML Registry 996 This document registers two URIs in the IETF XML registry [RFC3688]. 997 Following the format in [RFC3688], the following registrations are 998 requested: 1000 URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance 1001 Registrant Contact: The NETCONF WG of the IETF. 1002 XML: N/A, the requested URI is an XML namespace. 1004 URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device 1005 Registrant Contact: The NETCONF WG of the IETF. 1006 XML: N/A, the requested URI is an XML namespace. 1008 URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface 1009 Registrant Contact: The NETCONF WG of the IETF. 1010 XML: N/A, the requested URI is an XML namespace. 1012 7.2. The YANG Module Names Registry 1014 This document registers three YANG modules in the YANG Module Names 1015 registry [RFC7950]. Following the format in [RFC7950], the following 1016 registrations are requested: 1018 name: ietf-service-assurance 1019 namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance 1020 prefix: sain 1021 reference: RFC XXXX 1023 name: ietf-service-assurance-device 1024 namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device 1025 prefix: sain-device 1026 reference: RFC XXXX 1028 name: ietf-service-assurance-interface 1029 namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface 1030 prefix: sain-interface 1031 reference: RFC XXXX 1033 All these modules are not maintained by IANA. 1035 8. References 1037 8.1. Normative References 1039 [I-D.ietf-opsawg-service-assurance-architecture] 1040 Claise, B., Quilbeuf, J., Lopez, D. R., Voyer, D., and T. 1041 Arumugam, "Service Assurance for Intent-based Networking 1042 Architecture", Work in Progress, Internet-Draft, draft- 1043 ietf-opsawg-service-assurance-architecture-05, 22 June 1044 2022, . 1047 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1048 Requirement Levels", BCP 14, RFC 2119, 1049 DOI 10.17487/RFC2119, March 1997, 1050 . 1052 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1053 DOI 10.17487/RFC3688, January 2004, 1054 . 1056 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1057 and A. Bierman, Ed., "Network Configuration Protocol 1058 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1059 . 1061 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1062 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1063 . 1065 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1066 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1067 . 1069 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1070 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1071 . 1073 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1074 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1075 May 2017, . 1077 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1078 Access Control Model", STD 91, RFC 8341, 1079 DOI 10.17487/RFC8341, March 2018, 1080 . 1082 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1083 and R. Wilton, "Network Management Datastore Architecture 1084 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1085 . 1087 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1088 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1089 . 1091 8.2. Informative References 1093 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 1094 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 1095 . 1097 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1098 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1099 . 1101 Appendix A. Vendor-specific Subservice Augmentation: example-service- 1102 assurance-device-acme YANG module 1104 A.1. Tree View 1106 The following tree diagram [RFC8340] provides an overview of the 1107 "example-service-assurance-device-acme" module. 1109 module: example-service-assurance-device-acme 1111 augment /sain:subservices/sain:subservice/sain:parameter: 1112 +--rw parameters 1113 +--rw device string 1114 +--rw acme-specific-parameter string 1116 A complete tree view of the base module with all augmenting modules 1117 presented in this draft is available in Appendix B.3. 1119 A.2. Concepts 1121 Under some circumstances, vendor-specific subservice types might be 1122 required. As an example of this vendor-specific implementation, this 1123 section shows how to augment the "ietf-service-assurance-device" 1124 module to add custom support for the device subservice, specific to 1125 the ACME Corporation. The specific version adds a new parameter, 1126 named "acme-specific-parameter". 1128 A.3. YANG Module 1129 module example-service-assurance-device-acme { 1130 yang-version 1.1; 1131 namespace "urn:example:example-service-assurance-device-acme"; 1132 prefix example-device-acme; 1134 import ietf-service-assurance { 1135 prefix sain; 1136 reference 1137 "RFC xxxx: YANG Modules for Service Assurance"; 1138 } 1139 import ietf-service-assurance-device { 1140 prefix sain-device; 1141 reference 1142 "RFC xxxx: YANG Modules for Service Assurance"; 1143 } 1145 organization 1146 "IETF OPSAWG Working Group"; 1147 contact 1148 "WG Web: 1149 WG List: 1150 Author: Benoit Claise 1151 Author: Jean Quilbeuf "; 1152 description 1153 "This module extends the ietf-service-assurance-device module to 1154 add specific support for devices of ACME Corporation. 1156 Copyright (c) 2022 IETF Trust and the persons identified as 1157 authors of the code. All rights reserved. 1159 Redistribution and use in source and binary forms, with or 1160 without modification, is permitted pursuant to, and subject 1161 to the license terms contained in, the Revised BSD License 1162 set forth in Section 4.c of the IETF Trust's Legal Provisions 1163 Relating to IETF Documents 1164 (https://trustee.ietf.org/license-info). 1166 This version of this YANG module is part of RFC XXXX; see the 1167 RFC itself for full legal notices. "; 1169 revision 2022-06-23 { 1170 description 1171 "Initial revision"; 1172 reference 1173 "RFC xxxx: YANG Modules for Service Assurance"; 1174 } 1176 identity device-acme-idty { 1177 base sain-device:device-idty; 1178 description 1179 "Network Device is healthy."; 1180 } 1182 augment "/sain:subservices/sain:subservice/sain:parameter" { 1183 when "derived-from-or-self(sain:type, 'device-acme-idty')"; 1184 description 1185 "Augments the parameter choice from ietf-service-assurance 1186 module with a case specific to the device-acme subservice."; 1187 container parameters { 1188 description 1189 "Parameters for the device-acme subservice type"; 1190 leaf device { 1191 type string; 1192 mandatory true; 1193 description 1194 "The device to monitor."; 1195 } 1196 leaf acme-specific-parameter { 1197 type string; 1198 mandatory true; 1199 description 1200 "The ACME Corporation specific parameter."; 1201 } 1202 } 1203 } 1204 } 1206 Appendix B. Further Augmentations: IP Connectivity and IS-IS 1207 subservices 1209 In this section, we provide two additional YANG modules to completely 1210 cover the example in Figure 2 from Section 3.1 of 1211 [I-D.ietf-opsawg-service-assurance-architecture]. These modules are 1212 presented as examples, some future work is needed to propose a more 1213 complete version. 1215 B.1. IP Connectivity Tree View 1217 That subservice represents the unicast connectivity between two IP 1218 addresses located on two different devices. Such a subservice could 1219 report symptoms such as "No route found". The following tree diagram 1220 [RFC8340] provides an overview of the "example-service-assurance-ip- 1221 connectivity" module. 1223 module: example-service-assurance-ip-connectivity 1225 augment /sain:subservices/sain:subservice/sain:parameter: 1226 +--rw parameters 1227 +--rw device1 string 1228 +--rw address1 inet:ip-address 1229 +--rw device2 string 1230 +--rw address2 inet:ip-address 1232 To specify the connectivity that we are interested in, we specify two 1233 IP addresses and two devices. The subservice assures that the 1234 connectivity between IP address 1 on device 1 and IP address 2 on 1235 device 2 is healthy. 1237 B.2. IS-IS Tree View 1239 The following tree diagram [RFC8340] provides an overview of the 1240 "example-service-assurance-is-is" module. 1242 module: example-service-assurance-is-is 1244 augment /sain:subservices/sain:subservice/sain:parameter: 1245 +--rw parameters 1246 +--rw instance-name string 1248 The parameter of this subservice is the name of the IS-IS instance to 1249 assure. 1251 B.3. Global Tree View 1253 The following tree diagram [RFC8340] provides an overview of the 1254 "ietf-service-assurance", "ietf-service-assurance-device", "example- 1255 service-assurance-device-acme", "example-service-assurance-ip- 1256 connectivity" and "example-service-assurance-is-is" modules. 1258 module: ietf-service-assurance 1259 +--ro assurance-graph-version yang:counter64 1260 +--ro assurance-graph-last-change yang:date-and-time 1261 +--rw subservices 1262 +--rw subservice* [type id] 1263 +--rw type identityref 1264 +--rw id string 1265 +--ro last-change? 1266 | yang:date-and-time 1267 +--ro label? string 1268 +--rw under-maintenance? boolean 1269 +--rw maintenance-contact string 1270 +--rw (parameter) 1271 | +--:(service-instance-parameter) 1272 | | +--rw service-instance-parameter 1273 | | +--rw service string 1274 | | +--rw instance-name string 1275 | +--:(example-ip-connectivity:parameters) 1276 | | +--rw example-ip-connectivity:parameters 1277 | | +--rw example-ip-connectivity:device1 string 1278 | | +--rw example-ip-connectivity:address1 1279 | | | inet:ip-address 1280 | | +--rw example-ip-connectivity:device2 string 1281 | | +--rw example-ip-connectivity:address2 1282 | | inet:ip-address 1283 | +--:(example-is-is:parameters) 1284 | | +--rw example-is-is:parameters 1285 | | +--rw example-is-is:instance-name string 1286 | +--:(sain-device:parameters) 1287 | | +--rw sain-device:parameters 1288 | | +--rw sain-device:device string 1289 | +--:(example-device-acme:parameters) 1290 | | +--rw example-device-acme:parameters 1291 | | +--rw example-device-acme:device 1292 | | | string 1293 | | +--rw example-device-acme:acme-specific-parameter 1294 | | string 1295 | +--:(sain-interface:parameters) 1296 | +--rw sain-interface:parameters 1297 | +--rw sain-interface:device string 1298 | +--rw sain-interface:interface string 1299 +--ro health-score? union 1300 +--ro symptoms-history-start? 1301 | yang:date-and-time 1302 +--ro symptoms 1303 | +--ro symptom* [start-date-time id] 1304 | +--ro id string 1305 | +--ro health-score-weight? uint8 1306 | +--ro description? string 1307 | +--ro start-date-time yang:date-and-time 1308 | +--ro stop-date-time? yang:date-and-time 1309 +--rw dependencies 1310 +--rw dependency* [type id] 1311 +--rw type 1312 | -> /subservices/subservice/type 1313 +--rw id leafref 1314 +--rw dependency-type? identityref 1316 B.4. IP Connectivity YANG Module 1318 module example-service-assurance-ip-connectivity { 1319 yang-version 1.1; 1320 namespace "urn:example:example-service-assurance-ip-connectivity"; 1321 prefix example-ip-connectivity; 1323 import ietf-inet-types { 1324 prefix inet; 1325 reference 1326 "RFC 6991: Common YANG Data Types"; 1327 } 1328 import ietf-service-assurance { 1329 prefix sain; 1330 reference 1331 "RFC xxxx: YANG Modules for Service Assurance"; 1332 } 1334 organization 1335 "IETF OPSAWG Working Group"; 1336 contact 1337 "WG Web: 1338 WG List: 1339 Author: Benoit Claise 1340 Author: Jean Quilbeuf "; 1341 description 1342 "This example module augments the ietf-service-assurance module to 1343 add support for the subservice ip-connectivity. 1345 Checks whether the ip connectivity between two ip addresses 1346 belonging to two network devices is healthy. 1348 Copyright (c) 2022 IETF Trust and the persons identified as 1349 authors of the code. All rights reserved. 1350 Redistribution and use in source and binary forms, with or 1351 without modification, is permitted pursuant to, and subject 1352 to the license terms contained in, the Revised BSD License 1353 set forth in Section 4.c of the IETF Trust's Legal Provisions 1354 Relating to IETF Documents 1355 (https://trustee.ietf.org/license-info). 1357 This version of this YANG module is part of RFC XXXX; see the 1358 RFC itself for full legal notices. "; 1360 revision 2022-06-23 { 1361 description 1362 "Initial version"; 1363 reference 1364 "RFC xxxx: YANG Modules for Service Assurance"; 1365 } 1367 identity ip-connectivity-idty { 1368 base sain:subservice-idty; 1369 description 1370 "Checks connectivity between two IP addresses."; 1371 } 1373 augment "/sain:subservices/sain:subservice/sain:parameter" { 1374 when "derived-from-or-self(sain:type, 'ip-connectivity-idty')"; 1375 description 1376 "Augments the parameter choice from ietf-service-assurance 1377 module with a case specific to the ip-connectivity 1378 subservice."; 1379 container parameters { 1380 description 1381 "Parameters for the ip-connectivity subservice type"; 1382 leaf device1 { 1383 type string; 1384 mandatory true; 1385 description 1386 "Device at the first end of the connection."; 1387 } 1388 leaf address1 { 1389 type inet:ip-address; 1390 mandatory true; 1391 description 1392 "Address at the first end of the connection."; 1393 } 1394 leaf device2 { 1395 type string; 1396 mandatory true; 1397 description 1398 "Device at the second end of the connection."; 1399 } 1400 leaf address2 { 1401 type inet:ip-address; 1402 mandatory true; 1403 description 1404 "Address at the second end of the connection."; 1405 } 1406 } 1407 } 1408 } 1410 B.5. IS-IS YANG Module 1412 module example-service-assurance-is-is { 1413 yang-version 1.1; 1414 namespace "urn:example:example-service-assurance-is-is"; 1415 prefix example-is-is; 1417 import ietf-service-assurance { 1418 prefix sain; 1419 reference 1420 "RFC xxxx: YANG Modules for Service Assurance"; 1421 } 1423 organization 1424 "IETF OPSAWG Working Group"; 1425 contact 1426 "WG Web: 1427 WG List: 1428 Author: Benoit Claise 1429 Author: Jean Quilbeuf "; 1430 description 1431 "This example module augments the ietf-service-assurance module to 1432 add support for the subservice is-is. 1434 Checks whether an IS-IS instance is healthy. 1436 Copyright (c) 2022 IETF Trust and the persons identified as 1437 authors of the code. All rights reserved. 1439 Redistribution and use in source and binary forms, with or 1440 without modification, is permitted pursuant to, and subject 1441 to the license terms contained in, the Revised BSD License 1442 set forth in Section 4.c of the IETF Trust's Legal Provisions 1443 Relating to IETF Documents 1444 (https://trustee.ietf.org/license-info). 1445 This version of this YANG module is part of RFC XXXX; see the 1446 RFC itself for full legal notices. "; 1448 revision 2022-06-23 { 1449 description 1450 "Initial version"; 1451 reference 1452 "RFC xxxx: YANG Modules for Service Assurance"; 1453 } 1455 identity is-is-idty { 1456 base sain:subservice-idty; 1457 description 1458 "Health of IS-IS routing protocol."; 1459 } 1461 augment "/sain:subservices/sain:subservice/sain:parameter" { 1462 when "derived-from-or-self(sain:type, 'is-is-idty')"; 1463 description 1464 "Augments the parameter choice from ietf-service-assurance 1465 module with a case specific to the is-is subservice."; 1466 container parameters { 1467 description 1468 "Parameters for the is-is subservice type."; 1469 leaf instance-name { 1470 type string; 1471 mandatory true; 1472 description 1473 "The instance to monitor."; 1474 } 1475 } 1476 } 1477 } 1479 Appendix C. Example of YANG instances 1481 This section contains examples of YANG instances that conform to the 1482 YANG modules. The validity of these data instances has been checked 1483 using yangson (https://yangson.labs.nic.cz/). Yangson requires a 1484 YANG library [RFC7895] to define the complete model against which the 1485 data instance must be validated. We provide in Appendix D the JSON 1486 library file, named "ietf-service-assurance-library.json", that we 1487 used for validation. 1489 We provide below the contents of the file 1490 "example_configuration_instance.json" which contains the 1491 configuration data that models the Figure 2 from Section 3.1 of 1492 [I-D.ietf-opsawg-service-assurance-architecture]. The instance can 1493 be validated with yangson by using the invocation "yangson -v 1494 example_configuration_instance.json ietf-service-assurance- 1495 library.json", assuming all the files (YANG and JSON) defined in this 1496 draft reside in the current folder. 1498 { 1499 "ietf-service-assurance:subservices": { 1500 "subservice": [ 1501 { 1502 "type": "service-instance-idty", 1503 "id": "simple-tunnel/example", 1504 "service-instance-parameter": { 1505 "service": "simple-tunnel", 1506 "instance-name": "example" 1507 }, 1508 "dependencies": { 1509 "dependency": [ 1510 { 1511 "type": "ietf-service-assurance-interface:interface-idty", 1512 "id": "interface/peer1/tunnel0", 1513 "dependency-type": "impacting" 1514 }, 1515 { 1516 "type": "ietf-service-assurance-interface:interface-idty", 1517 "id": "interface/peer2/tunnel9", 1518 "dependency-type": "impacting" 1519 }, 1520 { 1521 "type": 1522 "example-service-assurance-ip-connectivity:ip-connectivity-idty", 1523 "id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2", 1524 "dependency-type": "impacting" 1525 } 1526 ] 1527 } 1528 }, 1529 { 1530 "type": 1531 "example-service-assurance-ip-connectivity:ip-connectivity-idty", 1532 "id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2", 1533 "example-service-assurance-ip-connectivity:parameters": { 1534 "device1": "Peer1", 1535 "address1": "2001:db8::1", 1536 "device2": "Peer2", 1537 "address2": "2001:db8::2" 1538 }, 1539 "dependencies": { 1540 "dependency": [ 1541 { 1542 "type": "ietf-service-assurance-interface:interface-idty", 1543 "id": "interface/peer1/physical0", 1544 "dependency-type": "impacting" 1545 }, 1546 { 1547 "type": "ietf-service-assurance-interface:interface-idty", 1548 "id": "interface/peer2/physical5", 1549 "dependency-type": "impacting" 1550 }, 1551 { 1552 "type": "example-service-assurance-is-is:is-is-idty", 1553 "id": "is-is/instance1", 1554 "dependency-type": "impacting" 1555 } 1556 ] 1557 } 1558 }, 1559 { 1560 "type": "example-service-assurance-is-is:is-is-idty", 1561 "id": "is-is/instance1", 1562 "example-service-assurance-is-is:parameters": { 1563 "instance-name": "instance1" 1564 } 1565 }, 1566 { 1567 "type": "ietf-service-assurance-interface:interface-idty", 1568 "id": "interface/peer1/tunnel0", 1569 "ietf-service-assurance-interface:parameters": { 1570 "device": "Peer1", 1571 "interface": "tunnel0" 1572 }, 1573 "dependencies": { 1574 "dependency": [ 1575 { 1576 "type": "ietf-service-assurance-interface:interface-idty", 1577 "id": "interface/peer1/physical0", 1578 "dependency-type": "impacting" 1579 } 1580 ] 1581 } 1582 }, 1583 { 1584 "type": "ietf-service-assurance-interface:interface-idty", 1585 "id": "interface/peer1/physical0", 1586 "ietf-service-assurance-interface:parameters": { 1587 "device": "Peer1", 1588 "interface": "physical0" 1589 }, 1590 "dependencies": { 1591 "dependency": [ 1592 { 1593 "type": "ietf-service-assurance-device:device-idty", 1594 "id": "interface/peer1", 1595 "dependency-type": "impacting" 1596 } 1597 ] 1598 } 1599 }, 1600 { 1601 "type": "ietf-service-assurance-device:device-idty", 1602 "id": "interface/peer1", 1603 "ietf-service-assurance-device:parameters": { 1604 "device": "Peer1" 1605 } 1606 }, 1607 { 1608 "type": "ietf-service-assurance-interface:interface-idty", 1609 "id": "interface/peer2/tunnel9", 1610 "ietf-service-assurance-interface:parameters": { 1611 "device": "Peer2", 1612 "interface": "tunnel9" 1613 }, 1614 "dependencies": { 1615 "dependency": [ 1616 { 1617 "type": "ietf-service-assurance-interface:interface-idty", 1618 "id": "interface/peer2/physical5", 1619 "dependency-type": "impacting" 1620 } 1621 ] 1622 } 1623 }, 1624 { 1625 "type": "ietf-service-assurance-interface:interface-idty", 1626 "id": "interface/peer2/physical5", 1627 "ietf-service-assurance-interface:parameters": { 1628 "device": "Peer2", 1629 "interface": "physical5" 1630 }, 1631 "dependencies": { 1632 "dependency": [ 1633 { 1634 "type": "ietf-service-assurance-device:device-idty", 1635 "id": "interface/peer2", 1636 "dependency-type": "impacting" 1637 } 1638 ] 1639 } 1640 }, 1641 { 1642 "type": "ietf-service-assurance-device:device-idty", 1643 "id": "interface/peer2", 1644 "ietf-service-assurance-device:parameters": { 1645 "device": "Peer2" 1646 } 1647 } 1648 ] 1650 } 1651 } 1653 Appendix D. YANG Library for Service Assurance 1655 This section provides the JSON encoding of the YANG library [RFC7895] 1656 listing all modules defined in this draft and their dependencies. 1657 This library can be used to validate data instances using yangson, as 1658 explained in the previous section. 1660 { 1661 "ietf-yang-library:modules-state": { 1662 "module-set-id": "ietf-service-assurance@2022-04-07", 1663 "module": [ 1664 { 1665 "name": "ietf-service-assurance", 1666 "namespace": 1667 "urn:ietf:params:xml:ns:yang:ietf-service-assurance", 1668 "revision": "2022-06-23", 1669 "conformance-type": "implement" 1670 }, 1671 { 1672 "name": "ietf-service-assurance-device", 1673 "namespace": 1674 "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device", 1675 "revision": "2022-06-23", 1676 "conformance-type": "implement" 1677 }, 1678 { 1679 "name": "ietf-service-assurance-interface", 1680 "namespace": 1681 "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface", 1682 "revision": "2022-06-23", 1683 "conformance-type": "implement" 1684 }, 1685 { 1686 "name": "example-service-assurance-device-acme", 1687 "namespace": 1688 "urn:example:example-service-assurance-device-acme", 1689 "revision": "2022-06-23", 1690 "conformance-type": "implement" 1691 }, 1692 { 1693 "name": "example-service-assurance-is-is", 1694 "namespace": "urn:example:example-service-assurance-is-is", 1695 "revision": "2022-06-23", 1696 "conformance-type": "implement" 1697 }, 1698 { 1699 "name": "example-service-assurance-ip-connectivity", 1700 "namespace": 1701 "urn:example:example-service-assurance-ip-connectivity", 1702 "revision": "2022-06-23", 1703 "conformance-type": "implement" 1704 }, 1705 { 1706 "name": "ietf-yang-types", 1707 "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1708 "revision": "2021-04-14", 1709 "conformance-type": "import" 1710 }, 1711 { 1712 "name": "ietf-inet-types", 1713 "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1714 "revision": "2021-02-22", 1715 "conformance-type": "import" 1716 } 1717 ] 1718 } 1719 } 1721 Appendix E. Changes between revisions 1723 v05 - v06 1725 * Remove revision history in modules 1727 * Present elements in order of the tree for the main module 1729 * Rewriting and rewording for clarity 1731 * Made parameters mandatory for the subservices 1733 v04 - v05 1735 * Remove Guidelines section 1737 * Move informative parts (examples) to appendix 1739 * Minor text edits and reformulations 1741 v03 - v04 1742 * Fix YANG errors 1744 * Change is-is and ip-connectivity subservices from ietf to example. 1746 * Mention that models are NMDA compliant 1748 * Fix typos, reformulate for clarity 1750 v02 - v03 1752 * Change counter32 to counter64 to avoid resetting too frequently 1754 * Explain why relation between health-score and symptom's health- 1755 score-weight is not defined and how it could be defined 1757 v01 - v02 1759 * Explicitly represent the fact that the health-score could not be 1760 computed (value -1) 1762 v00 - v01 1764 * Added needed subservice to model example from architecture draft 1766 * Added guideline section for naming models 1768 * Added data instance examples and validation procedure 1770 * Added the "parameters" container in the interface YANG module to 1771 correct a bug. 1773 Acknowledgements 1775 The authors would like to thank Jan Lindblad for his help during the 1776 design of these YANG modules. The authors would like to thank 1777 Stephane Litkowski, Charles Eckel, Mohamed Boucadair and Tom Petch 1778 for their reviews. 1780 Authors' Addresses 1782 Benoit Claise 1783 Huawei 1784 Email: benoit.claise@huawei.com 1786 Jean Quilbeuf 1787 Huawei 1788 Email: jean.quilbeuf@huawei.com 1789 Paolo Lucente 1790 NTT 1791 Siriusdreef 70-72 1792 2132 Hoofddorp 1793 Netherlands 1794 Email: paolo@ntt.net 1796 Paolo Fasano 1797 TIM S.p.A 1798 via G. Reiss Romoli, 274 1799 10148 Torino 1800 Italy 1801 Email: paolo2.fasano@telecomitalia.it 1803 Thangam Arumugam 1804 Cisco Systems, Inc. 1805 Milpitas (California), 1806 United States 1807 Email: tarumuga@cisco.com