idnits 2.17.1 draft-ietf-opsawg-service-assurance-yang-01.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 638 has weird spacing: '... device str...' == Line 647 has weird spacing: '...-change yan...' == Line 660 has weird spacing: '...ce-name str...' == (19 more instances...) -- The document date (July 2, 2021) is 1028 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) -- Looks like a reference, but probably isn't: '1' on line 1613 ** 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 (==), 3 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: January 3, 2022 P. Lucente 6 NTT 7 P. Fasano 8 TIM S.p.A 9 T. Arumugam 10 Cisco Systems, Inc. 11 July 2, 2021 13 YANG Modules for Service Assurance 14 draft-ietf-opsawg-service-assurance-yang-01 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 January 3, 2022. 38 Copyright Notice 40 Copyright (c) 2021 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 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. YANG Models Overview . . . . . . . . . . . . . . . . . . . . 3 58 4. Base ietf-service-assurance YANG module . . . . . . . . . . . 4 59 4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7 62 5. Subservice Extension: ietf-service-assurance-device YANG 63 module . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 14 65 5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 14 66 5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 15 67 5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 16 68 6. Subservice Extension: ietf-service-assurance-interface YANG 69 module . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 18 71 6.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 18 72 6.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 19 73 6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 20 74 7. Vendor-specific Subservice Extension: example-service- 75 assurance-device-acme YANG module . . . . . . . . . . . . . . 22 76 7.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 22 77 7.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 22 78 7.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 23 79 7.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 24 80 8. Further Extensions: IP Connectivity and IS-IS subservices . . 26 81 8.1. IP Connectivity Tree View . . . . . . . . . . . . . . . . 26 82 8.2. IS-IS Tree View . . . . . . . . . . . . . . . . . . . . . 26 83 8.3. Global Tree View . . . . . . . . . . . . . . . . . . . . 26 84 8.4. IP Connectivity YANG Module . . . . . . . . . . . . . . . 28 85 8.5. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . 30 86 9. Guidelines for Specific Subservice Extension . . . . . . . . 31 87 9.1. Module Name . . . . . . . . . . . . . . . . . . . . . . . 32 88 9.2. Module Namespace . . . . . . . . . . . . . . . . . . . . 32 89 9.3. Module Prefix . . . . . . . . . . . . . . . . . . . . . . 32 90 9.4. Subservice Specific Identity . . . . . . . . . . . . . . 33 91 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 o machine readable 128 o vendor independent 130 o 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 o 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 o 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? uint8 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 o 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 o 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 o A type: identity inheriting of the base identity for subservice, 250 o An id: string uniquely identifying the subservice among those with 251 the same identity, 253 o 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 o Impacting: such a dependency indicates an impact on the health of 261 the dependent, 263 o 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@2021-06-28.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 2021-06-28 { 361 description 362 "Made service-instance parameters mandatory."; 363 reference 364 "RFC xxxx: Title to be completed"; 365 } 366 revision 2020-01-13 { 367 description 368 "Added the maintenance window concept."; 369 reference 370 "RFC xxxx: Title to be completed"; 372 } 373 revision 2019-11-16 { 374 description 375 "Initial revision."; 376 reference 377 "RFC xxxx: Title to be completed"; 378 } 380 identity subservice-idty { 381 description 382 "Root identity for all subservice types."; 383 } 385 identity service-instance-idty { 386 base subservice-idty; 387 description 388 "Identity representing a service instance."; 389 } 391 identity dependency-type { 392 description 393 "Base identity for representing dependency types."; 394 } 396 identity informational-dependency { 397 base dependency-type; 398 description 399 "Indicates that symptoms of the dependency might be of interest for the 400 dependent, but the status of the dependency should not have any 401 impact on the dependent."; 402 } 404 identity impacting-dependency { 405 base dependency-type; 406 description 407 "Indicates that the status of the dependency directly impacts the status 408 of the dependent."; 409 } 411 grouping symptom { 412 description 413 "Contains the list of symptoms for a specific subservice."; 414 leaf id { 415 type string; 416 description 417 "A unique identifier for the symptom."; 418 } 419 leaf health-score-weight { 420 type uint8 { 421 range "0 .. 100"; 422 } 423 description 424 "The weight to the health score incurred by this symptom. The higher the 425 value, the more of an impact this symptom has. If a subservice health 426 score is not 100, there must be at least one symptom with a health 427 score weight larger than 0."; 428 } 429 leaf description { 430 type string; 431 description 432 "Description of the symptom, i.e. text describing what the symptom is, to 433 be computer-consumable and be displayed on a human interface. "; 434 } 435 leaf start-date-time { 436 type yang:date-and-time; 437 description 438 "Date and time at which the symptom was detected."; 439 } 440 leaf stop-date-time { 441 type yang:date-and-time; 442 description 443 "Date and time at which the symptom stopped being detected."; 444 } 445 } 447 grouping subservice-dependency { 448 description 449 "Represent a dependency to another subservice."; 450 leaf type { 451 type leafref { 452 path "/subservices/subservice/type"; 453 } 454 description 455 "The type of the subservice to refer to (e.g. DeviceHealthy)."; 456 } 457 leaf id { 458 type leafref { 459 path "/subservices/subservice[type=current()/../type]/id"; 460 } 461 description 462 "The identifier of the subservice to refer to."; 463 } 464 leaf dependency-type { 465 type identityref { 466 base dependency-type; 467 } 468 description 469 "Represents the type of dependency (i.e. informational, impacting)."; 470 } 471 // augment here if more info are needed (i.e. a percentage) depending on the dependency type. 472 } 474 leaf assurance-graph-version { 475 type yang:counter32; 476 mandatory true; 477 config false; 478 description 479 "The assurance graph version, which increases by 1 for each new version, after the changes 480 (dependencies and/or maintenance windows parameters) are applied to the subservice(s)."; 481 } 482 leaf assurance-graph-last-change { 483 type yang:date-and-time; 484 mandatory true; 485 config false; 486 description 487 "Date and time at which the assurance graph last changed after the changes (dependencies 488 and/or maintenance windows parameters) are applied to the subservice(s). These date and time 489 must be more recent or equal compared to the more recent value of any changed subservices 490 last-change"; 491 } 492 container subservices { 493 description 494 "Root container for the subservices."; 495 list subservice { 496 key "type id"; 497 description 498 "List of subservice configured."; 499 leaf type { 500 type identityref { 501 base subservice-idty; 502 } 503 description 504 "Name of the subservice, e.g. DeviceHealthy."; 505 } 506 leaf id { 507 type string; 508 description 509 "Unique identifier of the subservice instance, for each type."; 510 } 511 leaf last-change { 512 type yang:date-and-time; 513 config false; 514 description 515 "Date and time at which the assurance graph for this subservice 516 instance last changed, i.e. dependencies and/or maintenance windows parameters."; 517 } 518 leaf label { 519 type string; 520 config false; 521 description 522 "Label of the subservice, i.e. text describing what the subservice is to 523 be displayed on a human interface."; 524 } 525 leaf under-maintenance { 526 type boolean; 527 default "false"; 528 description 529 "An optional flag indicating whether this particular subservice is under 530 maintenance. Under this circumstance, the subservice symptoms and the 531 symptoms of its dependencies in the assurance graph should not be taken 532 into account. Instead, the subservice should send a 'Under Maintenance' 533 single symptom. 535 The operator changing the under-maintenance value must set the 536 maintenance-contact variable. 538 When the subservice is not under maintenance any longer, the 539 under-maintenance flag must return to its default value and 540 the under-maintenance-owner variable deleted."; 541 } 542 leaf maintenance-contact { 543 when "../under-maintenance = 'true'"; 544 type string; 545 mandatory true; 546 description 547 "A string used to model an administratively assigned name of the 548 resource that changed the under-maintenance value to 'true. 550 It is suggested that this name contain one or more of the following: 551 IP address, management station name, network manager's name, location, 552 or phone number. In some cases the agent itself will be the owner of 553 an entry. In these cases, this string shall be set to a string 554 starting with 'monitor'."; 555 } 556 choice parameter { 557 description 558 "Specify the required parameters per subservice type."; 559 container service-instance-parameter { 560 when "derived-from-or-self(../type, 'service-assurance:service-instance-idty')"; 561 description 562 "Specify the parameters of a service instance."; 563 leaf service { 564 type string; 565 mandatory true; 566 description 567 "Name of the service."; 568 } 569 leaf instance-name { 570 type string; 571 mandatory true; 572 description 573 "Name of the instance for that service."; 574 } 575 } 576 // Other modules can augment their own cases into here 577 } 578 leaf health-score { 579 type uint8 { 580 range "0 .. 100"; 581 } 582 config false; 583 description 584 "Score value of the subservice health. A value of 100 means that 585 subservice is healthy. A value of 0 means that the subservice is 586 broken. A value between 0 and 100 means that the subservice is 587 degraded."; 588 } 589 leaf symptoms-history-start { 590 type yang:date-and-time; 591 config false; 592 description 593 "Date and time at which the symptoms history starts for this 594 subservice instance, either because the subservice instance 595 started at that date and time or because the symptoms before that 596 were removed due to a garbage collection process."; 597 } 598 container symptoms { 599 description 600 "Symptoms for the subservice."; 601 list symptom { 602 key "start-date-time id"; 603 config false; 604 description 605 "List of symptoms the subservice. While the start-date-time key is not 606 necessary per se, this would get the entries sorted by start-date-time 607 for easy consumption."; 608 uses symptom; 609 } 610 } 611 container dependencies { 612 description 613 "configure the dependencies between the subservices, along with their types."; 614 list dependency { 615 key "type id"; 616 description 617 "List of soft dependencies of the subservice."; 618 uses subservice-dependency; 619 } 620 } 621 } 622 } 623 } 625 627 5. Subservice Extension: ietf-service-assurance-device YANG module 629 5.1. Tree View 631 The following tree diagram [RFC8340] provides an overview of the 632 ietf-service-assurance-device data model. 634 module: ietf-service-assurance-device 636 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: 637 +--rw parameters 638 +--rw device string 640 5.2. Complete Tree View 642 The following tree diagram [RFC8340] provides an overview of the 643 ietf-service-assurance and ietf-service-assurance-device data models. 645 module: ietf-service-assurance 646 +--ro assurance-graph-version yang:counter32 647 +--ro assurance-graph-last-change yang:date-and-time 648 +--rw subservices 649 +--rw subservice* [type id] 650 +--rw type identityref 651 +--rw id string 652 +--ro last-change? yang:date-and-time 653 +--ro label? string 654 +--rw under-maintenance? boolean 655 +--rw maintenance-contact string 656 +--rw (parameter)? 657 | +--:(service-instance-parameter) 658 | | +--rw service-instance-parameter 659 | | +--rw service string 660 | | +--rw instance-name string 661 | +--:(service-assurance-device:parameters) 662 | +--rw service-assurance-device:parameters 663 | +--rw service-assurance-device:device string 664 +--ro health-score? uint8 665 +--ro symptoms-history-start? yang:date-and-time 666 +--rw symptoms 667 | +--ro symptom* [start-date-time id] 668 | +--ro id string 669 | +--ro health-score-weight? uint8 670 | +--ro description? string 671 | +--ro start-date-time yang:date-and-time 672 | +--ro stop-date-time? yang:date-and-time 673 +--rw dependencies 674 +--rw dependency* [type id] 675 +--rw type -> /subservices/subservice/type 676 +--rw id -> /subservices/subservice[type=current()/../type]/id 677 +--rw dependency-type? identityref 679 5.3. Concepts 681 As the number of subservices will grow over time, the YANG module is 682 designed to be extensible. A new subservice type requires the 683 precise specifications of its type and expected parameters. Let us 684 illustrate the example of the new DeviceHealthy subservice type. As 685 the name implies, it monitors and reports the device health, along 686 with some symptoms in case of degradation. 688 For our DeviceHealthy subservice definition, the new identity device- 689 idty is specified, as an inheritance from the base identity for 690 subservices. This indicates to the assurance agent that we are now 691 assuring the health of a device. 693 The typical parameter for the configuration of the DeviceHealthy 694 subservice is the name of the device that we want to assure. By 695 augmenting the parameter choice from ietf-service-assurance YANG 696 module for the case of the device-idty subservice type, this new 697 parameter is specified. 699 5.4. YANG Module 701 file "ietf-service-assurance-device@2021-06-28.yang" 703 module ietf-service-assurance-device { 704 yang-version 1.1; 705 namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device"; 706 prefix service-assurance-device; 708 import ietf-service-assurance { 709 prefix service-assurance; 710 } 712 organization 713 "IETF NETCONF (Network Configuration) Working Group"; 714 contact 715 "WG Web: 716 WG List: 717 Author: Benoit Claise 718 Author: Jean Quilbeuf "; 719 description 720 "This module extends the ietf-service-assurance module to add 721 support for the subservice DeviceHealthy. 723 Checks whether a network device is healthy. 725 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 726 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 727 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 728 are to be interpreted as described in BCP 14 (RFC 2119) 729 (RFC 8174) when, and only when, they appear in all 730 capitals, as shown here. 732 Copyright (c) 2021 IETF Trust and the persons identified as 733 authors of the code. All rights reserved. 735 Redistribution and use in source and binary forms, with or 736 without modification, is permitted pursuant to, and subject 737 to the license terms contained in, the Simplified BSD License 738 set forth in Section 4.c of the IETF Trust's Legal Provisions 739 Relating to IETF Documents 740 (https://trustee.ietf.org/license-info). 742 This version of this YANG module is part of RFC XXXX; see the 743 RFC itself for full legal notices. "; 745 revision 2021-06-28 { 746 description 747 "Renamed the container for parameters."; 748 reference 749 "RFC xxxx: Title to be completed"; 750 } 751 revision 2020-01-13 { 752 description 753 "Added the maintenance window concept."; 754 reference 755 "RFC xxxx: Title to be completed"; 756 } 757 revision 2019-11-16 { 758 description 759 "Initial revision."; 760 reference 761 "RFC xxxx: Title to be completed"; 762 } 764 identity device-idty { 765 base service-assurance:subservice-idty; 766 description 767 "Network Device is healthy."; 768 } 770 augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" { 771 description 772 "Specify the required parameters for a new subservice type"; 773 container parameters { 774 when "derived-from-or-self(../service-assurance:type, 'device-idty')"; 775 description 776 "Specify the required parameters for the device-idty subservice type"; 777 leaf device { 778 type string; 779 mandatory true; 780 description 781 "The device to monitor."; 782 } 783 } 784 } 785 } 787 789 6. Subservice Extension: ietf-service-assurance-interface YANG module 791 6.1. Tree View 793 The following tree diagram [RFC8340] provides an overview of the 794 ietf-service-assurance-interface data model. 796 module: ietf-service-assurance-interface 798 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: 799 +--rw parameters 800 +--rw device string 801 +--rw interface string 803 6.2. Complete Tree View 805 The following tree diagram [RFC8340] provides an overview of the 806 ietf-service-assurance, ietf-service-assurance-device, and ietf- 807 service-assurance-interface data models. 809 module: ietf-service-assurance 810 +--ro assurance-graph-version yang:counter32 811 +--ro assurance-graph-last-change yang:date-and-time 812 +--rw subservices 813 +--rw subservice* [type id] 814 +--rw type identityref 815 +--rw id string 816 +--ro last-change? yang:date-and-time 817 +--ro label? string 818 +--rw under-maintenance? boolean 819 +--rw maintenance-contact string 820 +--rw (parameter)? 821 | +--:(service-instance-parameter) 822 | | +--rw service-instance-parameter 823 | | +--rw service string 824 | | +--rw instance-name string 825 | +--:(service-assurance-interface:parameters) 826 | | +--rw service-assurance-interface:parameters 827 | | +--rw service-assurance-interface:device string 828 | | +--rw service-assurance-interface:interface string 829 | +--:(service-assurance-device:parameters) 830 | +--rw service-assurance-device:parameters 831 | +--rw service-assurance-device:device string 832 +--ro health-score? uint8 833 +--ro symptoms-history-start? yang:date-and-time 834 +--rw symptoms 835 | +--ro symptom* [start-date-time id] 836 | +--ro id string 837 | +--ro health-score-weight? uint8 838 | +--ro description? string 839 | +--ro start-date-time yang:date-and-time 840 | +--ro stop-date-time? yang:date-and-time 841 +--rw dependencies 842 +--rw dependency* [type id] 843 +--rw type -> /subservices/subservice/type 844 +--rw id -> /subservices/subservice[type=current()/../type]/id 845 +--rw dependency-type? identityref 847 6.3. Concepts 849 For our InterfaceHealthy subservice definition, the new interface- 850 idty is specified, as an inheritance from the base identity for 851 subservices. This indicates to the assurance agent that we are now 852 assuring the health of an interface. 854 The typical parameters for the configuration of the InterfaceHealthy 855 subservice are the name of the device and, on that specific device, a 856 specific interface. By augmenting the parameter choice from ietf- 857 service-assurance YANG module for the case of the interface-idty 858 subservice type, those two new parameter are specified. 860 6.4. YANG Module 862 file "ietf-service-assurance-interface@2021-06-28.yang" 864 module ietf-service-assurance-interface { 865 yang-version 1.1; 866 namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface"; 867 prefix service-assurance-interface; 869 import ietf-service-assurance { 870 prefix service-assurance; 871 } 873 organization 874 "IETF OPSAWG Working Group"; 875 contact 876 "WG Web: 877 WG List: 878 Author: Benoit Claise 879 Author: Jean Quilbeuf "; 880 description 881 "This module extends the ietf-service-assurance module to add 882 support for the subservice InterfaceHealthy. 884 Checks whether an interface is healthy. 886 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 887 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 888 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 889 are to be interpreted as described in BCP 14 (RFC 2119) 890 (RFC 8174) when, and only when, they appear in all 891 capitals, as shown here. 893 Copyright (c) 2021 IETF Trust and the persons identified as 894 authors of the code. All rights reserved. 895 Redistribution and use in source and binary forms, with or 896 without modification, is permitted pursuant to, and subject 897 to the license terms contained in, the Simplified BSD License 898 set forth in Section 4.c of the IETF Trust's Legal Provisions 899 Relating to IETF Documents 900 (https://trustee.ietf.org/license-info). 902 This version of this YANG module is part of RFC XXXX; see the 903 RFC itself for full legal notices. "; 905 revision 2021-06-28 { 906 description 907 "Regroup parameters in a container."; 908 reference 909 "RFC xxxx: Title to be completed"; 910 } 911 revision 2020-01-13 { 912 description 913 "Initial revision."; 914 reference 915 "RFC xxxx: Title to be completed"; 916 } 918 identity interface-idty { 919 base service-assurance:subservice-idty; 920 description 921 "Checks whether an interface is healthy."; 922 } 924 augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" { 925 description 926 "Specify the required parameters for the interface-idty subservice type"; 927 container parameters { 928 when "derived-from-or-self(../service-assurance:type, 'interface-idty')"; 929 description 930 "Required parameters for the interface-idty subservice type"; 931 leaf device { 932 type string; 933 mandatory true; 934 description 935 "Device supporting the interface."; 936 } 937 leaf interface { 938 type string; 939 mandatory true; 940 description 941 "Name of the interface."; 942 } 943 } 944 } 945 } 947 949 7. Vendor-specific Subservice Extension: example-service-assurance- 950 device-acme YANG module 952 7.1. Tree View 954 The following tree diagram [RFC8340] provides an overview of the 955 example-service-assurance-device-acme data model. 957 module: example-service-assurance-device-acme 959 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: 960 +--rw parameters 961 +--rw device string 962 +--rw acme-specific-parameter string 964 7.2. Complete Tree View 966 The following tree diagram [RFC8340] provides an overview of the 967 ietf-service-assurance, ietf-service-assurance-device, and example- 968 service-assurance-device-acme data models. 970 module: ietf-service-assurance 971 +--ro assurance-graph-version yang:counter32 972 +--ro assurance-graph-last-change yang:date-and-time 973 +--rw subservices 974 +--rw subservice* [type id] 975 +--rw type identityref 976 +--rw id string 977 +--ro last-change? yang:date-and-time 978 +--ro label? string 979 +--rw under-maintenance? boolean 980 +--rw maintenance-contact string 981 +--rw (parameter)? 982 | +--:(service-instance-parameter) 983 | | +--rw service-instance-parameter 984 | | +--rw service string 985 | | +--rw instance-name string 986 | +--:(service-assurance-device:parameters) 987 | | +--rw service-assurance-device:parameters 988 | | +--rw service-assurance-device:device string 989 | +--:(example-service-assurance-device-acme:parameters) 990 | | +--rw example-service-assurance-device-acme:parameters 991 | | +--rw example-service-assurance-device-acme:device string 992 | | +--rw example-service-assurance-device-acme:acme-specific-parameter string 993 | +--:(service-assurance-interface:parameters) 994 | +--rw service-assurance-interface:parameters 995 | +--rw service-assurance-interface:device string 996 | +--rw service-assurance-interface:interface string 997 +--ro health-score? uint8 998 +--ro symptoms-history-start? yang:date-and-time 999 +--rw symptoms 1000 | +--ro symptom* [start-date-time id] 1001 | +--ro id string 1002 | +--ro health-score-weight? uint8 1003 | +--ro description? string 1004 | +--ro start-date-time yang:date-and-time 1005 | +--ro stop-date-time? yang:date-and-time 1006 +--rw dependencies 1007 +--rw dependency* [type id] 1008 +--rw type -> /subservices/subservice/type 1009 +--rw id -> /subservices/subservice[type=current()/../type]/id 1010 +--rw dependency-type? identityref 1012 7.3. Concepts 1014 Under some circumstances, vendor-specific subservice types might be 1015 required. As an example of this vendor-specific implementation, this 1016 section shows how to augment the ietf-service-assurance-device module 1017 to add support for the subservice DeviceHealthy, specific to the ACME 1018 Corporation. The new parameter is acme-specific-parameter. 1020 7.4. YANG Module 1022 module example-service-assurance-device-acme { 1023 yang-version 1.1; 1024 namespace "urn:example:example-service-assurance-device-acme"; 1025 prefix example-service-assurance-device-acme; 1027 import ietf-service-assurance { 1028 prefix service-assurance; 1029 } 1030 import ietf-service-assurance-device { 1031 prefix service-assurance-device; 1032 } 1034 organization 1035 "IETF NETCONF (Network Configuration) Working Group"; 1036 contact 1037 "WG Web: 1038 WG List: 1039 Author: Benoit Claise 1040 Author: Jean Quilbeuf "; 1041 description 1042 "This module extends the ietf-service-assurance-device module to add 1043 support for the subservice DeviceHealthy, specific to the ACME Corporation. 1045 ACME Network Device is healthy. 1047 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1048 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1049 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1050 are to be interpreted as described in BCP 14 (RFC 2119) 1051 (RFC 8174) when, and only when, they appear in all 1052 capitals, as shown here. 1054 Copyright (c) 2021 IETF Trust and the persons identified as 1055 authors of the code. All rights reserved. 1057 Redistribution and use in source and binary forms, with or 1058 without modification, is permitted pursuant to, and subject 1059 to the license terms contained in, the Simplified BSD License 1060 set forth in Section 4.c of the IETF Trust's Legal Provisions 1061 Relating to IETF Documents 1062 (https://trustee.ietf.org/license-info). 1064 This version of this YANG module is part of RFC XXXX; see the 1065 RFC itself for full legal notices. "; 1067 revision 2021-06-28 { 1068 description 1069 "Renamed the parameters container."; 1070 reference 1071 "RFC xxxx: Title to be completed"; 1072 } 1073 revision 2020-01-13 { 1074 description 1075 "Added the maintenance window concept."; 1076 reference 1077 "RFC xxxx: Title to be completed"; 1078 } 1079 revision 2019-11-16 { 1080 description 1081 "Initial revision."; 1082 reference 1083 "RFC xxxx: Title to be completed"; 1084 } 1086 identity device-acme-idty { 1087 base service-assurance-device:device-idty; 1088 description 1089 "Network Device is healthy."; 1090 } 1092 augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" { 1093 description 1094 "Specify the required parameters for a new subservice type"; 1095 container parameters { 1096 when "derived-from-or-self(../service-assurance:type, 'device-acme-idty')"; 1097 description 1098 "Specify the required parameters for the device-acme-idty subservice type"; 1099 leaf device { 1100 type string; 1101 mandatory true; 1102 description 1103 "The device to monitor."; 1104 } 1105 leaf acme-specific-parameter { 1106 type string; 1107 mandatory true; 1108 description 1109 "The ACME Corporation sepcific parameter."; 1110 } 1111 } 1112 } 1114 } 1116 8. Further Extensions: IP Connectivity and IS-IS subservices 1118 8.1. IP Connectivity Tree View 1120 The following tree diagram [RFC8340] provides an overview of the 1121 ietf-service-assurance-ip-connectivity data model. 1123 module: ietf-service-assurance-ip-connectivity 1125 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: 1126 +--rw parameters 1127 +--rw device1 string 1128 +--rw address1 inet:ip-address 1129 +--rw device2 string 1130 +--rw address2 inet:ip-address 1132 To specify the connectivity that we are interested in, we specify two 1133 IP addresses and two devices. The subservice assures that the 1134 connectivity between IP address 1 on device 1 and IP address 2 on 1135 device 2 is healthy. 1137 8.2. IS-IS Tree View 1139 The following tree diagram [RFC8340] provides an overview of the 1140 ietf-service-assurance-is-is data model. 1142 module: ietf-service-assurance-is-is 1144 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: 1145 +--rw parameters 1146 +--rw instance-name string 1148 The parameter of this subservice is the name of the IS-IS instance to 1149 assure. 1151 8.3. Global Tree View 1153 The following tree diagram [RFC8340] provides an overview of the 1154 ietf-service-assurance, ietf-service-assurance-device, example- 1155 service-assurance-device-acme, ietf-service-assurance-ip-connectivity 1156 and ietf-service-assurance-is-is data models. 1158 module: ietf-service-assurance 1159 +--ro assurance-graph-version yang:counter32 1160 +--ro assurance-graph-last-change yang:date-and-time 1161 +--rw subservices 1162 +--rw subservice* [type id] 1163 +--rw type identityref 1164 +--rw id string 1165 +--ro last-change? yang:date-and-time 1166 +--ro label? string 1167 +--rw under-maintenance? boolean 1168 +--rw maintenance-contact string 1169 +--rw (parameter)? 1170 | +--:(service-instance-parameter) 1171 | | +--rw service-instance-parameter 1172 | | +--rw service string 1173 | | +--rw instance-name string 1174 | +--:(service-assurance-ip-connectivity:parameters) 1175 | | +--rw service-assurance-ip-connectivity:parameters 1176 | | +--rw service-assurance-ip-connectivity:device1 string 1177 | | +--rw service-assurance-ip-connectivity:address1 inet:ip-address 1178 | | +--rw service-assurance-ip-connectivity:device2 string 1179 | | +--rw service-assurance-ip-connectivity:address2 inet:ip-address 1180 | +--:(service-assurance-is-is:parameters) 1181 | | +--rw service-assurance-is-is:parameters 1182 | | +--rw service-assurance-is-is:instance-name string 1183 | +--:(service-assurance-device:parameters) 1184 | | +--rw service-assurance-device:parameters 1185 | | +--rw service-assurance-device:device string 1186 | +--:(example-service-assurance-device-acme:parameters) 1187 | | +--rw example-service-assurance-device-acme:parameters 1188 | | +--rw example-service-assurance-device-acme:device string 1189 | | +--rw example-service-assurance-device-acme:acme-specific-parameter string 1190 | +--:(service-assurance-interface:parameters) 1191 | +--rw service-assurance-interface:parameters 1192 | +--rw service-assurance-interface:device string 1193 | +--rw service-assurance-interface:interface string 1194 +--ro health-score? uint8 1195 +--ro symptoms-history-start? yang:date-and-time 1196 +--rw symptoms 1197 | +--ro symptom* [start-date-time id] 1198 | +--ro id string 1199 | +--ro health-score-weight? uint8 1200 | +--ro description? string 1201 | +--ro start-date-time yang:date-and-time 1202 | +--ro stop-date-time? yang:date-and-time 1203 +--rw dependencies 1204 +--rw dependency* [type id] 1205 +--rw type -> /subservices/subservice/type 1206 +--rw id -> /subservices/subservice[type=current()/../type]/id 1207 +--rw dependency-type? identityref 1209 8.4. IP Connectivity YANG Module 1211 file "ietf-service-assurance-ip- 1212 connectivity@2021-06-28.yang" 1214 module ietf-service-assurance-ip-connectivity { 1215 yang-version 1.1; 1216 namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-ip-connectivity"; 1217 prefix service-assurance-ip-connectivity; 1219 import ietf-inet-types { 1220 prefix inet; 1221 } 1222 import ietf-service-assurance { 1223 prefix service-assurance; 1224 } 1226 organization 1227 "IETF OPSAWG Working Group"; 1228 contact 1229 "WG Web: 1230 WG List: 1231 Author: Benoit Claise 1232 Author: Jean Quilbeuf "; 1233 description 1234 "This module extends the ietf-service-assurance module to add 1235 support for the subservice ip-connectivity. 1237 Checks whether the ip connectivity between two ip addresses 1238 belonging to two network devices is healthy. 1240 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1241 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1242 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1243 are to be interpreted as described in BCP 14 (RFC 2119) 1244 (RFC 8174) when, and only when, they appear in all 1245 capitals, as shown here. 1247 Copyright (c) 2021 IETF Trust and the persons identified as 1248 authors of the code. All rights reserved. 1249 Redistribution and use in source and binary forms, with or 1250 without modification, is permitted pursuant to, and subject 1251 to the license terms contained in, the Simplified BSD License 1252 set forth in Section 4.c of the IETF Trust's Legal Provisions 1253 Relating to IETF Documents 1254 (https://trustee.ietf.org/license-info). 1256 This version of this YANG module is part of RFC XXXX; see the 1257 RFC itself for full legal notices. "; 1259 revision 2021-06-28 { 1260 description 1261 "Initial revision."; 1262 reference 1263 "RFC xxxx: Title to be completed"; 1264 } 1266 identity ip-connectivity-idty { 1267 base service-assurance:subservice-idty; 1268 description 1269 "Checks connectivity between two IP addresses."; 1270 } 1272 augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" { 1273 description 1274 "Specify the required parameters for the ip-connectivity-idty subservice type"; 1275 container parameters { 1276 when "derived-from-or-self(../service-assurance:type, 'ip-connectivity-idty')"; 1277 description 1278 "Required parameters for the ip-connectivity-idty subservice type"; 1279 leaf device1 { 1280 type string; 1281 mandatory true; 1282 description 1283 "Device at the first end of the connection."; 1284 } 1285 leaf address1 { 1286 type inet:ip-address; 1287 mandatory true; 1288 description 1289 "Address at the first end of the connection."; 1290 } 1291 leaf device2 { 1292 type string; 1293 mandatory true; 1294 description 1295 "Device at the second end of the connection."; 1296 } 1297 leaf address2 { 1298 type inet:ip-address; 1299 mandatory true; 1300 description 1301 "Address at the second end of the connection."; 1303 } 1304 } 1305 } 1306 } 1308 1310 8.5. IS-IS YANG Module 1312 file "ietf-service-assurance-is-is@2021-06-28.yang" 1314 module ietf-service-assurance-is-is { 1315 yang-version 1.1; 1316 namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-is-is"; 1317 prefix service-assurance-is-is; 1319 import ietf-service-assurance { 1320 prefix service-assurance; 1321 } 1323 organization 1324 "IETF NETCONF (Network Configuration) Working Group"; 1325 contact 1326 "WG Web: 1327 WG List: 1328 Author: Benoit Claise 1329 Author: Jean Quilbeuf "; 1330 description 1331 "This module extends the ietf-service-assurance module to add 1332 support for the subservice IS-ISHealthy. 1334 Checks whether an IS-IS instance is healthy. 1336 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1337 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1338 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1339 are to be interpreted as described in BCP 14 (RFC 2119) 1340 (RFC 8174) when, and only when, they appear in all 1341 capitals, as shown here. 1343 Copyright (c) 2021 IETF Trust and the persons identified as 1344 authors of the code. All rights reserved. 1346 Redistribution and use in source and binary forms, with or 1347 without modification, is permitted pursuant to, and subject 1348 to the license terms contained in, the Simplified BSD License 1349 set forth in Section 4.c of the IETF Trust's Legal Provisions 1350 Relating to IETF Documents 1351 (https://trustee.ietf.org/license-info). 1352 This version of this YANG module is part of RFC XXXX; see the 1353 RFC itself for full legal notices. "; 1355 revision 2021-06-28 { 1356 description 1357 "Initial revision."; 1358 reference 1359 "RFC xxxx: Title to be completed"; 1360 } 1362 identity is-is-idty { 1363 base service-assurance:subservice-idty; 1364 description 1365 "Health of IS-IS routing protocol."; 1366 } 1368 augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" { 1369 description 1370 "Specify the required parameters for a new subservice type"; 1371 container parameters { 1372 when "derived-from-or-self(../service-assurance:type, 'is-is-idty')"; 1373 description 1374 "Specify the required parameters for the IS-IS subservice type"; 1375 leaf instance-name { 1376 type string; 1377 mandatory true; 1378 description 1379 "The instance to monitor."; 1380 } 1381 } 1382 } 1383 } 1385 1387 9. Guidelines for Specific Subservice Extension 1389 The base YANG module defined in Section 4.3 only defines a single 1390 type of subservices that represent service instances. As explained 1391 above, this model is meant to be augmented so that a variety of 1392 subservices can be used in the assurance graph. In this section, we 1393 propose some guidelines in order to build theses extensions. 1395 First, the specific subservice must be given an adequate unique short 1396 name that will be used to form longer names (e.g. module name, prefix 1397 ...) appearing in the YANG module. The short name identifies the 1398 type of subpart of feature that the subservice will represent, for 1399 instance if the subservice will assure the health of a network 1400 interafce then "interface" is an adequate short name. If the 1401 subservice will assure the IS-IS routing protocol, then "is-is" is an 1402 adequate short name. The short name must be in kebab-case. 1404 In this section, by subservice YANG module, we mean "YANG module that 1405 extends ieft-service-assurance in order to define a specific 1406 subservice". 1408 9.1. Module Name 1410 For subservice YANG modules vetted by the IETF, the module name 1411 should be "ieft-service-assurance-" followed by the short name. For 1412 instance, "ietf-service-assurance-interface" or "ietf-service- 1413 assurance-is-is". 1415 For subservice YANG module that are directly provided by vendors, we 1416 propose that they use the company in the prefix. For example, the 1417 prefix for the company "acme" would be "acme-assurance-" and the YANG 1418 modules would be "acme-assurance-interface", "acme-assurance-is-is", 1419 etc. 1421 9.2. Module Namespace 1423 For subservice YANG modules vetted by the IETF, the module namespace 1424 should be "urn:ietf:params:xml:ns:yang:ietf-service-assurance-" 1425 followed by the short name. For instance, 1426 "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface" or 1427 "urn:ietf:params:xml:ns:yang:ietf-service-assurance-is-is". 1429 For subservice YANG module that are directly provided by vendors, a 1430 similar pattern can be used with the prefix being a namespace 1431 controlled by the vendor. 1433 9.3. Module Prefix 1435 For subservice YANG modules vetted by the IETF, the module prefix 1436 should be "service-assurance-" followed by the short name. For 1437 instance, "service-assurance-interface" or "service-assurance-is-is". 1439 For subservice YANG module that are directly provided by vendors, the 1440 same pattern can be used provided it does not conflict with an 1441 imported prefix. 1443 9.4. Subservice Specific Identity 1445 Each auqment specific to a subservice must define an identity 1446 representing the type of subpart or features of the network system 1447 that are assured by the subservice. As required in the "ietf- 1448 service-assurance" module (see Section 4.3), that identity must be 1449 based on the "subservice-idty" identity. 1451 For subservice YANG modules vetted by the IETF, the subservice 1452 specific identity should be the short name of the subservice followed 1453 by "-idty". For instance, "interface-idty" or "is-is-identity". 1455 For subservice YANG module that are directly provided by vendors, the 1456 same pattern can be used. 1458 9.5. Parameters 1460 For subservice YANG modules vetted by the IETF, the parameters 1461 specific to the subservice should be placed in a container named 1462 "parameters". That container must be used to augment the "parameter" 1463 choice from the module "ietf-service-assurance" (see Section 4.3 and 1464 that augment must be guarded so that it is effective only for 1465 subservice instance whose type is the subservice specific identity 1466 from Section 9.4. 1468 For subservice YANG module that are directly provided by vendors, the 1469 same pattern can be used. 1471 10. Security Considerations 1473 The YANG module specified in this document defines a schema for data 1474 that is designed to be accessed via network management protocols such 1475 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1476 is the secure transport layer, and the mandatory-to-implement secure 1477 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1478 is HTTPS, and the mandatory-to-implement secure transport is TLS 1479 [RFC8446]. 1481 The Network Configuration Access Control Model (NACM) [RFC8341] 1482 provides the means to restrict access for particular NETCONF or 1483 RESTCONF users to a preconfigured subset of all available NETCONF or 1484 RESTCONF protocol operations and content. 1486 There are a number of data nodes defined in this YANG module that are 1487 writable/ creatable/deletable (i.e., config true, which is the 1488 default). These data nodes may be considered sensitive or vulnerable 1489 in some network environments. Write operations (e.g., edit-config) 1490 to these data nodes without proper protection can have a negative 1491 effect on network operations. These are the subtrees and data nodes 1492 and their sensitivity/vulnerability: 1494 o /subservices/subservice/type 1496 o /subservices/subservice/id 1498 o /subservices/subservice/under-maintenance 1500 o /subservices/subservice/maintenance-contact 1502 11. IANA Considerations 1504 11.1. The IETF XML Registry 1506 This document registers two URIs in the IETF XML registry [RFC3688]. 1507 Following the format in [RFC3688], the following registrations are 1508 requested: 1510 URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance 1511 Registrant Contact: The NETCONF WG of the IETF. 1512 XML: N/A, the requested URI is an XML namespace. 1514 URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device 1515 Registrant Contact: The NETCONF WG of the IETF. 1516 XML: N/A, the requested URI is an XML namespace. 1518 URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface 1519 Registrant Contact: The NETCONF WG of the IETF. 1520 XML: N/A, the requested URI is an XML namespace. 1522 11.2. The YANG Module Names Registry 1524 This document registers three YANG modules in the YANG Module Names 1525 registry [RFC7950]. Following the format in [RFC7950], the the 1526 following registrations are requested: 1528 name: ietf-service-assurance 1529 namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance 1530 prefix: inc 1531 reference: RFC XXXX 1533 name: ietf-service-assurance-device 1534 namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device 1535 prefix: inc 1536 reference: RFC XXXX 1538 name: ietf-service-assurance-interface 1539 namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface 1540 prefix: inc 1541 reference: RFC XXXX 1543 12. Open Issues 1545 -None 1547 13. References 1549 13.1. Normative References 1551 [I-D.ietf-opsawg-service-assurance-architecture] 1552 Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T. 1553 Arumugam, "draft-claise-opsawg-service-assurance- 1554 architecture", 2020. 1556 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1557 and A. Bierman, Ed., "Network Configuration Protocol 1558 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1559 . 1561 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1562 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1563 . 1565 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1566 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1567 . 1569 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1570 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1571 . 1573 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1574 Access Control Model", STD 91, RFC 8341, 1575 DOI 10.17487/RFC8341, March 2018, 1576 . 1578 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1579 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1580 . 1582 13.2. Informative References 1584 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1585 Requirement Levels", BCP 14, RFC 2119, 1586 DOI 10.17487/RFC2119, March 1997, 1587 . 1589 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1590 DOI 10.17487/RFC3688, January 2004, 1591 . 1593 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 1594 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 1595 . 1597 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1598 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1599 May 2017, . 1601 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1602 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1603 . 1605 13.3. URIs 1607 [1] https://yangson.labs.nic.cz/ 1609 Appendix A. Example of YANG instances 1611 This section contains examples of YANG instances that conform to the 1612 YANG modules. The validity of these data instances has been checked 1613 using yangson [1]. Yangson requires a YANG library [RFC7895] to 1614 define the complete model against which the data instance must be 1615 validated. We provide in Appendix B the JSON library file, named 1616 "ietf-service-assurance-library.json", that we used for validation. 1618 We provide below the contents of the file 1619 "example_configuration_instance.json" which contains the 1620 configuration data that models the Figure 2 of 1622 [I-D.ietf-opsawg-service-assurance-architecture]. The instance can 1623 be validated with yangson by using the invocation "yangson -v 1624 example_configuration_instance.json ietf-service-assurance- 1625 library.json", assuming all the files (YANG and JSON) defined in this 1626 draft reside in the current folder. 1628 file "example_configuration_instance.json" 1630 { 1631 "ietf-service-assurance:subservices": { 1632 "subservice": [ 1633 { 1634 "type": "service-instance-idty", 1635 "id": "simple-tunnel/example", 1636 "service-instance-parameter": { 1637 "service": "simple-tunnel", 1638 "instance-name": "example" 1639 }, 1640 "dependencies": { 1641 "dependency": [ 1642 { 1643 "type": "ietf-service-assurance-interface:interface-idty", 1644 "id": "interface/peer1/tunnel0", 1645 "dependency-type": "impacting-dependency" 1646 }, 1647 { 1648 "type": "ietf-service-assurance-interface:interface-idty", 1649 "id": "interface/peer2/tunnel9", 1650 "dependency-type": "impacting-dependency" 1651 }, 1652 { 1653 "type": "ietf-service-assurance-ip-connectivity:ip-connectivity-idty", 1654 "id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2", 1655 "dependency-type": "impacting-dependency" 1656 } 1657 ] 1658 } 1659 }, 1660 { 1661 "type": "ietf-service-assurance-ip-connectivity:ip-connectivity-idty", 1662 "id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2", 1663 "ietf-service-assurance-ip-connectivity:parameters": { 1664 "device1": "Peer1", 1665 "address1": "2001:db8::1", 1666 "device2": "Peer2", 1667 "address2": "2001:db8::2" 1668 }, 1669 "dependencies": { 1670 "dependency": [ 1671 { 1672 "type": "ietf-service-assurance-interface:interface-idty", 1673 "id": "interface/peer1/physical0", 1674 "dependency-type": "impacting-dependency" 1675 }, 1676 { 1677 "type": "ietf-service-assurance-interface:interface-idty", 1678 "id": "interface/peer2/physical5", 1679 "dependency-type": "impacting-dependency" 1680 }, 1681 { 1682 "type": "ietf-service-assurance-is-is:is-is-idty", 1683 "id": "is-is/instance1", 1684 "dependency-type": "impacting-dependency" 1685 } 1686 ] 1687 } 1688 }, 1689 { 1690 "type": "ietf-service-assurance-is-is:is-is-idty", 1691 "id": "is-is/instance1", 1692 "ietf-service-assurance-is-is:parameters": { 1693 "instance-name": "instance1" 1694 } 1695 }, 1696 { 1697 "type": "ietf-service-assurance-interface:interface-idty", 1698 "id": "interface/peer1/tunnel0", 1699 "ietf-service-assurance-interface:parameters": { 1700 "device": "Peer1", 1701 "interface": "tunnel0" 1702 }, 1703 "dependencies": { 1704 "dependency": [ 1705 { 1706 "type": "ietf-service-assurance-interface:interface-idty", 1707 "id": "interface/peer1/physical0", 1708 "dependency-type": "impacting-dependency" 1709 } 1710 ] 1711 } 1712 }, 1713 { 1714 "type": "ietf-service-assurance-interface:interface-idty", 1715 "id": "interface/peer1/physical0", 1716 "ietf-service-assurance-interface:parameters": { 1717 "device": "Peer1", 1718 "interface": "physical0" 1719 }, 1720 "dependencies": { 1721 "dependency": [ 1722 { 1723 "type": "ietf-service-assurance-device:device-idty", 1724 "id": "interface/peer1", 1725 "dependency-type": "impacting-dependency" 1726 } 1727 ] 1728 } 1729 }, 1730 { 1731 "type": "ietf-service-assurance-device:device-idty", 1732 "id": "interface/peer1", 1733 "ietf-service-assurance-device:parameters": { 1734 "device": "Peer1" 1735 } 1736 }, 1737 { 1738 "type": "ietf-service-assurance-interface:interface-idty", 1739 "id": "interface/peer2/tunnel9", 1740 "ietf-service-assurance-interface:parameters": { 1741 "device": "Peer2", 1742 "interface": "tunnel9" 1743 }, 1744 "dependencies": { 1745 "dependency": [ 1746 { 1747 "type": "ietf-service-assurance-interface:interface-idty", 1748 "id": "interface/peer2/physical5", 1749 "dependency-type": "impacting-dependency" 1750 } 1751 ] 1752 } 1753 }, 1754 { 1755 "type": "ietf-service-assurance-interface:interface-idty", 1756 "id": "interface/peer2/physical5", 1757 "ietf-service-assurance-interface:parameters": { 1758 "device": "Peer2", 1759 "interface": "physical5" 1760 }, 1761 "dependencies": { 1762 "dependency": [ 1763 { 1764 "type": "ietf-service-assurance-device:device-idty", 1765 "id": "interface/peer2", 1766 "dependency-type": "impacting-dependency" 1767 } 1768 ] 1769 } 1770 }, 1771 { 1772 "type": "ietf-service-assurance-device:device-idty", 1773 "id": "interface/peer2", 1774 "ietf-service-assurance-device:parameters": { 1775 "device": "Peer2" 1776 } 1777 } 1778 ] 1779 } 1780 } 1782 1784 Appendix B. YANG Library for Service Assurance 1786 This section provides the JSON encoding of the YANG library [RFC7895] 1787 listing all modules defined in this draft and their dependencies. 1788 This library can be used to validate data instances using yangson, as 1789 explained in the previous section. 1791 file "ietf-service-assurance-library.json" 1793 { 1794 "ietf-yang-library:modules-state": { 1795 "module-set-id": "ietf-service-assurance@2020-01-13", 1796 "module": [ 1797 { 1798 "name": "ietf-service-assurance", 1799 "namespace": "urn:ietf:params:xml:ns:yang:ietf-service-assurance", 1800 "revision": "2021-06-28", 1801 "conformance-type": "implement" 1802 }, 1803 { 1804 "name": "ietf-service-assurance-device", 1805 "namespace": "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device", 1806 "revision": "2021-06-28", 1807 "conformance-type": "implement" 1808 }, 1809 { 1810 "name": "ietf-service-assurance-interface", 1811 "namespace": "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface", 1812 "revision": "2021-06-28", 1813 "conformance-type": "implement" 1815 }, 1816 { 1817 "name": "example-service-assurance-device-acme", 1818 "namespace": "urn:example:example-service-assurance-device-acme", 1819 "revision": "2021-06-28", 1820 "conformance-type": "implement" 1821 }, 1822 { 1823 "name": "ietf-service-assurance-is-is", 1824 "namespace": "urn:ietf:payams:xml:ns:yang:ietf-service-assurance-is-is", 1825 "revision": "2021-06-28", 1826 "conformance-type": "implement" 1827 }, 1828 { 1829 "name": "ietf-service-assurance-ip-connectivity", 1830 "namespace": "urn:ietf:payams:xml:ns:yang:ietf-service-assurance-ip-connectivity", 1831 "revision": "2021-06-28", 1832 "conformance-type": "implement" 1833 }, 1834 { 1835 "name": "ietf-yang-types", 1836 "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1837 "revision": "2021-04-14", 1838 "conformance-type": "import" 1839 }, 1840 { 1841 "name": "ietf-inet-types", 1842 "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1843 "revision": "2021-02-22", 1844 "conformance-type": "import" 1845 } 1846 ] 1847 } 1848 } 1850 1852 Appendix C. Changes between revisions 1854 v00 - v01 1856 o Added needed subservice to model example from architecture draft 1858 o Added guideline section for naming models 1860 o Added data instance examples and validation procedure 1861 o Added the "parameters" container in the interface YANG module to 1862 correct a bug. 1864 Acknowledgements 1866 The authors would like to thank Jan Lindblad for his help during the 1867 design of these YANG modules. The authors would like to thank 1868 Stephane Litkowski and Charles Eckel for their reviews. 1870 Authors' Addresses 1872 Benoit Claise 1873 Huawei 1875 Email: benoit.claise@huawei.com 1877 Jean Quilbeuf 1878 Huawei 1880 Email: jean.quilbeuf@huawei.com 1882 Paolo Lucente 1883 NTT 1884 Siriusdreef 70-72 1885 Hoofddorp, WT 2132 1886 Netherlands 1888 Email: paolo@ntt.net 1890 Paolo Fasano 1891 TIM S.p.A 1892 via G. Reiss Romoli, 274 1893 10148 Torino 1894 Italy 1896 Email: paolo2.fasano@telecomitalia.it 1898 Thangam Arumugam 1899 Cisco Systems, Inc. 1900 Milpitas (California) 1901 United States 1903 Email: tarumuga@cisco.com