idnits 2.17.1 draft-ietf-opsawg-service-assurance-yang-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 109 instances of too long lines in the document, the longest one being 29 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 183 has weird spacing: '...-change yan...' == Line 196 has weird spacing: '...ce-name str...' == Line 655 has weird spacing: '... device str...' == Line 664 has weird spacing: '...-change yan...' == Line 677 has weird spacing: '...ce-name str...' == (19 more instances...) -- The document date (4 January 2022) is 842 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) ** Downref: Normative reference to an Informational draft: draft-claise-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: 2 errors (**), 0 flaws (~~), 7 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: 8 July 2022 P. Lucente 6 NTT 7 P. Fasano 8 TIM S.p.A 9 T. Arumugam 10 Cisco Systems, Inc. 11 4 January 2022 13 YANG Modules for Service Assurance 14 draft-ietf-opsawg-service-assurance-yang-02 16 Abstract 18 This document proposes YANG modules for the Service Assurance for 19 Intent-based Networking Architecture. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 8 July 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. YANG Models Overview . . . . . . . . . . . . . . . . . . . . 3 57 4. Base ietf-service-assurance YANG module . . . . . . . . . . . 4 58 4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7 61 5. Subservice Extension: ietf-service-assurance-device YANG 62 module . . . . . . . . . . . . . . . . . . . . . . . . . 14 63 5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 14 64 5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 15 65 5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 16 66 5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 16 67 6. Subservice Extension: ietf-service-assurance-interface YANG 68 module . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 18 70 6.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 18 71 6.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 19 72 6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 20 73 7. Vendor-specific Subservice Extension: 74 example-service-assurance-device-acme YANG module . . . . 22 75 7.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 22 76 7.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 22 77 7.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 24 78 7.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 24 79 8. Further Extensions: IP Connectivity and IS-IS subservices . . 26 80 8.1. IP Connectivity Tree View . . . . . . . . . . . . . . . . 26 81 8.2. IS-IS Tree View . . . . . . . . . . . . . . . . . . . . . 26 82 8.3. Global Tree View . . . . . . . . . . . . . . . . . . . . 27 83 8.4. IP Connectivity YANG Module . . . . . . . . . . . . . . . 28 84 8.5. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . 30 85 9. Guidelines for Specific Subservice Extension . . . . . . . . 32 86 9.1. Module Name . . . . . . . . . . . . . . . . . . . . . . . 32 87 9.2. Module Namespace . . . . . . . . . . . . . . . . . . . . 32 88 9.3. Module Prefix . . . . . . . . . . . . . . . . . . . . . . 33 89 9.4. Subservice Specific Identity . . . . . . . . . . . . . . 33 90 9.5. Parameters . . . . . . . . . . . . . . . . . . . . . . . 33 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 93 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 94 11.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 34 95 11.2. The YANG Module Names Registry . . . . . . . . . . . . . 34 96 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35 97 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 98 13.1. Normative References . . . . . . . . . . . . . . . . . . 35 99 13.2. Informative References . . . . . . . . . . . . . . . . . 36 100 Appendix A. Example of YANG instances . . . . . . . . . . . . . 36 101 Appendix B. YANG Library for Service Assurance . . . . . . . . . 40 102 Appendix C. Changes between revisions . . . . . . . . . . . . . 41 103 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 42 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 106 1. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 The terms used in this document are defined in 115 [I-D.ietf-opsawg-service-assurance-architecture] 117 2. Introduction 119 The "Service Assurance for Intent-based Networking Architecture" 120 draft-ietf-opsawg-service-assurance-architecture, specifies the 121 architecture and all of its components for service assurance. This 122 document complements the architecture by providing open interfaces 123 between components. More specifically, the goal is to provide YANG 124 modules for the purpose of service assurance in a format that is: 126 * machine readable 128 * vendor independent 130 * augmentable 132 3. YANG Models Overview 134 The main YANG module, ietf-service-assurance, defines objects for 135 assuring network services based on their decomposition into so-called 136 subservices. The subservices are hierarchically organised by 137 dependencies. The subservices, along with the dependencies, 138 constitute an assurance graph. This module should be supported by an 139 agent, able to interact with the devices in order to produce a health 140 status and symptoms for each subservice in the assurance graph. This 141 module is intended for the following use cases: 143 * Assurance graph configuration: 145 - Subservices: configure a set of subservices to assure, by 146 specifying their types and parameters. 148 - Dependencies: configure the dependencies between the 149 subservices, along with their type. 151 * Assurance telemetry: export the health status of the subservices, 152 along with the observed symptoms. 154 The second YANG module, ietf-service-assurance-device, extends the 155 ietf-service-assurance module to add support for the subservice 156 DeviceHealthy. Additional subservice types might be added the same 157 way. 159 The third YANG module, ietf-service-assurance-device, is another 160 example that extends the ietf-service-assurance-device module. This 161 extension adds support for the subservice InterfaceHealthy. 163 The fourth YANG module, example-service-assurance-device-acme, 164 extends the ietf-service-assurance-device module as an example to add 165 support for the subservice DeviceHealthy, with specifics for the 166 fictional ACME Corporation. Additional vendor-specific parameters 167 might be added the same way. 169 Finally, the modules ietf-service-assurance-ip-connectivity and ietf- 170 service-assurance-is-is are provided to completely model the example 171 from the SAIN architecture draft 172 [I-D.ietf-opsawg-service-assurance-architecture]. 174 4. Base ietf-service-assurance YANG module 176 4.1. Tree View 178 The following tree diagram [RFC8340] provides an overview of the 179 ietf-service-assurance data model. 181 module: ietf-service-assurance 182 +--ro assurance-graph-version yang:counter32 183 +--ro assurance-graph-last-change yang:date-and-time 184 +--rw subservices 185 +--rw subservice* [type id] 186 +--rw type identityref 187 +--rw id string 188 +--ro last-change? yang:date-and-time 189 +--ro label? string 190 +--rw under-maintenance? boolean 191 +--rw maintenance-contact string 192 +--rw (parameter)? 193 | +--:(service-instance-parameter) 194 | +--rw service-instance-parameter 195 | +--rw service string 196 | +--rw instance-name string 197 +--ro health-score? union 198 +--ro symptoms-history-start? yang:date-and-time 199 +--rw symptoms 200 | +--ro symptom* [start-date-time id] 201 | +--ro id string 202 | +--ro health-score-weight? uint8 203 | +--ro description? string 204 | +--ro start-date-time yang:date-and-time 205 | +--ro stop-date-time? yang:date-and-time 206 +--rw dependencies 207 +--rw dependency* [type id] 208 +--rw type -> /subservices/subservice/type 209 +--rw id -> /subservices/subservice[type=current()/../type]/id 210 +--rw dependency-type? identityref 212 4.2. Concepts 214 The ietf-service-assurance YANG model assumes an identified number of 215 subservices, to be assured independently. A subservice is a feature 216 or a subpart of the network system that a given service instance 217 might depend on. Example of subservices include: 219 * DeviceHealthy: whether a device is healthy, and if not, what are 220 the symptoms. Potential symptoms are "CPU overloaded", "Out of 221 RAM", or "Out of TCAM". 223 * ConnectivityHealthy: given two IP addresses owned by two devices, 224 what is the quality of the connection between them. Potential 225 symptoms are "No route available" or "ECMP Imbalance". 227 The first example is a subservice representing a subpart of the 228 network system, while the second is a subservice representing a 229 feature of the network, In both cases, these subservices might depend 230 on other subservices, for instance, the connectivity might depend on 231 a subservice representing the routing mechanism and on a subservice 232 representing ECMP. 234 The status of each subservice contains a list of symptoms. Each 235 symptom is specified by a unique id and contains a health-score- 236 weight (the impact to the health score incurred by this symptom), a 237 label (text describing what the symptom is), and dates and times at 238 which the symptom was detected and stopped being detected. While the 239 unique id is sufficient as an unique key list, the start-date-time 240 second key help sorting and retrieving relevant symptoms. 242 The assurance of a given service instance can be obtained by 243 composing the assurance of the subservices that it depends on, via 244 the dependency relations. 246 A subservice declaration MUST provide: 248 * A type: identity inheriting of the base identity for subservice, 250 * An id: string uniquely identifying the subservice among those with 251 the same identity, 253 * One or more parameters, which should be specified in an augmenting 254 model, as described in the next sections. 256 The type and id uniquely identify a given subservice. They are used 257 to indicate the dependencies. Dependencies have types as well. Two 258 types are specified in the model: 260 * Impacting: such a dependency indicates an impact on the health of 261 the dependent, 263 * Informational: such a dependency might explain why the dependent 264 has issues but does not impact its health. 266 To illustrate the difference between "impacting" and "informational", 267 consider the subservice InterfaceHealthy, representing a network 268 interface. If the device to which the network interface belongs goes 269 down, the network interface will transition to a down state as well. 270 Therefore, the dependency of InterfaceHealthy towards DeviceHealthy 271 is "impacting". On the other hand, as a the dependency towards the 272 ECMPLoad subservice, which checks that the load between ECMP remains 273 ce remains stable throughout time, is only "informational". Indeed, 274 services might be perfectly healthy even if the load distribution 275 between ECMP changed. However, such an instability might be a 276 relevant symptom for diagnosing the root cause of a problem. 278 Service instances MUST be modeled as a particular type of subservice 279 with two parameters, a type and an instance name. The type is the 280 name of the service defined in the network orchestrator, for instance 281 "point-to-point-l2vpn". The instance name is the name assigned to 282 the particular instance that we are assuring, for instance the name 283 of the customer using that instance. 285 The "under-maintenance" and "maintenance-contact" flags inhibit the 286 emission of symptoms for that subservice and subservices that depend 287 on them. See Section 3.7 of 288 [I-D.ietf-opsawg-service-assurance-architecture] for a more detailed 289 discussion. 291 By specifying service instances and their dependencies in terms of 292 subservices, one defines the whole assurance to apply for them. An 293 assurance agent supporting this model should then produce telemetry 294 in return with, for each subservice: a health-status indicating how 295 healthy the subservice is and when the subservice is not healthy, a 296 list of symptoms explaining why the subservice is not healthy. 298 4.3. YANG Module 300 file "ietf-service-assurance@2022-01-04.yang" 302 module ietf-service-assurance { 303 yang-version 1.1; 304 namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance"; 305 prefix service-assurance; 307 import ietf-yang-types { 308 prefix yang; 309 } 311 organization 312 "IETF NETCONF (Network Configuration) Working Group"; 313 contact 314 "WG Web: 315 WG List: 316 Author: Benoit Claise 317 Author: Jean Quilbeuf "; 318 description 319 "This module defines objects for assuring network services based on 320 their decomposition into so-called subservices, according to the SAIN 321 (Service Assurance for Intent-based Networking) architecture. 323 The subservices hierarchically organised by dependencies constitute an 324 assurance graph. This module should be supported by an assurance agent, 325 able to interact with the devices in order to produce a health status 326 and symptoms for each subservice in the assurance graph. 328 This module is intended for the following use cases: 329 * Assurance graph configuration: 330 * subservices: configure a set of subservices to assure, by specifying 331 their types and parameters. 332 * dependencies: configure the dependencies between the subservices, 333 along with their type. 334 * Assurance telemetry: export the health status of the subservices, along 335 with the observed symptoms. 337 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 338 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 339 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 340 are to be interpreted as described in BCP 14 (RFC 2119) 341 (RFC 8174) when, and only when, they appear in all 342 capitals, as shown here. 344 Copyright (c)2021 IETF Trust and the persons identified as 345 authors of the code. All rights reserved. 347 Redistribution and use in source and binary forms, with or 348 without modification, is permitted pursuant to, and subject 349 to the license terms contained in, the Simplified BSD License 350 set forth in Section 4.c of the IETF Trust's Legal Provisions 351 Relating to IETF Documents 352 (https://trustee.ietf.org/license-info). 354 This version of this YANG module is part of RFC XXXX; see the 355 RFC itself for full legal notices. 356 TO DO: 357 - Better type (IETF or OC) for device-id, interface-id, etc. 358 - Have a YANG module for IETF and one for OC?"; 360 revision 2022-01-04 { 361 description 362 "Explicitely model a missing value"; 363 reference 364 "RFC xxxx: Title to be completed"; 365 } 366 revision 2021-06-28 { 367 description 368 "Made service-instance parameters mandatory."; 369 reference 370 "RFC xxxx: Title to be completed"; 371 } 372 revision 2020-01-13 { 373 description 374 "Added the maintenance window concept."; 375 reference 376 "RFC xxxx: Title to be completed"; 377 } 378 revision 2019-11-16 { 379 description 380 "Initial revision."; 381 reference 382 "RFC xxxx: Title to be completed"; 383 } 385 identity subservice-idty { 386 description 387 "Root identity for all subservice types."; 388 } 390 identity service-instance-idty { 391 base subservice-idty; 392 description 393 "Identity representing a service instance."; 394 } 396 identity dependency-type { 397 description 398 "Base identity for representing dependency types."; 399 } 401 identity informational-dependency { 402 base dependency-type; 403 description 404 "Indicates that symptoms of the dependency might be of interest for the 405 dependent, but the status of the dependency should not have any 406 impact on the dependent."; 407 } 409 identity impacting-dependency { 410 base dependency-type; 411 description 412 "Indicates that the status of the dependency directly impacts the status 413 of the dependent."; 414 } 416 grouping symptom { 417 description 418 "Contains the list of symptoms for a specific subservice."; 419 leaf id { 420 type string; 421 description 422 "A unique identifier for the symptom."; 423 } 424 leaf health-score-weight { 425 type uint8 { 426 range "0 .. 100"; 427 } 428 description 429 "The weight to the health score incurred by this symptom. The higher the 430 value, the more of an impact this symptom has. If a subservice health 431 score is not 100, there must be at least one symptom with a health 432 score weight larger than 0."; 433 } 434 leaf description { 435 type string; 436 description 437 "Description of the symptom, i.e. text describing what the symptom is, to 438 be computer-consumable and be displayed on a human interface. "; 439 } 440 leaf start-date-time { 441 type yang:date-and-time; 442 description 443 "Date and time at which the symptom was detected."; 444 } 445 leaf stop-date-time { 446 type yang:date-and-time; 447 description 448 "Date and time at which the symptom stopped being detected."; 449 } 450 } 452 grouping subservice-dependency { 453 description 454 "Represent a dependency to another subservice."; 455 leaf type { 456 type leafref { 457 path "/subservices/subservice/type"; 459 } 460 description 461 "The type of the subservice to refer to (e.g. DeviceHealthy)."; 462 } 463 leaf id { 464 type leafref { 465 path "/subservices/subservice[type=current()/../type]/id"; 466 } 467 description 468 "The identifier of the subservice to refer to."; 469 } 470 leaf dependency-type { 471 type identityref { 472 base dependency-type; 473 } 474 description 475 "Represents the type of dependency (i.e. informational, impacting)."; 476 } 477 // augment here if more info are needed (i.e. a percentage) depending on the dependency type. 478 } 480 leaf assurance-graph-version { 481 type yang:counter32; 482 config false; 483 mandatory true; 484 description 485 "The assurance graph version, which increases by 1 for each new version, after the changes 486 (dependencies and/or maintenance windows parameters) are applied to the subservice(s)."; 487 } 488 leaf assurance-graph-last-change { 489 type yang:date-and-time; 490 config false; 491 mandatory true; 492 description 493 "Date and time at which the assurance graph last changed after the changes (dependencies 494 and/or maintenance windows parameters) are applied to the subservice(s). These date and time 495 must be more recent or equal compared to the more recent value of any changed subservices 496 last-change"; 497 } 498 container subservices { 499 description 500 "Root container for the subservices."; 501 list subservice { 502 key "type id"; 503 description 504 "List of subservice configured."; 505 leaf type { 506 type identityref { 507 base subservice-idty; 508 } 509 description 510 "Name of the subservice, e.g. DeviceHealthy."; 511 } 512 leaf id { 513 type string; 514 description 515 "Unique identifier of the subservice instance, for each type."; 516 } 517 leaf last-change { 518 type yang:date-and-time; 519 config false; 520 description 521 "Date and time at which the assurance graph for this subservice 522 instance last changed, i.e. dependencies and/or maintenance windows parameters."; 523 } 524 leaf label { 525 type string; 526 config false; 527 description 528 "Label of the subservice, i.e. text describing what the subservice is to 529 be displayed on a human interface."; 530 } 531 leaf under-maintenance { 532 type boolean; 533 default "false"; 534 description 535 "An optional flag indicating whether this particular subservice is under 536 maintenance. Under this circumstance, the subservice symptoms and the 537 symptoms of its dependencies in the assurance graph should not be taken 538 into account. Instead, the subservice should send a 'Under Maintenance' 539 single symptom. 541 The operator changing the under-maintenance value must set the 542 maintenance-contact variable. 544 When the subservice is not under maintenance any longer, the 545 under-maintenance flag must return to its default value and 546 the under-maintenance-owner variable deleted."; 547 } 548 leaf maintenance-contact { 549 when "../under-maintenance = 'true'"; 550 type string; 551 mandatory true; 552 description 553 "A string used to model an administratively assigned name of the 554 resource that changed the under-maintenance value to 'true. 556 It is suggested that this name contain one or more of the following: 557 IP address, management station name, network manager's name, location, 558 or phone number. In some cases the agent itself will be the owner of 559 an entry. In these cases, this string shall be set to a string 560 starting with 'monitor'."; 561 } 562 choice parameter { 563 description 564 "Specify the required parameters per subservice type."; 565 container service-instance-parameter { 566 when "derived-from-or-self(../type, 'service-assurance:service-instance-idty')"; 567 description 568 "Specify the parameters of a service instance."; 569 leaf service { 570 type string; 571 mandatory true; 572 description 573 "Name of the service."; 574 } 575 leaf instance-name { 576 type string; 577 mandatory true; 578 description 579 "Name of the instance for that service."; 580 } 581 } 582 // Other modules can augment their own cases into here 583 } 584 leaf health-score { 585 type union { 586 type uint8 { 587 range "0 .. 100"; 588 } 589 type enumeration { 590 enum missing { 591 value -1; 592 description 593 "Explictly represent the fact that the health score is 594 missing. This could be used when metrics crucial to 595 establish the health score are not collected anymore."; 596 } 597 } 598 } 599 config false; 600 description 601 "Score value of the subservice health. A value of 100 means that 602 subservice is healthy. A value of 0 means that the subservice is 603 broken. A value between 0 and 100 means that the subservice is 604 degraded."; 605 } 606 leaf symptoms-history-start { 607 type yang:date-and-time; 608 config false; 609 description 610 "Date and time at which the symptoms history starts for this 611 subservice instance, either because the subservice instance 612 started at that date and time or because the symptoms before that 613 were removed due to a garbage collection process."; 614 } 615 container symptoms { 616 description 617 "Symptoms for the subservice."; 618 list symptom { 619 key "start-date-time id"; 620 config false; 621 description 622 "List of symptoms the subservice. While the start-date-time key is not 623 necessary per se, this would get the entries sorted by start-date-time 624 for easy consumption."; 625 uses symptom; 626 } 627 } 628 container dependencies { 629 description 630 "configure the dependencies between the subservices, along with their types."; 631 list dependency { 632 key "type id"; 633 description 634 "List of soft dependencies of the subservice."; 635 uses subservice-dependency; 636 } 637 } 638 } 639 } 640 } 642 644 5. Subservice Extension: ietf-service-assurance-device YANG module 646 5.1. Tree View 648 The following tree diagram [RFC8340] provides an overview of the 649 ietf-service-assurance-device data model. 651 module: ietf-service-assurance-device 653 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: 654 +--rw parameters 655 +--rw device string 657 5.2. Complete Tree View 659 The following tree diagram [RFC8340] provides an overview of the 660 ietf-service-assurance and ietf-service-assurance-device data models. 662 module: ietf-service-assurance 663 +--ro assurance-graph-version yang:counter32 664 +--ro assurance-graph-last-change yang:date-and-time 665 +--rw subservices 666 +--rw subservice* [type id] 667 +--rw type identityref 668 +--rw id string 669 +--ro last-change? yang:date-and-time 670 +--ro label? string 671 +--rw under-maintenance? boolean 672 +--rw maintenance-contact string 673 +--rw (parameter)? 674 | +--:(service-instance-parameter) 675 | | +--rw service-instance-parameter 676 | | +--rw service string 677 | | +--rw instance-name string 678 | +--:(service-assurance-device:parameters) 679 | +--rw service-assurance-device:parameters 680 | +--rw service-assurance-device:device string 681 +--ro health-score? union 682 +--ro symptoms-history-start? yang:date-and-time 683 +--rw symptoms 684 | +--ro symptom* [start-date-time id] 685 | +--ro id string 686 | +--ro health-score-weight? uint8 687 | +--ro description? string 688 | +--ro start-date-time yang:date-and-time 689 | +--ro stop-date-time? yang:date-and-time 690 +--rw dependencies 691 +--rw dependency* [type id] 692 +--rw type -> /subservices/subservice/type 693 +--rw id -> /subservices/subservice[type=current()/../type]/id 694 +--rw dependency-type? identityref 696 5.3. Concepts 698 As the number of subservices will grow over time, the YANG module is 699 designed to be extensible. A new subservice type requires the 700 precise specifications of its type and expected parameters. Let us 701 illustrate the example of the new DeviceHealthy subservice type. As 702 the name implies, it monitors and reports the device health, along 703 with some symptoms in case of degradation. 705 For our DeviceHealthy subservice definition, the new identity device- 706 idty is specified, as an inheritance from the base identity for 707 subservices. This indicates to the assurance agent that we are now 708 assuring the health of a device. 710 The typical parameter for the configuration of the DeviceHealthy 711 subservice is the name of the device that we want to assure. By 712 augmenting the parameter choice from ietf-service-assurance YANG 713 module for the case of the device-idty subservice type, this new 714 parameter is specified. 716 5.4. YANG Module 718 file "ietf-service-assurance-device@2021-06-28.yang" 720 module ietf-service-assurance-device { 721 yang-version 1.1; 722 namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device"; 723 prefix service-assurance-device; 725 import ietf-service-assurance { 726 prefix service-assurance; 727 } 729 organization 730 "IETF NETCONF (Network Configuration) Working Group"; 731 contact 732 "WG Web: 733 WG List: 734 Author: Benoit Claise 735 Author: Jean Quilbeuf "; 736 description 737 "This module extends the ietf-service-assurance module to add 738 support for the subservice DeviceHealthy. 740 Checks whether a network device is healthy. 742 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 743 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 744 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 745 are to be interpreted as described in BCP 14 (RFC 2119) 746 (RFC 8174) when, and only when, they appear in all 747 capitals, as shown here. 749 Copyright (c) 2021 IETF Trust and the persons identified as 750 authors of the code. All rights reserved. 752 Redistribution and use in source and binary forms, with or 753 without modification, is permitted pursuant to, and subject 754 to the license terms contained in, the Simplified BSD License 755 set forth in Section 4.c of the IETF Trust's Legal Provisions 756 Relating to IETF Documents 757 (https://trustee.ietf.org/license-info). 758 This version of this YANG module is part of RFC XXXX; see the 759 RFC itself for full legal notices. "; 761 revision 2021-06-28 { 762 description 763 "Renamed the container for parameters."; 764 reference 765 "RFC xxxx: Title to be completed"; 766 } 767 revision 2020-01-13 { 768 description 769 "Added the maintenance window concept."; 770 reference 771 "RFC xxxx: Title to be completed"; 772 } 773 revision 2019-11-16 { 774 description 775 "Initial revision."; 776 reference 777 "RFC xxxx: Title to be completed"; 778 } 780 identity device-idty { 781 base service-assurance:subservice-idty; 782 description 783 "Network Device is healthy."; 784 } 786 augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" { 787 description 788 "Specify the required parameters for a new subservice type"; 789 container parameters { 790 when "derived-from-or-self(../service-assurance:type, 'device-idty')"; 791 description 792 "Specify the required parameters for the device-idty subservice type"; 793 leaf device { 794 type string; 795 mandatory true; 796 description 797 "The device to monitor."; 798 } 799 } 800 } 801 } 803 805 6. Subservice Extension: ietf-service-assurance-interface YANG module 807 6.1. Tree View 809 The following tree diagram [RFC8340] provides an overview of the 810 ietf-service-assurance-interface data model. 812 module: ietf-service-assurance-interface 814 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: 815 +--rw parameters 816 +--rw device string 817 +--rw interface string 819 6.2. Complete Tree View 821 The following tree diagram [RFC8340] provides an overview of the 822 ietf-service-assurance, ietf-service-assurance-device, and ietf- 823 service-assurance-interface data models. 825 module: ietf-service-assurance 826 +--ro assurance-graph-version yang:counter32 827 +--ro assurance-graph-last-change yang:date-and-time 828 +--rw subservices 829 +--rw subservice* [type id] 830 +--rw type identityref 831 +--rw id string 832 +--ro last-change? yang:date-and-time 833 +--ro label? string 834 +--rw under-maintenance? boolean 835 +--rw maintenance-contact string 836 +--rw (parameter)? 837 | +--:(service-instance-parameter) 838 | | +--rw service-instance-parameter 839 | | +--rw service string 840 | | +--rw instance-name string 841 | +--:(service-assurance-interface:parameters) 842 | | +--rw service-assurance-interface:parameters 843 | | +--rw service-assurance-interface:device string 844 | | +--rw service-assurance-interface:interface string 845 | +--:(service-assurance-device:parameters) 846 | +--rw service-assurance-device:parameters 847 | +--rw service-assurance-device:device string 848 +--ro health-score? union 849 +--ro symptoms-history-start? yang:date-and-time 850 +--rw symptoms 851 | +--ro symptom* [start-date-time id] 852 | +--ro id string 853 | +--ro health-score-weight? uint8 854 | +--ro description? string 855 | +--ro start-date-time yang:date-and-time 856 | +--ro stop-date-time? yang:date-and-time 857 +--rw dependencies 858 +--rw dependency* [type id] 859 +--rw type -> /subservices/subservice/type 860 +--rw id -> /subservices/subservice[type=current()/../type]/id 861 +--rw dependency-type? identityref 863 6.3. Concepts 865 For our InterfaceHealthy subservice definition, the new interface- 866 idty is specified, as an inheritance from the base identity for 867 subservices. This indicates to the assurance agent that we are now 868 assuring the health of an interface. 870 The typical parameters for the configuration of the InterfaceHealthy 871 subservice are the name of the device and, on that specific device, a 872 specific interface. By augmenting the parameter choice from ietf- 873 service-assurance YANG module for the case of the interface-idty 874 subservice type, those two new parameter are specified. 876 6.4. YANG Module 878 file "ietf-service-assurance-interface@2021-06-28.yang" 880 module ietf-service-assurance-interface { 881 yang-version 1.1; 882 namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface"; 883 prefix service-assurance-interface; 885 import ietf-service-assurance { 886 prefix service-assurance; 887 } 889 organization 890 "IETF OPSAWG Working Group"; 891 contact 892 "WG Web: 893 WG List: 894 Author: Benoit Claise 895 Author: Jean Quilbeuf "; 896 description 897 "This module extends the ietf-service-assurance module to add 898 support for the subservice InterfaceHealthy. 900 Checks whether an interface is healthy. 902 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 903 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 904 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 905 are to be interpreted as described in BCP 14 (RFC 2119) 906 (RFC 8174) when, and only when, they appear in all 907 capitals, as shown here. 909 Copyright (c) 2021 IETF Trust and the persons identified as 910 authors of the code. All rights reserved. 911 Redistribution and use in source and binary forms, with or 912 without modification, is permitted pursuant to, and subject 913 to the license terms contained in, the Simplified BSD License 914 set forth in Section 4.c of the IETF Trust's Legal Provisions 915 Relating to IETF Documents 916 (https://trustee.ietf.org/license-info). 918 This version of this YANG module is part of RFC XXXX; see the 919 RFC itself for full legal notices. "; 921 revision 2021-06-28 { 922 description 923 "Regroup parameters in a container."; 924 reference 925 "RFC xxxx: Title to be completed"; 926 } 927 revision 2020-01-13 { 928 description 929 "Initial revision."; 930 reference 931 "RFC xxxx: Title to be completed"; 932 } 934 identity interface-idty { 935 base service-assurance:subservice-idty; 936 description 937 "Checks whether an interface is healthy."; 938 } 940 augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" { 941 description 942 "Specify the required parameters for the interface-idty subservice type"; 943 container parameters { 944 when "derived-from-or-self(../service-assurance:type, 'interface-idty')"; 945 description 946 "Required parameters for the interface-idty subservice type"; 947 leaf device { 948 type string; 949 mandatory true; 950 description 951 "Device supporting the interface."; 952 } 953 leaf interface { 954 type string; 955 mandatory true; 956 description 957 "Name of the interface."; 958 } 959 } 960 } 961 } 963 965 7. Vendor-specific Subservice Extension: example-service-assurance- 966 device-acme YANG module 968 7.1. Tree View 970 The following tree diagram [RFC8340] provides an overview of the 971 example-service-assurance-device-acme data model. 973 module: example-service-assurance-device-acme 975 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: 976 +--rw parameters 977 +--rw device string 978 +--rw acme-specific-parameter string 980 7.2. Complete Tree View 982 The following tree diagram [RFC8340] provides an overview of the 983 ietf-service-assurance, ietf-service-assurance-device, and example- 984 service-assurance-device-acme data models. 986 module: ietf-service-assurance 987 +--ro assurance-graph-version yang:counter32 988 +--ro assurance-graph-last-change yang:date-and-time 989 +--rw subservices 990 +--rw subservice* [type id] 991 +--rw type identityref 992 +--rw id string 993 +--ro last-change? yang:date-and-time 994 +--ro label? string 995 +--rw under-maintenance? boolean 996 +--rw maintenance-contact string 997 +--rw (parameter)? 998 | +--:(service-instance-parameter) 999 | | +--rw service-instance-parameter 1000 | | +--rw service string 1001 | | +--rw instance-name string 1002 | +--:(service-assurance-device:parameters) 1003 | | +--rw service-assurance-device:parameters 1004 | | +--rw service-assurance-device:device string 1005 | +--:(example-service-assurance-device-acme:parameters) 1006 | | +--rw example-service-assurance-device-acme:parameters 1007 | | +--rw example-service-assurance-device-acme:device string 1008 | | +--rw example-service-assurance-device-acme:acme-specific-parameter string 1009 | +--:(service-assurance-interface:parameters) 1010 | +--rw service-assurance-interface:parameters 1011 | +--rw service-assurance-interface:device string 1012 | +--rw service-assurance-interface:interface string 1013 +--ro health-score? union 1014 +--ro symptoms-history-start? yang:date-and-time 1015 +--rw symptoms 1016 | +--ro symptom* [start-date-time id] 1017 | +--ro id string 1018 | +--ro health-score-weight? uint8 1019 | +--ro description? string 1020 | +--ro start-date-time yang:date-and-time 1021 | +--ro stop-date-time? yang:date-and-time 1022 +--rw dependencies 1023 +--rw dependency* [type id] 1024 +--rw type -> /subservices/subservice/type 1025 +--rw id -> /subservices/subservice[type=current()/../type]/id 1026 +--rw dependency-type? identityref 1028 7.3. Concepts 1030 Under some circumstances, vendor-specific subservice types might be 1031 required. As an example of this vendor-specific implementation, this 1032 section shows how to augment the ietf-service-assurance-device module 1033 to add support for the subservice DeviceHealthy, specific to the ACME 1034 Corporation. The new parameter is acme-specific-parameter. 1036 7.4. YANG Module 1038 module example-service-assurance-device-acme { 1039 yang-version 1.1; 1040 namespace "urn:example:example-service-assurance-device-acme"; 1041 prefix example-service-assurance-device-acme; 1043 import ietf-service-assurance { 1044 prefix service-assurance; 1045 } 1046 import ietf-service-assurance-device { 1047 prefix service-assurance-device; 1048 } 1050 organization 1051 "IETF NETCONF (Network Configuration) Working Group"; 1052 contact 1053 "WG Web: 1054 WG List: 1055 Author: Benoit Claise 1056 Author: Jean Quilbeuf "; 1057 description 1058 "This module extends the ietf-service-assurance-device module to add 1059 support for the subservice DeviceHealthy, specific to the ACME Corporation. 1061 ACME Network Device is healthy. 1063 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1064 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1065 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1066 are to be interpreted as described in BCP 14 (RFC 2119) 1067 (RFC 8174) when, and only when, they appear in all 1068 capitals, as shown here. 1070 Copyright (c) 2021 IETF Trust and the persons identified as 1071 authors of the code. All rights reserved. 1073 Redistribution and use in source and binary forms, with or 1074 without modification, is permitted pursuant to, and subject 1075 to the license terms contained in, the Simplified BSD License 1076 set forth in Section 4.c of the IETF Trust's Legal Provisions 1077 Relating to IETF Documents 1078 (https://trustee.ietf.org/license-info). 1080 This version of this YANG module is part of RFC XXXX; see the 1081 RFC itself for full legal notices. "; 1083 revision 2021-06-28 { 1084 description 1085 "Renamed the parameters container."; 1086 reference 1087 "RFC xxxx: Title to be completed"; 1088 } 1089 revision 2020-01-13 { 1090 description 1091 "Added the maintenance window concept."; 1092 reference 1093 "RFC xxxx: Title to be completed"; 1094 } 1095 revision 2019-11-16 { 1096 description 1097 "Initial revision."; 1098 reference 1099 "RFC xxxx: Title to be completed"; 1100 } 1102 identity device-acme-idty { 1103 base service-assurance-device:device-idty; 1104 description 1105 "Network Device is healthy."; 1106 } 1108 augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" { 1109 description 1110 "Specify the required parameters for a new subservice type"; 1111 container parameters { 1112 when "derived-from-or-self(../service-assurance:type, 'device-acme-idty')"; 1113 description 1114 "Specify the required parameters for the device-acme-idty subservice type"; 1115 leaf device { 1116 type string; 1117 mandatory true; 1118 description 1119 "The device to monitor."; 1120 } 1121 leaf acme-specific-parameter { 1122 type string; 1123 mandatory true; 1124 description 1125 "The ACME Corporation sepcific parameter."; 1126 } 1127 } 1128 } 1129 } 1131 8. Further Extensions: IP Connectivity and IS-IS subservices 1133 8.1. IP Connectivity Tree View 1135 The following tree diagram [RFC8340] provides an overview of the 1136 ietf-service-assurance-ip-connectivity data model. 1138 module: ietf-service-assurance-ip-connectivity 1140 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: 1141 +--rw parameters 1142 +--rw device1 string 1143 +--rw address1 inet:ip-address 1144 +--rw device2 string 1145 +--rw address2 inet:ip-address 1147 To specify the connectivity that we are interested in, we specify two 1148 IP addresses and two devices. The subservice assures that the 1149 connectivity between IP address 1 on device 1 and IP address 2 on 1150 device 2 is healthy. 1152 8.2. IS-IS Tree View 1154 The following tree diagram [RFC8340] provides an overview of the 1155 ietf-service-assurance-is-is data model. 1157 module: ietf-service-assurance-is-is 1159 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: 1160 +--rw parameters 1161 +--rw instance-name string 1163 The parameter of this subservice is the name of the IS-IS instance to 1164 assure. 1166 8.3. Global Tree View 1168 The following tree diagram [RFC8340] provides an overview of the 1169 ietf-service-assurance, ietf-service-assurance-device, example- 1170 service-assurance-device-acme, ietf-service-assurance-ip-connectivity 1171 and ietf-service-assurance-is-is data models. 1173 module: ietf-service-assurance 1174 +--ro assurance-graph-version yang:counter32 1175 +--ro assurance-graph-last-change yang:date-and-time 1176 +--rw subservices 1177 +--rw subservice* [type id] 1178 +--rw type identityref 1179 +--rw id string 1180 +--ro last-change? yang:date-and-time 1181 +--ro label? string 1182 +--rw under-maintenance? boolean 1183 +--rw maintenance-contact string 1184 +--rw (parameter)? 1185 | +--:(service-instance-parameter) 1186 | | +--rw service-instance-parameter 1187 | | +--rw service string 1188 | | +--rw instance-name string 1189 | +--:(service-assurance-ip-connectivity:parameters) 1190 | | +--rw service-assurance-ip-connectivity:parameters 1191 | | +--rw service-assurance-ip-connectivity:device1 string 1192 | | +--rw service-assurance-ip-connectivity:address1 inet:ip-address 1193 | | +--rw service-assurance-ip-connectivity:device2 string 1194 | | +--rw service-assurance-ip-connectivity:address2 inet:ip-address 1195 | +--:(service-assurance-is-is:parameters) 1196 | | +--rw service-assurance-is-is:parameters 1197 | | +--rw service-assurance-is-is:instance-name string 1198 | +--:(service-assurance-device:parameters) 1199 | | +--rw service-assurance-device:parameters 1200 | | +--rw service-assurance-device:device string 1201 | +--:(example-service-assurance-device-acme:parameters) 1202 | | +--rw example-service-assurance-device-acme:parameters 1203 | | +--rw example-service-assurance-device-acme:device string 1204 | | +--rw example-service-assurance-device-acme:acme-specific-parameter string 1205 | +--:(service-assurance-interface:parameters) 1206 | +--rw service-assurance-interface:parameters 1207 | +--rw service-assurance-interface:device string 1208 | +--rw service-assurance-interface:interface string 1209 +--ro health-score? union 1210 +--ro symptoms-history-start? yang:date-and-time 1211 +--rw symptoms 1212 | +--ro symptom* [start-date-time id] 1213 | +--ro id string 1214 | +--ro health-score-weight? uint8 1215 | +--ro description? string 1216 | +--ro start-date-time yang:date-and-time 1217 | +--ro stop-date-time? yang:date-and-time 1218 +--rw dependencies 1219 +--rw dependency* [type id] 1220 +--rw type -> /subservices/subservice/type 1221 +--rw id -> /subservices/subservice[type=current()/../type]/id 1222 +--rw dependency-type? identityref 1224 8.4. IP Connectivity YANG Module 1226 file "ietf-service-assurance-ip- 1227 connectivity@2021-06-28.yang" 1229 module ietf-service-assurance-ip-connectivity { 1230 yang-version 1.1; 1231 namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-ip-connectivity"; 1232 prefix service-assurance-ip-connectivity; 1234 import ietf-inet-types { 1235 prefix inet; 1236 } 1237 import ietf-service-assurance { 1238 prefix service-assurance; 1239 } 1241 organization 1242 "IETF OPSAWG Working Group"; 1243 contact 1244 "WG Web: 1245 WG List: 1246 Author: Benoit Claise 1247 Author: Jean Quilbeuf "; 1248 description 1249 "This module extends the ietf-service-assurance module to add 1250 support for the subservice ip-connectivity. 1252 Checks whether the ip connectivity between two ip addresses 1253 belonging to two network devices is healthy. 1255 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1256 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1257 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1258 are to be interpreted as described in BCP 14 (RFC 2119) 1259 (RFC 8174) when, and only when, they appear in all 1260 capitals, as shown here. 1262 Copyright (c) 2021 IETF Trust and the persons identified as 1263 authors of the code. All rights reserved. 1264 Redistribution and use in source and binary forms, with or 1265 without modification, is permitted pursuant to, and subject 1266 to the license terms contained in, the Simplified BSD License 1267 set forth in Section 4.c of the IETF Trust's Legal Provisions 1268 Relating to IETF Documents 1269 (https://trustee.ietf.org/license-info). 1271 This version of this YANG module is part of RFC XXXX; see the 1272 RFC itself for full legal notices. "; 1274 revision 2021-06-28 { 1275 description 1276 "Initial revision."; 1277 reference 1278 "RFC xxxx: Title to be completed"; 1279 } 1281 identity ip-connectivity-idty { 1282 base service-assurance:subservice-idty; 1283 description 1284 "Checks connectivity between two IP addresses."; 1285 } 1287 augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" { 1288 description 1289 "Specify the required parameters for the ip-connectivity-idty subservice type"; 1290 container parameters { 1291 when "derived-from-or-self(../service-assurance:type, 'ip-connectivity-idty')"; 1292 description 1293 "Required parameters for the ip-connectivity-idty subservice type"; 1294 leaf device1 { 1295 type string; 1296 mandatory true; 1297 description 1298 "Device at the first end of the connection."; 1299 } 1300 leaf address1 { 1301 type inet:ip-address; 1302 mandatory true; 1303 description 1304 "Address at the first end of the connection."; 1305 } 1306 leaf device2 { 1307 type string; 1308 mandatory true; 1309 description 1310 "Device at the second end of the connection."; 1311 } 1312 leaf address2 { 1313 type inet:ip-address; 1314 mandatory true; 1315 description 1316 "Address at the second end of the connection."; 1317 } 1318 } 1319 } 1320 } 1322 1324 8.5. IS-IS YANG Module 1326 file "ietf-service-assurance-is-is@2021-06-28.yang" 1328 module ietf-service-assurance-is-is { 1329 yang-version 1.1; 1330 namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-is-is"; 1331 prefix service-assurance-is-is; 1333 import ietf-service-assurance { 1334 prefix service-assurance; 1335 } 1337 organization 1338 "IETF NETCONF (Network Configuration) Working Group"; 1339 contact 1340 "WG Web: 1341 WG List: 1342 Author: Benoit Claise 1343 Author: Jean Quilbeuf "; 1344 description 1345 "This module extends the ietf-service-assurance module to add 1346 support for the subservice IS-ISHealthy. 1348 Checks whether an IS-IS instance is healthy. 1350 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1351 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1352 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1353 are to be interpreted as described in BCP 14 (RFC 2119) 1354 (RFC 8174) when, and only when, they appear in all 1355 capitals, as shown here. 1357 Copyright (c) 2021 IETF Trust and the persons identified as 1358 authors of the code. All rights reserved. 1360 Redistribution and use in source and binary forms, with or 1361 without modification, is permitted pursuant to, and subject 1362 to the license terms contained in, the Simplified BSD License 1363 set forth in Section 4.c of the IETF Trust's Legal Provisions 1364 Relating to IETF Documents 1365 (https://trustee.ietf.org/license-info). 1366 This version of this YANG module is part of RFC XXXX; see the 1367 RFC itself for full legal notices. "; 1369 revision 2021-06-28 { 1370 description 1371 "Initial revision."; 1372 reference 1373 "RFC xxxx: Title to be completed"; 1374 } 1376 identity is-is-idty { 1377 base service-assurance:subservice-idty; 1378 description 1379 "Health of IS-IS routing protocol."; 1380 } 1382 augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" { 1383 description 1384 "Specify the required parameters for a new subservice type"; 1385 container parameters { 1386 when "derived-from-or-self(../service-assurance:type, 'is-is-idty')"; 1387 description 1388 "Specify the required parameters for the IS-IS subservice type"; 1389 leaf instance-name { 1390 type string; 1391 mandatory true; 1392 description 1393 "The instance to monitor."; 1394 } 1395 } 1396 } 1397 } 1399 1401 9. Guidelines for Specific Subservice Extension 1403 The base YANG module defined in Section 4.3 only defines a single 1404 type of subservices that represent service instances. As explained 1405 above, this model is meant to be augmented so that a variety of 1406 subservices can be used in the assurance graph. In this section, we 1407 propose some guidelines in order to build theses extensions. 1409 First, the specific subservice must be given an adequate unique short 1410 name that will be used to form longer names (e.g. module name, prefix 1411 ...) appearing in the YANG module. The short name identifies the 1412 type of subpart of feature that the subservice will represent, for 1413 instance if the subservice will assure the health of a network 1414 interafce then "interface" is an adequate short name. If the 1415 subservice will assure the IS-IS routing protocol, then "is-is" is an 1416 adequate short name. The short name must be in kebab-case. 1418 In this section, by subservice YANG module, we mean "YANG module that 1419 extends ieft-service-assurance in order to define a specific 1420 subservice". 1422 9.1. Module Name 1424 For subservice YANG modules vetted by the IETF, the module name 1425 should be "ieft-service-assurance-" followed by the short name. For 1426 instance, "ietf-service-assurance-interface" or "ietf-service- 1427 assurance-is-is". 1429 For subservice YANG module that are directly provided by vendors, we 1430 propose that they use the company in the prefix. For example, the 1431 prefix for the company "acme" would be "acme-assurance-" and the YANG 1432 modules would be "acme-assurance-interface", "acme-assurance-is-is", 1433 etc. 1435 9.2. Module Namespace 1437 For subservice YANG modules vetted by the IETF, the module namespace 1438 should be "urn:ietf:params:xml:ns:yang:ietf-service-assurance-" 1439 followed by the short name. For instance, 1440 "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface" or 1441 "urn:ietf:params:xml:ns:yang:ietf-service-assurance-is-is". 1443 For subservice YANG module that are directly provided by vendors, a 1444 similar pattern can be used with the prefix being a namespace 1445 controlled by the vendor. 1447 9.3. Module Prefix 1449 For subservice YANG modules vetted by the IETF, the module prefix 1450 should be "service-assurance-" followed by the short name. For 1451 instance, "service-assurance-interface" or "service-assurance-is-is". 1453 For subservice YANG module that are directly provided by vendors, the 1454 same pattern can be used provided it does not conflict with an 1455 imported prefix. 1457 9.4. Subservice Specific Identity 1459 Each auqment specific to a subservice must define an identity 1460 representing the type of subpart or features of the network system 1461 that are assured by the subservice. As required in the "ietf- 1462 service-assurance" module (see Section 4.3), that identity must be 1463 based on the "subservice-idty" identity. 1465 For subservice YANG modules vetted by the IETF, the subservice 1466 specific identity should be the short name of the subservice followed 1467 by "-idty". For instance, "interface-idty" or "is-is-identity". 1469 For subservice YANG module that are directly provided by vendors, the 1470 same pattern can be used. 1472 9.5. Parameters 1474 For subservice YANG modules vetted by the IETF, the parameters 1475 specific to the subservice should be placed in a container named 1476 "parameters". That container must be used to augment the "parameter" 1477 choice from the module "ietf-service-assurance" (see Section 4.3 and 1478 that augment must be guarded so that it is effective only for 1479 subservice instance whose type is the subservice specific identity 1480 from Section 9.4. 1482 For subservice YANG module that are directly provided by vendors, the 1483 same pattern can be used. 1485 10. Security Considerations 1487 The YANG module specified in this document defines a schema for data 1488 that is designed to be accessed via network management protocols such 1489 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1490 is the secure transport layer, and the mandatory-to-implement secure 1491 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1492 is HTTPS, and the mandatory-to-implement secure transport is TLS 1493 [RFC8446]. 1495 The Network Configuration Access Control Model (NACM) [RFC8341] 1496 provides the means to restrict access for particular NETCONF or 1497 RESTCONF users to a preconfigured subset of all available NETCONF or 1498 RESTCONF protocol operations and content. 1500 There are a number of data nodes defined in this YANG module that are 1501 writable/ creatable/deletable (i.e., config true, which is the 1502 default). These data nodes may be considered sensitive or vulnerable 1503 in some network environments. Write operations (e.g., edit-config) 1504 to these data nodes without proper protection can have a negative 1505 effect on network operations. These are the subtrees and data nodes 1506 and their sensitivity/vulnerability: 1508 * /subservices/subservice/type 1510 * /subservices/subservice/id 1512 * /subservices/subservice/under-maintenance 1514 * /subservices/subservice/maintenance-contact 1516 11. IANA Considerations 1518 11.1. The IETF XML Registry 1520 This document registers two URIs in the IETF XML registry [RFC3688]. 1521 Following the format in [RFC3688], the following registrations are 1522 requested: 1524 URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance 1525 Registrant Contact: The NETCONF WG of the IETF. 1526 XML: N/A, the requested URI is an XML namespace. 1528 URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device 1529 Registrant Contact: The NETCONF WG of the IETF. 1530 XML: N/A, the requested URI is an XML namespace. 1532 URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface 1533 Registrant Contact: The NETCONF WG of the IETF. 1534 XML: N/A, the requested URI is an XML namespace. 1536 11.2. The YANG Module Names Registry 1538 This document registers three YANG modules in the YANG Module Names 1539 registry [RFC7950]. Following the format in [RFC7950], the the 1540 following registrations are requested: 1542 name: ietf-service-assurance 1543 namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance 1544 prefix: inc 1545 reference: RFC XXXX 1547 name: ietf-service-assurance-device 1548 namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device 1549 prefix: inc 1550 reference: RFC XXXX 1552 name: ietf-service-assurance-interface 1553 namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface 1554 prefix: inc 1555 reference: RFC XXXX 1557 12. Open Issues 1559 -None 1561 13. References 1563 13.1. Normative References 1565 [I-D.ietf-opsawg-service-assurance-architecture] 1566 Claise, B.C., Quilbeuf, J.Q., Lopez, D.L., Voyer, D.V., 1567 and T.A. Arumugam, "draft-claise-opsawg-service-assurance- 1568 architecture", 2020. 1570 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1571 and A. Bierman, Ed., "Network Configuration Protocol 1572 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1573 . 1575 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1576 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1577 . 1579 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1580 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1581 . 1583 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1584 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1585 . 1587 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1588 Access Control Model", STD 91, RFC 8341, 1589 DOI 10.17487/RFC8341, March 2018, 1590 . 1592 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1593 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1594 . 1596 13.2. Informative References 1598 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1599 Requirement Levels", BCP 14, RFC 2119, 1600 DOI 10.17487/RFC2119, March 1997, 1601 . 1603 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1604 DOI 10.17487/RFC3688, January 2004, 1605 . 1607 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 1608 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 1609 . 1611 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1612 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1613 May 2017, . 1615 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1616 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1617 . 1619 Appendix A. Example of YANG instances 1621 This section contains examples of YANG instances that conform to the 1622 YANG modules. The validity of these data instances has been checked 1623 using yangson (https://yangson.labs.nic.cz/). Yangson requires a 1624 YANG library [RFC7895] to define the complete model against which the 1625 data instance must be validated. We provide in Appendix B the JSON 1626 library file, named "ietf-service-assurance-library.json", that we 1627 used for validation. 1629 We provide below the contents of the file 1630 "example_configuration_instance.json" which contains the 1631 configuration data that models the Figure 2 of 1632 [I-D.ietf-opsawg-service-assurance-architecture]. The instance can 1633 be validated with yangson by using the invocation "yangson -v 1634 example_configuration_instance.json ietf-service-assurance- 1635 library.json", assuming all the files (YANG and JSON) defined in this 1636 draft reside in the current folder. 1638 file "example_configuration_instance.json" 1640 { 1641 "ietf-service-assurance:subservices": { 1642 "subservice": [ 1643 { 1644 "type": "service-instance-idty", 1645 "id": "simple-tunnel/example", 1646 "service-instance-parameter": { 1647 "service": "simple-tunnel", 1648 "instance-name": "example" 1649 }, 1650 "dependencies": { 1651 "dependency": [ 1652 { 1653 "type": "ietf-service-assurance-interface:interface-idty", 1654 "id": "interface/peer1/tunnel0", 1655 "dependency-type": "impacting-dependency" 1656 }, 1657 { 1658 "type": "ietf-service-assurance-interface:interface-idty", 1659 "id": "interface/peer2/tunnel9", 1660 "dependency-type": "impacting-dependency" 1661 }, 1662 { 1663 "type": "ietf-service-assurance-ip-connectivity:ip-connectivity-idty", 1664 "id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2", 1665 "dependency-type": "impacting-dependency" 1666 } 1667 ] 1668 } 1669 }, 1670 { 1671 "type": "ietf-service-assurance-ip-connectivity:ip-connectivity-idty", 1672 "id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2", 1673 "ietf-service-assurance-ip-connectivity:parameters": { 1674 "device1": "Peer1", 1675 "address1": "2001:db8::1", 1676 "device2": "Peer2", 1677 "address2": "2001:db8::2" 1678 }, 1679 "dependencies": { 1680 "dependency": [ 1681 { 1682 "type": "ietf-service-assurance-interface:interface-idty", 1683 "id": "interface/peer1/physical0", 1684 "dependency-type": "impacting-dependency" 1685 }, 1686 { 1687 "type": "ietf-service-assurance-interface:interface-idty", 1688 "id": "interface/peer2/physical5", 1689 "dependency-type": "impacting-dependency" 1690 }, 1691 { 1692 "type": "ietf-service-assurance-is-is:is-is-idty", 1693 "id": "is-is/instance1", 1694 "dependency-type": "impacting-dependency" 1695 } 1696 ] 1697 } 1698 }, 1699 { 1700 "type": "ietf-service-assurance-is-is:is-is-idty", 1701 "id": "is-is/instance1", 1702 "ietf-service-assurance-is-is:parameters": { 1703 "instance-name": "instance1" 1704 } 1705 }, 1706 { 1707 "type": "ietf-service-assurance-interface:interface-idty", 1708 "id": "interface/peer1/tunnel0", 1709 "ietf-service-assurance-interface:parameters": { 1710 "device": "Peer1", 1711 "interface": "tunnel0" 1712 }, 1713 "dependencies": { 1714 "dependency": [ 1715 { 1716 "type": "ietf-service-assurance-interface:interface-idty", 1717 "id": "interface/peer1/physical0", 1718 "dependency-type": "impacting-dependency" 1719 } 1720 ] 1721 } 1722 }, 1723 { 1724 "type": "ietf-service-assurance-interface:interface-idty", 1725 "id": "interface/peer1/physical0", 1726 "ietf-service-assurance-interface:parameters": { 1727 "device": "Peer1", 1728 "interface": "physical0" 1729 }, 1730 "dependencies": { 1731 "dependency": [ 1732 { 1733 "type": "ietf-service-assurance-device:device-idty", 1734 "id": "interface/peer1", 1735 "dependency-type": "impacting-dependency" 1736 } 1737 ] 1738 } 1739 }, 1740 { 1741 "type": "ietf-service-assurance-device:device-idty", 1742 "id": "interface/peer1", 1743 "ietf-service-assurance-device:parameters": { 1744 "device": "Peer1" 1745 } 1746 }, 1747 { 1748 "type": "ietf-service-assurance-interface:interface-idty", 1749 "id": "interface/peer2/tunnel9", 1750 "ietf-service-assurance-interface:parameters": { 1751 "device": "Peer2", 1752 "interface": "tunnel9" 1753 }, 1754 "dependencies": { 1755 "dependency": [ 1756 { 1757 "type": "ietf-service-assurance-interface:interface-idty", 1758 "id": "interface/peer2/physical5", 1759 "dependency-type": "impacting-dependency" 1760 } 1761 ] 1762 } 1763 }, 1764 { 1765 "type": "ietf-service-assurance-interface:interface-idty", 1766 "id": "interface/peer2/physical5", 1767 "ietf-service-assurance-interface:parameters": { 1768 "device": "Peer2", 1769 "interface": "physical5" 1770 }, 1771 "dependencies": { 1772 "dependency": [ 1773 { 1774 "type": "ietf-service-assurance-device:device-idty", 1775 "id": "interface/peer2", 1776 "dependency-type": "impacting-dependency" 1777 } 1778 ] 1779 } 1780 }, 1781 { 1782 "type": "ietf-service-assurance-device:device-idty", 1783 "id": "interface/peer2", 1784 "ietf-service-assurance-device:parameters": { 1785 "device": "Peer2" 1786 } 1787 } 1788 ] 1789 } 1790 } 1792 1794 Appendix B. YANG Library for Service Assurance 1796 This section provides the JSON encoding of the YANG library [RFC7895] 1797 listing all modules defined in this draft and their dependencies. 1798 This library can be used to validate data instances using yangson, as 1799 explained in the previous section. 1801 file "ietf-service-assurance-library.json" 1803 { 1804 "ietf-yang-library:modules-state": { 1805 "module-set-id": "ietf-service-assurance@2020-01-13", 1806 "module": [ 1807 { 1808 "name": "ietf-service-assurance", 1809 "namespace": "urn:ietf:params:xml:ns:yang:ietf-service-assurance", 1810 "revision": "2021-06-28", 1811 "conformance-type": "implement" 1812 }, 1813 { 1814 "name": "ietf-service-assurance-device", 1815 "namespace": "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device", 1816 "revision": "2021-06-28", 1817 "conformance-type": "implement" 1818 }, 1819 { 1820 "name": "ietf-service-assurance-interface", 1821 "namespace": "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface", 1822 "revision": "2021-06-28", 1823 "conformance-type": "implement" 1824 }, 1825 { 1826 "name": "example-service-assurance-device-acme", 1827 "namespace": "urn:example:example-service-assurance-device-acme", 1828 "revision": "2021-06-28", 1829 "conformance-type": "implement" 1830 }, 1831 { 1832 "name": "ietf-service-assurance-is-is", 1833 "namespace": "urn:ietf:payams:xml:ns:yang:ietf-service-assurance-is-is", 1834 "revision": "2021-06-28", 1835 "conformance-type": "implement" 1836 }, 1837 { 1838 "name": "ietf-service-assurance-ip-connectivity", 1839 "namespace": "urn:ietf:payams:xml:ns:yang:ietf-service-assurance-ip-connectivity", 1840 "revision": "2021-06-28", 1841 "conformance-type": "implement" 1842 }, 1843 { 1844 "name": "ietf-yang-types", 1845 "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1846 "revision": "2021-04-14", 1847 "conformance-type": "import" 1848 }, 1849 { 1850 "name": "ietf-inet-types", 1851 "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1852 "revision": "2021-02-22", 1853 "conformance-type": "import" 1854 } 1855 ] 1856 } 1857 } 1859 1861 Appendix C. Changes between revisions 1863 v00 - v01 1865 * Added needed subservice to model example from architecture draft 1867 * Added guideline section for naming models 1868 * Added data instance examples and validation procedure 1870 * Added the "parameters" container in the interface YANG module to 1871 correct a bug. 1873 Acknowledgements 1875 The authors would like to thank Jan Lindblad for his help during the 1876 design of these YANG modules. The authors would like to thank 1877 Stephane Litkowski and Charles Eckel for their reviews. 1879 Authors' Addresses 1881 Benoit Claise 1882 Huawei 1884 Email: benoit.claise@huawei.com 1886 Jean Quilbeuf 1887 Huawei 1889 Email: jean.quilbeuf@huawei.com 1891 Paolo Lucente 1892 NTT 1893 Siriusdreef 70-72 1894 2132 Hoofddorp 1895 Netherlands 1897 Email: paolo@ntt.net 1899 Paolo Fasano 1900 TIM S.p.A 1901 via G. Reiss Romoli, 274 1902 10148 Torino 1903 Italy 1905 Email: paolo2.fasano@telecomitalia.it 1907 Thangam Arumugam 1908 Cisco Systems, Inc. 1909 Milpitas (California), 1910 United States 1911 Email: tarumuga@cisco.com