| < draft-ietf-opsawg-service-assurance-yang-04.txt | draft-ietf-opsawg-service-assurance-yang-05.txt > | |||
|---|---|---|---|---|
| OPSAWG B. Claise | OPSAWG B. Claise | |||
| Internet-Draft J. Quilbeuf | Internet-Draft J. Quilbeuf | |||
| Intended status: Standards Track Huawei | Intended status: Standards Track Huawei | |||
| Expires: 27 October 2022 P. Lucente | Expires: 31 October 2022 P. Lucente | |||
| NTT | NTT | |||
| P. Fasano | P. Fasano | |||
| TIM S.p.A | TIM S.p.A | |||
| T. Arumugam | T. Arumugam | |||
| Cisco Systems, Inc. | Cisco Systems, Inc. | |||
| 25 April 2022 | 29 April 2022 | |||
| YANG Modules for Service Assurance | YANG Modules for Service Assurance | |||
| draft-ietf-opsawg-service-assurance-yang-04 | draft-ietf-opsawg-service-assurance-yang-05 | |||
| Abstract | Abstract | |||
| This document specifies YANG modules representing assurance graphs. | This document specifies YANG modules representing assurance graphs. | |||
| These graphs represent the assurance of a given service by | These graphs represent the assurance of a given service by | |||
| decomposing it into atomic assurance elements called subservices. A | decomposing it into atomic assurance elements called subservices. A | |||
| companion RFC, Service Assurance for Intent-based Networking | companion RFC, Service Assurance for Intent-based Networking | |||
| Architecture, presents an architecture for implementing the assurance | Architecture, presents an architecture for implementing the assurance | |||
| of such services. | of such services. | |||
| skipping to change at page 1, line 44 ¶ | skipping to change at page 1, line 44 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 27 October 2022. | This Internet-Draft will expire on 31 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 2, line 35 ¶ | skipping to change at page 2, line 35 ¶ | |||
| 4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 15 | 4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 4.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 15 | 4.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 15 | |||
| 4.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 16 | 4.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 4.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17 | 4.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 5. Subservice Extension: ietf-service-assurance-interface YANG | 5. Subservice Extension: ietf-service-assurance-interface YANG | |||
| module . . . . . . . . . . . . . . . . . . . . . . . . . 19 | module . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 19 | 5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 19 | 5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 19 | |||
| 5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 20 | 5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 21 | 5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
| 6. Vendor-specific Subservice Extension: | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 | |||
| example-service-assurance-device-acme YANG module . . . . 23 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 23 | 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 24 | |||
| 6.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 23 | 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 24 | |||
| 6.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 25 | 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
| 6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 25 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
| 7. Further Extensions: IP Connectivity and IS-IS subservices . . 27 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 | |||
| 7.1. IP Connectivity Tree View . . . . . . . . . . . . . . . . 27 | 9.2. Informative References . . . . . . . . . . . . . . . . . 25 | |||
| 7.2. IS-IS Tree View . . . . . . . . . . . . . . . . . . . . . 28 | Appendix A. Vendor-specific Subservice Extension: | |||
| 7.3. Global Tree View . . . . . . . . . . . . . . . . . . . . 28 | example-service-assurance-device-acme YANG module . . . . 26 | |||
| 7.4. IP Connectivity YANG Module . . . . . . . . . . . . . . . 29 | A.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
| 7.5. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . 32 | A.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 26 | |||
| 8. Guidelines for Specific Subservice Extension . . . . . . . . 33 | A.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 8.1. Module Name . . . . . . . . . . . . . . . . . . . . . . . 34 | A.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 8.2. Module Namespace . . . . . . . . . . . . . . . . . . . . 34 | Appendix B. Further Extensions: IP Connectivity and IS-IS | |||
| 8.3. Module Prefix . . . . . . . . . . . . . . . . . . . . . . 34 | subservices . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
| 8.4. Subservice Specific Identity . . . . . . . . . . . . . . 35 | B.1. IP Connectivity Tree View . . . . . . . . . . . . . . . . 30 | |||
| 8.5. Parameters . . . . . . . . . . . . . . . . . . . . . . . 35 | B.2. IS-IS Tree View . . . . . . . . . . . . . . . . . . . . . 31 | |||
| B.3. Global Tree View . . . . . . . . . . . . . . . . . . . . 31 | ||||
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 | B.4. IP Connectivity YANG Module . . . . . . . . . . . . . . . 32 | |||
| 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 | B.5. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . 35 | |||
| 10.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 36 | Appendix C. Example of YANG instances . . . . . . . . . . . . . 37 | |||
| 10.2. The YANG Module Names Registry . . . . . . . . . . . . . 36 | Appendix D. YANG Library for Service Assurance . . . . . . . . . 40 | |||
| 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 37 | Appendix E. Changes between revisions . . . . . . . . . . . . . 42 | |||
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
| 12.1. Normative References . . . . . . . . . . . . . . . . . . 37 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
| 12.2. Informative References . . . . . . . . . . . . . . . . . 38 | ||||
| Appendix A. Example of YANG instances . . . . . . . . . . . . . 38 | ||||
| Appendix B. YANG Library for Service Assurance . . . . . . . . . 42 | ||||
| Appendix C. Changes between revisions . . . . . . . . . . . . . 43 | ||||
| Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 44 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 | ||||
| 1. Introduction | 1. Introduction | |||
| The "Service Assurance for Intent-based Networking Architecture" | The "Service Assurance for Intent-based Networking Architecture" | |||
| [I-D.ietf-opsawg-service-assurance-architecture], specifies the | [I-D.ietf-opsawg-service-assurance-architecture], specifies the | |||
| architecture and all of its components for service assurance. This | architecture and all of its components for service assurance. This | |||
| document complements the architecture by providing open interfaces | document complements the architecture by providing open interfaces | |||
| between components. More specifically, the goal is to provide YANG | between components. More specifically, the goal is to provide YANG | |||
| modules for the purpose of service assurance in a format that is: | modules for the purpose of service assurance in a format that is: | |||
| skipping to change at page 4, line 25 ¶ | skipping to change at page 4, line 21 ¶ | |||
| * Assurance telemetry: export the health status of the subservices, | * Assurance telemetry: export the health status of the subservices, | |||
| along with the observed symptoms. | along with the observed symptoms. | |||
| The main module represents the configuration (subservice and | The main module represents the configuration (subservice and | |||
| dependencies) and operational data (health status and symptoms) in a | dependencies) and operational data (health status and symptoms) in a | |||
| single tree. Other modules follows the same pattern. Thus, the | single tree. Other modules follows the same pattern. Thus, the | |||
| modules presented in this document conform to the Network Management | modules presented in this document conform to the Network Management | |||
| Datastore Architecture defined in [RFC8342]. | Datastore Architecture defined in [RFC8342]. | |||
| The second YANG module, ietf-service-assurance-device, extends the | The second YANG module, ietf-service-assurance-device, extends the | |||
| ietf-service-assurance module to add support for the subservice | ietf-service-assurance module to add support for the device | |||
| DeviceHealthy. Additional subservice types might be added the same | subservice. Additional subservice types might be added the same way. | |||
| way. | ||||
| The third YANG module, ietf-service-assurance-device, is another | ||||
| example that extends the ietf-service-assurance-device module. This | ||||
| extension adds support for the subservice InterfaceHealthy. | ||||
| The fourth YANG module, example-service-assurance-device-acme, | The third YANG module, ietf-service-assurance-interface, is another | |||
| extends the ietf-service-assurance-device module as an example to add | example that extends the ietf-service-assurance module. This | |||
| support for the subservice DeviceHealthy, with specifics for the | extension adds support for the interface subservice. | |||
| fictional ACME Corporation. Additional vendor-specific parameters | ||||
| might be added the same way. | ||||
| Finally, the modules example-service-assurance-ip-connectivity and | We provide additional examples in the appendix. The module example- | |||
| example-service-assurance-is-is are provided to completely model the | service-assurance-device-acme extends the ietf-service-assurance- | |||
| example from the SAIN architecture draft | device module to customize it for devices of the fictional ACME | |||
| Corporation. Additional vendor-specific parameters might be added | ||||
| the same way. We also provide the modules example-service-assurance- | ||||
| ip-connectivity and example-service-assurance-is-is to completely | ||||
| model the example from the SAIN architecture draft | ||||
| [I-D.ietf-opsawg-service-assurance-architecture]. | [I-D.ietf-opsawg-service-assurance-architecture]. | |||
| 3. Base ietf-service-assurance YANG module | 3. Base ietf-service-assurance YANG module | |||
| 3.1. Tree View | 3.1. Tree View | |||
| The following tree diagram [RFC8340] provides an overview of the | The following tree diagram [RFC8340] provides an overview of the | |||
| ietf-service-assurance data model. | ietf-service-assurance data model. | |||
| module: ietf-service-assurance | module: ietf-service-assurance | |||
| skipping to change at page 5, line 44 ¶ | skipping to change at page 5, line 44 ¶ | |||
| +--rw id leafref | +--rw id leafref | |||
| +--rw dependency-type? identityref | +--rw dependency-type? identityref | |||
| 3.2. Concepts | 3.2. Concepts | |||
| The ietf-service-assurance YANG model assumes an identified number of | The ietf-service-assurance YANG model assumes an identified number of | |||
| subservices, to be assured independently. A subservice is a feature | subservices, to be assured independently. A subservice is a feature | |||
| or a subpart of the network system that a given service instance | or a subpart of the network system that a given service instance | |||
| might depend on. Example of subservices include: | might depend on. Example of subservices include: | |||
| * DeviceHealthy: whether a device is healthy, and if not, what are | * device: whether a device is healthy, and if not, what are the | |||
| the symptoms. Potential symptoms are "CPU overloaded", "Out of | symptoms. Potential symptoms are "CPU overloaded", "Out of RAM", | |||
| RAM", or "Out of TCAM". | or "Out of TCAM". | |||
| * ConnectivityHealthy: given two IP addresses owned by two devices, | * ip-connectivity: given two IP addresses owned by two devices, what | |||
| what is the quality of the connection between them. Potential | is the quality of the connection between them. Potential symptoms | |||
| symptoms are "No route available" or "ECMP Imbalance". | are "No route available" or "ECMP Imbalance". | |||
| The first example is a subservice representing a subpart of the | The first example is a subservice representing a subpart of the | |||
| network system, while the second is a subservice representing a | network system, while the second is a subservice representing a | |||
| feature of the network, In both cases, these subservices might depend | feature of the network, In both cases, these subservices might depend | |||
| on other subservices, for instance, the connectivity might depend on | on other subservices, for instance, the connectivity might depend on | |||
| a subservice representing the routing mechanism and on a subservice | a subservice representing the routing mechanism and on a subservice | |||
| representing ECMP. | representing ECMP. | |||
| The status of each subservice contains a list of symptoms. Each | The status of each subservice contains a list of symptoms. Each | |||
| symptom is specified by a unique id and contains a health-score- | symptom is specified by a unique id and contains a health-score- | |||
| skipping to change at page 7, line 12 ¶ | skipping to change at page 7, line 12 ¶ | |||
| to indicate the dependencies. Dependencies have types as well. Two | to indicate the dependencies. Dependencies have types as well. Two | |||
| types are specified in the model: | types are specified in the model: | |||
| * Impacting: such a dependency indicates an impact on the health of | * Impacting: such a dependency indicates an impact on the health of | |||
| the dependent, | the dependent, | |||
| * Informational: such a dependency might explain why the dependent | * Informational: such a dependency might explain why the dependent | |||
| has issues but does not impact its health. | has issues but does not impact its health. | |||
| To illustrate the difference between "impacting" and "informational", | To illustrate the difference between "impacting" and "informational", | |||
| consider the subservice InterfaceHealthy, representing a network | consider the interface subservice, representing a network interface. | |||
| interface. If the device to which the network interface belongs goes | If the device to which the network interface belongs goes down, the | |||
| down, the network interface will transition to a down state as well. | network interface will transition to a down state as well. | |||
| Therefore, the dependency of InterfaceHealthy towards DeviceHealthy | Therefore, the dependency of the interface subservice towards the | |||
| is "impacting". On the other hand, as a the dependency towards the | device subservice is "impacting". On the other hand, a dependency | |||
| ECMPLoad subservice, which checks that the load between ECMP remains | towards the ecmp-load subservice, which checks that the load between | |||
| ce remains stable throughout time, is only "informational". Indeed, | ECMP remains stable throughout time, is only "informational". | |||
| services might be perfectly healthy even if the load distribution | Indeed, services might be perfectly healthy even if the load | |||
| between ECMP changed. However, such an instability might be a | distribution between ECMP changed. However, such an instability | |||
| relevant symptom for diagnosing the root cause of a problem. | might be a relevant symptom for diagnosing the root cause of a | |||
| problem. | ||||
| Service instances MUST be modeled as a particular type of subservice | Service instances MUST be modeled as a particular type of subservice | |||
| with two parameters, a type and an instance name. The type is the | with two parameters, a type and an instance name. The type is the | |||
| name of the service defined in the network orchestrator, for instance | name of the service defined in the network orchestrator, for instance | |||
| "point-to-point-l2vpn". The instance name is the name assigned to | "point-to-point-l2vpn". The instance name is the name assigned to | |||
| the particular instance that we are assuring, for instance the name | the particular instance to be assured, for instance the name of the | |||
| of the customer using that instance. | customer using that instance. | |||
| The "under-maintenance" and "maintenance-contact" flags inhibit the | The "under-maintenance" and "maintenance-contact" flags inhibit the | |||
| emission of symptoms for that subservice and subservices that depend | emission of symptoms for that subservice and subservices that depend | |||
| on them. See Section 3.7 of | on them. See Section 3.7 of | |||
| [I-D.ietf-opsawg-service-assurance-architecture] for a more detailed | [I-D.ietf-opsawg-service-assurance-architecture] for a more detailed | |||
| discussion. | discussion. | |||
| By specifying service instances and their dependencies in terms of | By specifying service instances and their dependencies in terms of | |||
| subservices, one defines the whole assurance to apply for them. An | subservices, one defines the whole assurance to apply for them. An | |||
| assurance agent supporting this model should then produce telemetry | assurance agent supporting this model should then produce telemetry | |||
| skipping to change at page 11, line 19 ¶ | skipping to change at page 11, line 26 ¶ | |||
| } | } | |||
| grouping subservice-dependency { | grouping subservice-dependency { | |||
| description | description | |||
| "Represent a dependency to another subservice."; | "Represent a dependency to another subservice."; | |||
| leaf type { | leaf type { | |||
| type leafref { | type leafref { | |||
| path "/subservices/subservice/type"; | path "/subservices/subservice/type"; | |||
| } | } | |||
| description | description | |||
| "The type of the subservice to refer to (e.g. DeviceHealthy)."; | "The type of the subservice to refer to (e.g. device)."; | |||
| } | } | |||
| leaf id { | leaf id { | |||
| type leafref { | type leafref { | |||
| path "/subservices/subservice[type=current()/../type]/id"; | path "/subservices/subservice[type=current()/../type]/id"; | |||
| } | } | |||
| description | description | |||
| "The identifier of the subservice to refer to."; | "The identifier of the subservice to refer to."; | |||
| } | } | |||
| leaf dependency-type { | leaf dependency-type { | |||
| type identityref { | type identityref { | |||
| skipping to change at page 12, line 25 ¶ | skipping to change at page 12, line 31 ¶ | |||
| "Root container for the subservices."; | "Root container for the subservices."; | |||
| list subservice { | list subservice { | |||
| key "type id"; | key "type id"; | |||
| description | description | |||
| "List of subservice configured."; | "List of subservice configured."; | |||
| leaf type { | leaf type { | |||
| type identityref { | type identityref { | |||
| base subservice-idty; | base subservice-idty; | |||
| } | } | |||
| description | description | |||
| "Name of the subservice, e.g. DeviceHealthy."; | "Type of the subservice, for instance device or interface."; | |||
| } | } | |||
| leaf id { | leaf id { | |||
| type string; | type string; | |||
| description | description | |||
| "Unique identifier of the subservice instance, for each | "Unique identifier of the subservice instance, for each | |||
| type."; | type."; | |||
| } | } | |||
| leaf last-change { | leaf last-change { | |||
| type yang:date-and-time; | type yang:date-and-time; | |||
| config false; | config false; | |||
| skipping to change at page 16, line 45 ¶ | skipping to change at page 16, line 45 ¶ | |||
| +--rw type | +--rw type | |||
| | -> /subservices/subservice/type | | -> /subservices/subservice/type | |||
| +--rw id leafref | +--rw id leafref | |||
| +--rw dependency-type? identityref | +--rw dependency-type? identityref | |||
| 4.3. Concepts | 4.3. Concepts | |||
| As the number of subservices will grow over time, the YANG module is | As the number of subservices will grow over time, the YANG module is | |||
| designed to be extensible. A new subservice type requires the | designed to be extensible. A new subservice type requires the | |||
| precise specifications of its type and expected parameters. Let us | precise specifications of its type and expected parameters. Let us | |||
| illustrate the example of the new DeviceHealthy subservice type. As | illustrate the example of the new device subservice type. As the | |||
| the name implies, it monitors and reports the device health, along | name implies, it monitors and reports the device health, along with | |||
| with some symptoms in case of degradation. | some symptoms in case of degradation. | |||
| For our DeviceHealthy subservice definition, the new identity device- | For our device subservice definition, the new identity device-idty is | |||
| idty is specified, as an inheritance from the base identity for | specified, as an inheritance from the base identity for subservices. | |||
| subservices. This indicates to the assurance agent that we are now | This indicates to the assurance agent that we are now assuring the | |||
| assuring the health of a device. | health of a device. | |||
| The typical parameter for the configuration of the DeviceHealthy | The typical parameter for the configuration of the device subservice | |||
| subservice is the name of the device that we want to assure. By | is the name of the device that we want to assure. By augmenting the | |||
| augmenting the parameter choice from ietf-service-assurance YANG | parameter choice from ietf-service-assurance YANG module for the case | |||
| module for the case of the device-idty subservice type, this new | of the device-idty subservice type, this new parameter is specified. | |||
| parameter is specified. | ||||
| 4.4. YANG Module | 4.4. YANG Module | |||
| <CODE BEGINS> file "ietf-service-assurance-device@2022-04-07.yang" | <CODE BEGINS> file "ietf-service-assurance-device@2022-04-07.yang" | |||
| module ietf-service-assurance-device { | module ietf-service-assurance-device { | |||
| yang-version 1.1; | yang-version 1.1; | |||
| namespace | namespace | |||
| "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device"; | "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device"; | |||
| prefix sain-device; | prefix sain-device; | |||
| skipping to change at page 17, line 41 ¶ | skipping to change at page 17, line 40 ¶ | |||
| organization | organization | |||
| "IETF OPSAWG Working Group"; | "IETF OPSAWG Working Group"; | |||
| contact | contact | |||
| "WG Web: <https://datatracker.ietf.org/wg/opsawg/> | "WG Web: <https://datatracker.ietf.org/wg/opsawg/> | |||
| WG List: <mailto:opsawg@ietf.org> | WG List: <mailto:opsawg@ietf.org> | |||
| Author: Benoit Claise <mailto:benoit.claise@huawei.com> | Author: Benoit Claise <mailto:benoit.claise@huawei.com> | |||
| Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>"; | Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>"; | |||
| description | description | |||
| "This module extends the ietf-service-assurance module to add | "This module extends the ietf-service-assurance module to add | |||
| support for the subservice DeviceHealthy. | support for the device subservice. | |||
| Checks whether a network device is healthy. | Checks whether a network device is healthy. | |||
| The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', | The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', | |||
| 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', | 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', | |||
| 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document | 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document | |||
| are to be interpreted as described in BCP 14 (RFC 2119) | are to be interpreted as described in BCP 14 (RFC 2119) | |||
| (RFC 8174) when, and only when, they appear in all | (RFC 8174) when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| skipping to change at page 20, line 46 ¶ | skipping to change at page 20, line 46 ¶ | |||
| | +--ro stop-date-time? yang:date-and-time | | +--ro stop-date-time? yang:date-and-time | |||
| +--rw dependencies | +--rw dependencies | |||
| +--rw dependency* [type id] | +--rw dependency* [type id] | |||
| +--rw type | +--rw type | |||
| | -> /subservices/subservice/type | | -> /subservices/subservice/type | |||
| +--rw id leafref | +--rw id leafref | |||
| +--rw dependency-type? identityref | +--rw dependency-type? identityref | |||
| 5.3. Concepts | 5.3. Concepts | |||
| For our InterfaceHealthy subservice definition, the new interface- | For our interface subservice definition, the new interface-idty is | |||
| idty is specified, as an inheritance from the base identity for | specified, as an inheritance from the base identity for subservices. | |||
| subservices. This indicates to the assurance agent that we are now | This indicates to the assurance agent that we are now assuring the | |||
| assuring the health of an interface. | health of an interface. | |||
| The typical parameters for the configuration of the InterfaceHealthy | The typical parameters for the configuration of the interface | |||
| subservice are the name of the device and, on that specific device, a | subservice are the name of the device and, on that specific device, a | |||
| specific interface. By augmenting the parameter choice from ietf- | specific interface. By augmenting the parameter choice from ietf- | |||
| service-assurance YANG module for the case of the interface-idty | service-assurance YANG module for the case of the interface-idty | |||
| subservice type, those two new parameters are specified. | subservice type, those two new parameters are specified. | |||
| 5.4. YANG Module | 5.4. YANG Module | |||
| <CODE BEGINS> file "ietf-service-assurance-interface@2022-04-07.yang" | <CODE BEGINS> file "ietf-service-assurance-interface@2022-04-07.yang" | |||
| module ietf-service-assurance-interface { | module ietf-service-assurance-interface { | |||
| skipping to change at page 21, line 36 ¶ | skipping to change at page 21, line 36 ¶ | |||
| organization | organization | |||
| "IETF OPSAWG Working Group"; | "IETF OPSAWG Working Group"; | |||
| contact | contact | |||
| "WG Web: <https://datatracker.ietf.org/wg/opsawg/> | "WG Web: <https://datatracker.ietf.org/wg/opsawg/> | |||
| WG List: <mailto:opsawg@ietf.org> | WG List: <mailto:opsawg@ietf.org> | |||
| Author: Benoit Claise <mailto:benoit.claise@huawei.com> | Author: Benoit Claise <mailto:benoit.claise@huawei.com> | |||
| Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>"; | Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>"; | |||
| description | description | |||
| "This module extends the ietf-service-assurance module to add | "This module extends the ietf-service-assurance module to add | |||
| support for the subservice InterfaceHealthy. | support for the interface subservice. | |||
| Checks whether an interface is healthy. | Checks whether an interface is healthy. | |||
| The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', | The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', | |||
| 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', | 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', | |||
| 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document | 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document | |||
| are to be interpreted as described in BCP 14 (RFC 2119) | are to be interpreted as described in BCP 14 (RFC 2119) | |||
| (RFC 8174) when, and only when, they appear in all | (RFC 8174) when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| skipping to change at page 23, line 16 ¶ | skipping to change at page 23, line 16 ¶ | |||
| mandatory true; | mandatory true; | |||
| description | description | |||
| "Name of the interface."; | "Name of the interface."; | |||
| } | } | |||
| } | } | |||
| } | } | |||
| } | } | |||
| <CODE ENDS> | <CODE ENDS> | |||
| 6. Vendor-specific Subservice Extension: example-service-assurance- | 6. Security Considerations | |||
| device-acme YANG module | ||||
| 6.1. Tree View | The YANG module specified in this document defines a schema for data | |||
| that is designed to be accessed via network management protocols such | ||||
| as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer | ||||
| is the secure transport layer, and the mandatory-to-implement secure | ||||
| transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer | ||||
| is HTTPS, and the mandatory-to-implement secure transport is TLS | ||||
| [RFC8446]. | ||||
| The Network Configuration Access Control Model (NACM) [RFC8341] | ||||
| provides the means to restrict access for particular NETCONF or | ||||
| RESTCONF users to a preconfigured subset of all available NETCONF or | ||||
| RESTCONF protocol operations and content. | ||||
| There are a number of data nodes defined in this YANG module that are | ||||
| writable/ creatable/deletable (i.e., config true, which is the | ||||
| default). These data nodes may be considered sensitive or vulnerable | ||||
| in some network environments. Write operations (e.g., edit-config) | ||||
| to these data nodes without proper protection can have a negative | ||||
| effect on network operations. These are the subtrees and data nodes | ||||
| and their sensitivity/vulnerability: | ||||
| * /subservices/subservice/type | ||||
| * /subservices/subservice/id | ||||
| * /subservices/subservice/under-maintenance | ||||
| * /subservices/subservice/maintenance-contact | ||||
| 7. IANA Considerations | ||||
| 7.1. The IETF XML Registry | ||||
| This document registers two URIs in the IETF XML registry [RFC3688]. | ||||
| Following the format in [RFC3688], the following registrations are | ||||
| requested: | ||||
| URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance | ||||
| Registrant Contact: The NETCONF WG of the IETF. | ||||
| XML: N/A, the requested URI is an XML namespace. | ||||
| URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device | ||||
| Registrant Contact: The NETCONF WG of the IETF. | ||||
| XML: N/A, the requested URI is an XML namespace. | ||||
| URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface | ||||
| Registrant Contact: The NETCONF WG of the IETF. | ||||
| XML: N/A, the requested URI is an XML namespace. | ||||
| 7.2. The YANG Module Names Registry | ||||
| This document registers three YANG modules in the YANG Module Names | ||||
| registry [RFC7950]. Following the format in [RFC7950], the the | ||||
| following registrations are requested: | ||||
| name: ietf-service-assurance | ||||
| namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance | ||||
| prefix: sain | ||||
| reference: RFC XXXX | ||||
| name: ietf-service-assurance-device | ||||
| namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device | ||||
| prefix: sain-device | ||||
| reference: RFC XXXX | ||||
| name: ietf-service-assurance-interface | ||||
| namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface | ||||
| prefix: sain-interface | ||||
| reference: RFC XXXX | ||||
| 8. Open Issues | ||||
| -None | ||||
| 9. References | ||||
| 9.1. Normative References | ||||
| [I-D.ietf-opsawg-service-assurance-architecture] | ||||
| Claise, B., Quilbeuf, J., Lopez, D. R., Voyer, D., and T. | ||||
| Arumugam, "Service Assurance for Intent-based Networking | ||||
| Architecture", Work in Progress, Internet-Draft, draft- | ||||
| ietf-opsawg-service-assurance-architecture-03, 7 March | ||||
| 2022, <https://www.ietf.org/archive/id/draft-ietf-opsawg- | ||||
| service-assurance-architecture-03.txt>. | ||||
| [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | ||||
| and A. Bierman, Ed., "Network Configuration Protocol | ||||
| (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | ||||
| <https://www.rfc-editor.org/info/rfc6241>. | ||||
| [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure | ||||
| Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, | ||||
| <https://www.rfc-editor.org/info/rfc6242>. | ||||
| [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", | ||||
| RFC 7950, DOI 10.17487/RFC7950, August 2016, | ||||
| <https://www.rfc-editor.org/info/rfc7950>. | ||||
| [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF | ||||
| Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, | ||||
| <https://www.rfc-editor.org/info/rfc8040>. | ||||
| [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration | ||||
| Access Control Model", STD 91, RFC 8341, | ||||
| DOI 10.17487/RFC8341, March 2018, | ||||
| <https://www.rfc-editor.org/info/rfc8341>. | ||||
| [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., | ||||
| and R. Wilton, "Network Management Datastore Architecture | ||||
| (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, | ||||
| <https://www.rfc-editor.org/info/rfc8342>. | ||||
| [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | ||||
| Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | ||||
| <https://www.rfc-editor.org/info/rfc8446>. | ||||
| 9.2. Informative References | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | ||||
| Requirement Levels", BCP 14, RFC 2119, | ||||
| DOI 10.17487/RFC2119, March 1997, | ||||
| <https://www.rfc-editor.org/info/rfc2119>. | ||||
| [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | ||||
| DOI 10.17487/RFC3688, January 2004, | ||||
| <https://www.rfc-editor.org/info/rfc3688>. | ||||
| [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module | ||||
| Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, | ||||
| <https://www.rfc-editor.org/info/rfc7895>. | ||||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
| [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", | ||||
| BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, | ||||
| <https://www.rfc-editor.org/info/rfc8340>. | ||||
| Appendix A. Vendor-specific Subservice Extension: example-service- | ||||
| assurance-device-acme YANG module | ||||
| A.1. Tree View | ||||
| The following tree diagram [RFC8340] provides an overview of the | The following tree diagram [RFC8340] provides an overview of the | |||
| example-service-assurance-device-acme data model. | example-service-assurance-device-acme data model. | |||
| module: example-service-assurance-device-acme | module: example-service-assurance-device-acme | |||
| augment /sain:subservices/sain:subservice/sain:parameter: | augment /sain:subservices/sain:subservice/sain:parameter: | |||
| +--rw parameters | +--rw parameters | |||
| +--rw device string | +--rw device string | |||
| +--rw acme-specific-parameter string | +--rw acme-specific-parameter string | |||
| 6.2. Complete Tree View | A.2. Complete Tree View | |||
| The following tree diagram [RFC8340] provides an overview of the | The following tree diagram [RFC8340] provides an overview of the | |||
| ietf-service-assurance, ietf-service-assurance-device, and example- | ietf-service-assurance, ietf-service-assurance-device, and example- | |||
| service-assurance-device-acme data models. | service-assurance-device-acme data models. | |||
| module: ietf-service-assurance | module: ietf-service-assurance | |||
| +--ro assurance-graph-version yang:counter64 | +--ro assurance-graph-version yang:counter64 | |||
| +--ro assurance-graph-last-change yang:date-and-time | +--ro assurance-graph-last-change yang:date-and-time | |||
| +--rw subservices | +--rw subservices | |||
| +--rw subservice* [type id] | +--rw subservice* [type id] | |||
| skipping to change at page 25, line 5 ¶ | skipping to change at page 28, line 5 ¶ | |||
| | +--ro description? string | | +--ro description? string | |||
| | +--ro start-date-time yang:date-and-time | | +--ro start-date-time yang:date-and-time | |||
| | +--ro stop-date-time? yang:date-and-time | | +--ro stop-date-time? yang:date-and-time | |||
| +--rw dependencies | +--rw dependencies | |||
| +--rw dependency* [type id] | +--rw dependency* [type id] | |||
| +--rw type | +--rw type | |||
| | -> /subservices/subservice/type | | -> /subservices/subservice/type | |||
| +--rw id leafref | +--rw id leafref | |||
| +--rw dependency-type? identityref | +--rw dependency-type? identityref | |||
| 6.3. Concepts | A.3. Concepts | |||
| Under some circumstances, vendor-specific subservice types might be | Under some circumstances, vendor-specific subservice types might be | |||
| required. As an example of this vendor-specific implementation, this | required. As an example of this vendor-specific implementation, this | |||
| section shows how to augment the ietf-service-assurance-device module | section shows how to augment the ietf-service-assurance-device module | |||
| to add support for the subservice DeviceHealthy, specific to the ACME | to add custom support for the device subservice, specific to the ACME | |||
| Corporation. The new parameter is acme-specific-parameter. | Corporation. The specific version adds a new parameter, named acme- | |||
| specific-parameter. | ||||
| 6.4. YANG Module | A.4. YANG Module | |||
| module example-service-assurance-device-acme { | module example-service-assurance-device-acme { | |||
| yang-version 1.1; | yang-version 1.1; | |||
| namespace "urn:example:example-service-assurance-device-acme"; | namespace "urn:example:example-service-assurance-device-acme"; | |||
| prefix example-device-acme; | prefix example-device-acme; | |||
| import ietf-service-assurance { | import ietf-service-assurance { | |||
| prefix sain; | prefix sain; | |||
| reference | reference | |||
| "RFC xxxx: YANG Modules for Service Assurance"; | "RFC xxxx: YANG Modules for Service Assurance"; | |||
| } | } | |||
| import ietf-service-assurance-device { | import ietf-service-assurance-device { | |||
| prefix sain-device; | prefix sain-device; | |||
| reference | reference | |||
| "RFC xxxx: YANG Modules for Service Assurance"; | "RFC xxxx: YANG Modules for Service Assurance"; | |||
| } | } | |||
| organization | organization | |||
| "IETF OPSAWG Working Group"; | "IETF OPSAWG Working Group"; | |||
| contact | contact | |||
| "WG Web: <https://datatracker.ietf.org/wg/opsawg/> | "WG Web: <https://datatracker.ietf.org/wg/opsawg/> | |||
| WG List: <mailto:opsawg@ietf.org> | WG List: <mailto:opsawg@ietf.org> | |||
| Author: Benoit Claise <mailto:benoit.claise@huawei.com> | Author: Benoit Claise <mailto:benoit.claise@huawei.com> | |||
| Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>"; | Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>"; | |||
| description | description | |||
| "This module extends the ietf-service-assurance-device module to | "This module extends the ietf-service-assurance-device module to | |||
| add support for the subservice DeviceHealthy, specific to the ACME | add specific support for devices of ACME Corporation. | |||
| Corporation. | ||||
| ACME Network Device is healthy. | ACME Network Device is healthy. | |||
| The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', | The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', | |||
| 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', | 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', | |||
| 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document | 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document | |||
| are to be interpreted as described in BCP 14 (RFC 2119) | are to be interpreted as described in BCP 14 (RFC 2119) | |||
| (RFC 8174) when, and only when, they appear in all | (RFC 8174) when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| Copyright (c) 2022 IETF Trust and the persons identified as | Copyright (c) 2022 IETF Trust and the persons identified as | |||
| authors of the code. All rights reserved. | authors of the code. All rights reserved. | |||
| Redistribution and use in source and binary forms, with or | Redistribution and use in source and binary forms, with or | |||
| without modification, is permitted pursuant to, and subject | without modification, is permitted pursuant to, and subject | |||
| to the license terms contained in, the Revised BSD License | to the license terms contained in, the Revised BSD License | |||
| set forth in Section 4.c of the IETF Trust's Legal Provisions | set forth in Section 4.c of the IETF Trust's Legal Provisions | |||
| Relating to IETF Documents | Relating to IETF Documents | |||
| (https://trustee.ietf.org/license-info). | (https://trustee.ietf.org/license-info). | |||
| This version of this YANG module is part of RFC XXXX; see the | This version of this YANG module is part of RFC XXXX; see the | |||
| RFC itself for full legal notices. "; | RFC itself for full legal notices. "; | |||
| revision 2022-04-07 { | revision 2022-04-07 { | |||
| description | description | |||
| "Fix mandatory in augment error by moving when clause. | "Fix mandatory in augment error by moving when clause. | |||
| Shorten prefix. | Shorten prefix. | |||
| Fix module description"; | Fix module description"; | |||
| reference | reference | |||
| "RFC xxxx: YANG Modules for Service Assurance"; | "RFC xxxx: YANG Modules for Service Assurance"; | |||
| } | } | |||
| revision 2021-06-28 { | revision 2021-06-28 { | |||
| description | description | |||
| "Renamed the parameters container."; | "Renamed the parameters container."; | |||
| reference | reference | |||
| "RFC xxxx: YANG Modules for Service Assurance"; | "RFC xxxx: YANG Modules for Service Assurance"; | |||
| } | } | |||
| revision 2020-01-13 { | revision 2020-01-13 { | |||
| description | description | |||
| "Added the maintenance window concept."; | "Added the maintenance window concept."; | |||
| reference | reference | |||
| "RFC xxxx: YANG Modules for Service Assurance"; | "RFC xxxx: YANG Modules for Service Assurance"; | |||
| } | } | |||
| revision 2019-11-16 { | revision 2019-11-16 { | |||
| description | description | |||
| "Initial revision."; | "Initial revision."; | |||
| reference | reference | |||
| "RFC xxxx: YANG Modules for Service Assurance"; | "RFC xxxx: YANG Modules for Service Assurance"; | |||
| } | } | |||
| identity device-acme-idty { | identity device-acme-idty { | |||
| base sain-device:device-idty; | base sain-device:device-idty; | |||
| description | description | |||
| "Network Device is healthy."; | "Network Device is healthy."; | |||
| } | } | |||
| augment "/sain:subservices/sain:subservice/sain:parameter" { | augment "/sain:subservices/sain:subservice/sain:parameter" { | |||
| when "derived-from-or-self(sain:type, 'device-acme-idty')"; | when "derived-from-or-self(sain:type, 'device-acme-idty')"; | |||
| description | ||||
| "Specify the required parameters for a new subservice type"; | ||||
| container parameters { | ||||
| description | description | |||
| "Specify the required parameters for the device-acme-idty | "Specify the required parameters for a new subservice type"; | |||
| subservice type"; | container parameters { | |||
| leaf device { | ||||
| type string; | ||||
| mandatory true; | ||||
| description | ||||
| "The device to monitor."; | ||||
| } | ||||
| leaf acme-specific-parameter { | ||||
| type string; | ||||
| mandatory true; | ||||
| description | description | |||
| "The ACME Corporation sepcific parameter."; | "Specify the required parameters for the device-acme-idty | |||
| subservice type"; | ||||
| leaf device { | ||||
| type string; | ||||
| mandatory true; | ||||
| description | ||||
| "The device to monitor."; | ||||
| } | ||||
| leaf acme-specific-parameter { | ||||
| type string; | ||||
| mandatory true; | ||||
| description | ||||
| "The ACME Corporation sepcific parameter."; | ||||
| } | ||||
| } | } | |||
| } | } | |||
| } | } | |||
| } | ||||
| 7. Further Extensions: IP Connectivity and IS-IS subservices | Appendix B. Further Extensions: IP Connectivity and IS-IS subservices | |||
| In this section, we provide two additional YANG models to completely | In this section, we provide two additional YANG models to completely | |||
| cover the example from Figure 2 in | cover the example from Figure 2 in | |||
| [I-D.ietf-opsawg-service-assurance-architecture]. The complete | [I-D.ietf-opsawg-service-assurance-architecture]. The complete | |||
| normalization of these modules is to be done in future work. | normalization of these modules is to be done in future work. | |||
| 7.1. IP Connectivity Tree View | B.1. IP Connectivity Tree View | |||
| That subservice represents the unicast connectivity between two IP | That subservice represents the unicast connectivity between two IP | |||
| addresses located on to different devices. Such a subservice could | addresses located on to different devices. Such a subservice could | |||
| report symptoms such as "No route found". The following tree diagram | report symptoms such as "No route found". The following tree diagram | |||
| [RFC8340] provides an overview of the example-service-assurance-ip- | [RFC8340] provides an overview of the example-service-assurance-ip- | |||
| connectivity data model. | connectivity data model. | |||
| module: example-service-assurance-ip-connectivity | module: example-service-assurance-ip-connectivity | |||
| augment /sain:subservices/sain:subservice/sain:parameter: | augment /sain:subservices/sain:subservice/sain:parameter: | |||
| skipping to change at page 28, line 10 ¶ | skipping to change at page 31, line 10 ¶ | |||
| +--rw device1 string | +--rw device1 string | |||
| +--rw address1 inet:ip-address | +--rw address1 inet:ip-address | |||
| +--rw device2 string | +--rw device2 string | |||
| +--rw address2 inet:ip-address | +--rw address2 inet:ip-address | |||
| To specify the connectivity that we are interested in, we specify two | To specify the connectivity that we are interested in, we specify two | |||
| IP addresses and two devices. The subservice assures that the | IP addresses and two devices. The subservice assures that the | |||
| connectivity between IP address 1 on device 1 and IP address 2 on | connectivity between IP address 1 on device 1 and IP address 2 on | |||
| device 2 is healthy. | device 2 is healthy. | |||
| 7.2. IS-IS Tree View | B.2. IS-IS Tree View | |||
| The following tree diagram [RFC8340] provides an overview of the | The following tree diagram [RFC8340] provides an overview of the | |||
| example-service-assurance-is-is data model. | example-service-assurance-is-is data model. | |||
| module: example-service-assurance-is-is | module: example-service-assurance-is-is | |||
| augment /sain:subservices/sain:subservice/sain:parameter: | augment /sain:subservices/sain:subservice/sain:parameter: | |||
| +--rw parameters | +--rw parameters | |||
| +--rw instance-name string | +--rw instance-name string | |||
| The parameter of this subservice is the name of the IS-IS instance to | The parameter of this subservice is the name of the IS-IS instance to | |||
| assure. | assure. | |||
| 7.3. Global Tree View | B.3. Global Tree View | |||
| The following tree diagram [RFC8340] provides an overview of the | The following tree diagram [RFC8340] provides an overview of the | |||
| ietf-service-assurance, ietf-service-assurance-device, example- | ietf-service-assurance, ietf-service-assurance-device, example- | |||
| service-assurance-device-acme, example-service-assurance-ip- | service-assurance-device-acme, example-service-assurance-ip- | |||
| connectivity and example-service-assurance-is-is data models. | connectivity and example-service-assurance-is-is data models. | |||
| module: ietf-service-assurance | module: ietf-service-assurance | |||
| +--ro assurance-graph-version yang:counter64 | +--ro assurance-graph-version yang:counter64 | |||
| +--ro assurance-graph-last-change yang:date-and-time | +--ro assurance-graph-last-change yang:date-and-time | |||
| +--rw subservices | +--rw subservices | |||
| skipping to change at page 29, line 41 ¶ | skipping to change at page 32, line 41 ¶ | |||
| | +--ro description? string | | +--ro description? string | |||
| | +--ro start-date-time yang:date-and-time | | +--ro start-date-time yang:date-and-time | |||
| | +--ro stop-date-time? yang:date-and-time | | +--ro stop-date-time? yang:date-and-time | |||
| +--rw dependencies | +--rw dependencies | |||
| +--rw dependency* [type id] | +--rw dependency* [type id] | |||
| +--rw type | +--rw type | |||
| | -> /subservices/subservice/type | | -> /subservices/subservice/type | |||
| +--rw id leafref | +--rw id leafref | |||
| +--rw dependency-type? identityref | +--rw dependency-type? identityref | |||
| 7.4. IP Connectivity YANG Module | B.4. IP Connectivity YANG Module | |||
| module example-service-assurance-ip-connectivity { | module example-service-assurance-ip-connectivity { | |||
| yang-version 1.1; | yang-version 1.1; | |||
| namespace "urn:example:example-service-assurance-ip-connectivity"; | namespace "urn:example:example-service-assurance-ip-connectivity"; | |||
| prefix example-ip-connectivity; | prefix example-ip-connectivity; | |||
| import ietf-inet-types { | import ietf-inet-types { | |||
| prefix inet; | prefix inet; | |||
| reference | reference | |||
| "RFC 6991: Common YANG Data Types"; | "RFC 6991: Common YANG Data Types"; | |||
| skipping to change at page 32, line 8 ¶ | skipping to change at page 35, line 8 ¶ | |||
| type inet:ip-address; | type inet:ip-address; | |||
| mandatory true; | mandatory true; | |||
| description | description | |||
| "Address at the second end of the connection."; | "Address at the second end of the connection."; | |||
| } | } | |||
| } | } | |||
| } | } | |||
| } | } | |||
| 7.5. IS-IS YANG Module | B.5. IS-IS YANG Module | |||
| module example-service-assurance-is-is { | module example-service-assurance-is-is { | |||
| yang-version 1.1; | yang-version 1.1; | |||
| namespace "urn:example:example-service-assurance-is-is"; | namespace "urn:example:example-service-assurance-is-is"; | |||
| prefix example-is-is; | prefix example-is-is; | |||
| import ietf-service-assurance { | import ietf-service-assurance { | |||
| prefix sain; | prefix sain; | |||
| reference | reference | |||
| "RFC xxxx: YANG Modules for Service Assurance"; | "RFC xxxx: YANG Modules for Service Assurance"; | |||
| skipping to change at page 33, line 45 ¶ | skipping to change at page 37, line 5 ¶ | |||
| leaf instance-name { | leaf instance-name { | |||
| type string; | type string; | |||
| mandatory true; | mandatory true; | |||
| description | description | |||
| "The instance to monitor."; | "The instance to monitor."; | |||
| } | } | |||
| } | } | |||
| } | } | |||
| } | } | |||
| 8. Guidelines for Specific Subservice Extension | Appendix C. Example of YANG instances | |||
| The base YANG module defined in Section 3.3 only defines a single | ||||
| type of subservices that represent service instances. As explained | ||||
| above, this model is meant to be augmented so that a variety of | ||||
| subservices can be used in the assurance graph. In this section, we | ||||
| propose some guidelines in order to build theses extensions. | ||||
| First, the specific subservice must be given an adequate unique short | ||||
| name that will be used to form longer names (e.g. module name, prefix | ||||
| ...) appearing in the YANG module. The short name identifies the | ||||
| type of subpart of feature that the subservice will represent, for | ||||
| instance if the subservice will assure the health of a network | ||||
| interface then "interface" is an adequate short name. If the | ||||
| subservice will assure the IS-IS routing protocol, then "is-is" is an | ||||
| adequate short name. The short name must be in kebab-case. | ||||
| In this section, by subservice YANG module, we mean "YANG module that | ||||
| extends ietf-service-assurance in order to define a specific | ||||
| subservice". | ||||
| 8.1. Module Name | ||||
| For subservice YANG modules vetted by the IETF, the module name | ||||
| should be "ietf-service-assurance-" followed by the short name. For | ||||
| instance, "ietf-service-assurance-interface" or "ietf-service- | ||||
| assurance-is-is". | ||||
| For subservice YANG module that are directly provided by vendors, we | ||||
| propose that they use the company in the prefix. For example, the | ||||
| prefix for the company "acme" would be "acme-assurance-" and the YANG | ||||
| modules would be "acme-assurance-interface", "acme-assurance-is-is", | ||||
| etc. | ||||
| 8.2. Module Namespace | ||||
| For subservice YANG modules vetted by the IETF, the module namespace | ||||
| should be "urn:ietf:params:xml:ns:yang:ietf-service-assurance-" | ||||
| followed by the short name. For instance, | ||||
| "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface" or | ||||
| "urn:ietf:params:xml:ns:yang:example-service-assurance-is-is". | ||||
| For subservice YANG module that are directly provided by vendors, a | ||||
| similar pattern can be used with the prefix being a namespace | ||||
| controlled by the vendor. | ||||
| 8.3. Module Prefix | ||||
| For subservice YANG modules vetted by the IETF, the module prefix | ||||
| should be "sain-" followed by the short name. For instance, "sain- | ||||
| interface" or "sain-is-is". | ||||
| For subservice YANG module that are directly provided by vendors, the | ||||
| same pattern can be used provided it does not conflict with an | ||||
| imported prefix. | ||||
| 8.4. Subservice Specific Identity | ||||
| Each augment specific to a subservice must define an identity | ||||
| representing the type of subpart or features of the network system | ||||
| that are assured by the subservice. As required in the "ietf- | ||||
| service-assurance" module (see Section 3.3), that identity must be | ||||
| based on the "subservice-idty" identity. | ||||
| For subservice YANG modules vetted by the IETF, the subservice | ||||
| specific identity should be the short name of the subservice followed | ||||
| by "-idty". For instance, "interface-idty" or "is-is-identity". | ||||
| For subservice YANG module that are directly provided by vendors, the | ||||
| same pattern can be used. | ||||
| 8.5. Parameters | ||||
| For subservice YANG modules vetted by the IETF, the parameters | ||||
| specific to the subservice should be placed in a container named | ||||
| "parameters". That container must be used to augment the "parameter" | ||||
| choice from the module "ietf-service-assurance" (see Section 3.3 and | ||||
| that augment must be guarded so that it is effective only for | ||||
| subservice instance whose type is the subservice specific identity | ||||
| from Section 8.4. | ||||
| For subservice YANG module that are directly provided by vendors, the | ||||
| same pattern can be used. | ||||
| 9. Security Considerations | ||||
| The YANG module specified in this document defines a schema for data | ||||
| that is designed to be accessed via network management protocols such | ||||
| as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer | ||||
| is the secure transport layer, and the mandatory-to-implement secure | ||||
| transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer | ||||
| is HTTPS, and the mandatory-to-implement secure transport is TLS | ||||
| [RFC8446]. | ||||
| The Network Configuration Access Control Model (NACM) [RFC8341] | ||||
| provides the means to restrict access for particular NETCONF or | ||||
| RESTCONF users to a preconfigured subset of all available NETCONF or | ||||
| RESTCONF protocol operations and content. | ||||
| There are a number of data nodes defined in this YANG module that are | ||||
| writable/ creatable/deletable (i.e., config true, which is the | ||||
| default). These data nodes may be considered sensitive or vulnerable | ||||
| in some network environments. Write operations (e.g., edit-config) | ||||
| to these data nodes without proper protection can have a negative | ||||
| effect on network operations. These are the subtrees and data nodes | ||||
| and their sensitivity/vulnerability: | ||||
| * /subservices/subservice/type | ||||
| * /subservices/subservice/id | ||||
| * /subservices/subservice/under-maintenance | ||||
| * /subservices/subservice/maintenance-contact | ||||
| 10. IANA Considerations | ||||
| 10.1. The IETF XML Registry | ||||
| This document registers two URIs in the IETF XML registry [RFC3688]. | ||||
| Following the format in [RFC3688], the following registrations are | ||||
| requested: | ||||
| URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance | ||||
| Registrant Contact: The NETCONF WG of the IETF. | ||||
| XML: N/A, the requested URI is an XML namespace. | ||||
| URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device | ||||
| Registrant Contact: The NETCONF WG of the IETF. | ||||
| XML: N/A, the requested URI is an XML namespace. | ||||
| URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface | ||||
| Registrant Contact: The NETCONF WG of the IETF. | ||||
| XML: N/A, the requested URI is an XML namespace. | ||||
| 10.2. The YANG Module Names Registry | ||||
| This document registers three YANG modules in the YANG Module Names | ||||
| registry [RFC7950]. Following the format in [RFC7950], the the | ||||
| following registrations are requested: | ||||
| name: ietf-service-assurance | ||||
| namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance | ||||
| prefix: inc | ||||
| reference: RFC XXXX | ||||
| name: ietf-service-assurance-device | ||||
| namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device | ||||
| prefix: inc | ||||
| reference: RFC XXXX | ||||
| name: ietf-service-assurance-interface | ||||
| namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface | ||||
| prefix: inc | ||||
| reference: RFC XXXX | ||||
| 11. Open Issues | ||||
| -None | ||||
| 12. References | ||||
| 12.1. Normative References | ||||
| [I-D.ietf-opsawg-service-assurance-architecture] | ||||
| Claise, B.C., Quilbeuf, J.Q., Lopez, D.L., Voyer, D.V., | ||||
| and T.A. Arumugam, "draft-claise-opsawg-service-assurance- | ||||
| architecture", 2020. | ||||
| [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | ||||
| and A. Bierman, Ed., "Network Configuration Protocol | ||||
| (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | ||||
| <https://www.rfc-editor.org/info/rfc6241>. | ||||
| [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure | ||||
| Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, | ||||
| <https://www.rfc-editor.org/info/rfc6242>. | ||||
| [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", | ||||
| RFC 7950, DOI 10.17487/RFC7950, August 2016, | ||||
| <https://www.rfc-editor.org/info/rfc7950>. | ||||
| [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF | ||||
| Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, | ||||
| <https://www.rfc-editor.org/info/rfc8040>. | ||||
| [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration | ||||
| Access Control Model", STD 91, RFC 8341, | ||||
| DOI 10.17487/RFC8341, March 2018, | ||||
| <https://www.rfc-editor.org/info/rfc8341>. | ||||
| [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., | ||||
| and R. Wilton, "Network Management Datastore Architecture | ||||
| (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, | ||||
| <https://www.rfc-editor.org/info/rfc8342>. | ||||
| [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | ||||
| Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | ||||
| <https://www.rfc-editor.org/info/rfc8446>. | ||||
| 12.2. Informative References | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | ||||
| Requirement Levels", BCP 14, RFC 2119, | ||||
| DOI 10.17487/RFC2119, March 1997, | ||||
| <https://www.rfc-editor.org/info/rfc2119>. | ||||
| [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | ||||
| DOI 10.17487/RFC3688, January 2004, | ||||
| <https://www.rfc-editor.org/info/rfc3688>. | ||||
| [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module | ||||
| Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, | ||||
| <https://www.rfc-editor.org/info/rfc7895>. | ||||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
| [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", | ||||
| BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, | ||||
| <https://www.rfc-editor.org/info/rfc8340>. | ||||
| Appendix A. Example of YANG instances | ||||
| This section contains examples of YANG instances that conform to the | This section contains examples of YANG instances that conform to the | |||
| YANG modules. The validity of these data instances has been checked | YANG modules. The validity of these data instances has been checked | |||
| using yangson (https://yangson.labs.nic.cz/). Yangson requires a | using yangson (https://yangson.labs.nic.cz/). Yangson requires a | |||
| YANG library [RFC7895] to define the complete model against which the | YANG library [RFC7895] to define the complete model against which the | |||
| data instance must be validated. We provide in Appendix B the JSON | data instance must be validated. We provide in Appendix D the JSON | |||
| library file, named "ietf-service-assurance-library.json", that we | library file, named "ietf-service-assurance-library.json", that we | |||
| used for validation. | used for validation. | |||
| We provide below the contents of the file | We provide below the contents of the file | |||
| "example_configuration_instance.json" which contains the | "example_configuration_instance.json" which contains the | |||
| configuration data that models the Figure 2 of | configuration data that models the Figure 2 of | |||
| [I-D.ietf-opsawg-service-assurance-architecture]. The instance can | [I-D.ietf-opsawg-service-assurance-architecture]. The instance can | |||
| be validated with yangson by using the invocation "yangson -v | be validated with yangson by using the invocation "yangson -v | |||
| example_configuration_instance.json ietf-service-assurance- | example_configuration_instance.json ietf-service-assurance- | |||
| library.json", assuming all the files (YANG and JSON) defined in this | library.json", assuming all the files (YANG and JSON) defined in this | |||
| skipping to change at page 42, line 23 ¶ | skipping to change at page 40, line 34 ¶ | |||
| "type": "ietf-service-assurance-device:device-idty", | "type": "ietf-service-assurance-device:device-idty", | |||
| "id": "interface/peer2", | "id": "interface/peer2", | |||
| "ietf-service-assurance-device:parameters": { | "ietf-service-assurance-device:parameters": { | |||
| "device": "Peer2" | "device": "Peer2" | |||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| Appendix B. YANG Library for Service Assurance | Appendix D. YANG Library for Service Assurance | |||
| This section provides the JSON encoding of the YANG library [RFC7895] | This section provides the JSON encoding of the YANG library [RFC7895] | |||
| listing all modules defined in this draft and their dependencies. | listing all modules defined in this draft and their dependencies. | |||
| This library can be used to validate data instances using yangson, as | This library can be used to validate data instances using yangson, as | |||
| explained in the previous section. | explained in the previous section. | |||
| { | { | |||
| "ietf-yang-library:modules-state": { | "ietf-yang-library:modules-state": { | |||
| "module-set-id": "ietf-service-assurance@2022-04-07", | "module-set-id": "ietf-service-assurance@2022-04-07", | |||
| "module": [ | "module": [ | |||
| skipping to change at page 43, line 42 ¶ | skipping to change at page 42, line 4 ¶ | |||
| "revision": "2021-04-14", | "revision": "2021-04-14", | |||
| "conformance-type": "import" | "conformance-type": "import" | |||
| }, | }, | |||
| { | { | |||
| "name": "ietf-inet-types", | "name": "ietf-inet-types", | |||
| "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types", | "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types", | |||
| "revision": "2021-02-22", | "revision": "2021-02-22", | |||
| "conformance-type": "import" | "conformance-type": "import" | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| Appendix C. Changes between revisions | Appendix E. Changes between revisions | |||
| v04 - v05 | ||||
| * Remove Guidelines section | ||||
| * Move informative parts (examples) to appendix | ||||
| * Minor text edits and reformulations | ||||
| v03 - v04 | v03 - v04 | |||
| * Fix YANG errors | * Fix YANG errors | |||
| * Change is-is and ip-connectivity subservices from ietf to example. | * Change is-is and ip-connectivity subservices from ietf to example. | |||
| * Mention that models are NMDA compliant | * Mention that models are NMDA compliant | |||
| * Fix typos, reformulate for clarity | * Fix typos, reformulate for clarity | |||
| v02 - v03 | v02 - v03 | |||
| * Change counter32 to counter64 to avoid resetting too frequently | * Change counter32 to counter64 to avoid resetting too frequently | |||
| End of changes. 53 change blocks. | ||||
| 422 lines changed or deleted | 341 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||