The use cases of yang model conversion
draft-yby-netmod-usecase-of-ymc-00

Abstract

This document contains the brief description and the guidelines for the usage of Yang model conversion (YMC). It demonstrates the benefits of YMC for both communication vendors and network operators, provides several use cases to show the proper operations, and provides the recommendations for the development.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on November 15, 2020.

Copyright Notice

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Keywords
• 3. The usage limitation of Yang model conversion
• 4. Use cases for Yang model conversion
• 4.1. Use case for vendors
• 4.2. Use case for operators
• 4.3. Use case for multiple Yang model organizations
• 5. Considerations by using YMC
• 6. Acknowledgements
• 7. IANA Considerations
• 8. Security Considerations
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Appendix A. Additional Stuff
• Authors' Addresses

1. Introduction

The Yang standards with version 1.0 RFC 6020 and version 1.1 RFC 7950 define a domain- specific language for network data modeling. By using Yang models, several network management protocols like NETCONF and RESTCONF are proposed. These protocols are deployed widely in network management systems (including network controllers in SDN). The Yang-model-driven systems generally generate codes from yang models by using Yang compiler, and executes network operations on these model data. A lot of Yang models are defined for the networks in different layers. The combination of multiple Yang models form a complete network model under specific scenarios.

A Yang model is composed of different statements. According to the descriptions in Yang standards, these statements could be divided into module statement, submodule statement, typedef statement, container statement, leaf-list statement, list statement, choice statement, etc. In order to manage the updates for Yang models in the equipment development, Yang standard introduces revision statement and augment statement to indicate the version and extension for a Yang model. However, these statements could only handle the model management in an incremental updating way, but couldn't handle the mapping problem between two similar Yang models. And with the widespread adoption of Yang, such a mapping problem occurs.

Until now, many Yang models have been defined by different organizations, vendors, network operators, and foundations. These existed Yang models are deployed in different scenarios. However, these models don't coordinate with each other very well. For a certain part, the authors usually define duplicated and conflicted models to make this part meet their own requirements. And once the data conversion from one model to another is required, there is no such a solution defined. In order to address this problem, Yang model conversion is introduced. In reality, such a model conversion happens when:

• A vendor is required to provide different models for different customers (telecom operators, cloud computing companies, etc.) on the same equipment.
• A network operator needs to map all network models defined by all network equipment into its own complete network model.
• An organization needs to map its own models into the models defined by another organization.

The conversion between two Yang models enables the concrete definition of model difference. In all conversion use cases, such a definition enhances the conversion robustness. Besides, it also make all gap between models evaluable.

2. Keywords

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

3. The usage limitation of Yang model conversion

The model conversion MAY introduce information loss or information deviation while mapping the data from one model to another. Therefore, the conversion could not be applied when the gap between two models are non-negligible. Usually, only the mapping between two models that define the same equipment component MAY succeeds. Yang model conversion is not recommended if the mapping problem could be solved by simple augmentation, or other solutions without information loss or information deviation.

In database, there MAY be only one model stored, and other model data are generated by Yang model conversion timely. Some nodes defined in schema tree MAY be skipped after model conversion. If the rpc service or notification service include these skipped nodes, these services are not available.

4. Use cases for Yang model conversion

Yang model conversion is useful for all users. The following use cases show how to use it:

4.1. Use case for vendors

Matching between vendor's private model and operator's models.

     +-------------------------------------+
     |       Communication Equipment       |
     |                                     |
     |       +---------------------+       |
     |       | internal YANG model |       |
     |       +---------------------+       |
     |               /\                    |
     |         Sync  ||                    |
     |               \/                    |
     |       +---------------------+       |
     |       |Yang Model Conversion|       |
     |       +---------------------+       |
     |         |        |        |         |
     | +---------+ +---------+ +---------+ |
     | | model A | | model B | | model X | |
     | +---------+ +---------+ +---------+ |
     |    /           |           \        |
     +-------------------------------------+ 
        /             |             \
       /              |              \ 
      /               |         ...   \ 
+------------+  +------------+     +------------+
| Operator A |  | Operator B | ... | Operator X |
+------------+  +------------+     +------------+                  
                

mapping from vendor internal model to multiple operators' models.

Figure 1

4.2. Use case for operators

Matching between operator's private model to vendor's models.

Data migration for the existed huge performance data.

      +-------------------------------+
      |       Network Controller      |
      |                               |
      |     +---------------------+   |
      |     | internal YANG model |   |
      |     +---------------------+   |
      |               /\              |
      |         Sync  ||              |
      |               \/              |
      |     +---------------------+   |
      |     |Yang Model Conversion|   |
      |     +---------------------+   | 
      |    /           |           \  |
      +-------------------------------+
        /             |             \
       /              |              \ 
      /               |         ...   \ 
+-------------+  +-------------+     +-------------+
| Equipment A |  | Equipment B | ... | Equipment X |
+-------------+  +-------------+     +-------------+                  
                

mapping from multiple equipment model to one model.

Figure 2

4.3. Use case for multiple Yang model organizations

           +---------------------------------+
           |          organization A         |
       ____|__\ +-----------------------+    |
      |    |  / |        model A1       | /__|__
      |    |    +-----------------------+ \  |  |
      |    |    +-----------------------+    |  |
      |    |    |        model A2       | /__|__|_____________
      |    |    +-----------------------+ \  |  |             |
      |    |     /\                          |  |             |
      |    +-----|---------------------------+  |             |
      |     _____|_________________________     |             |
      |    |     |                         |    |             |
      |    |     |     __________________________________     |
      |    |     |    |                    |    |        |    |
+-----------------------------+       +-----------------------------+
|     |    |     |    |       |       |    |    |        |    |     |
|     \/   \/    \/   \/      |       |    \/   \/       \/   \/    |
|  +----------+ +----------+  |       |  +----------+ +----------+  |
|  | model B1 | | model B2 |  |       |  | model C1 | | model C2 |  |
|  +----------+ +----------+  |       |  +----------+ +----------+  |
|        organization B       |       |        organization C       |
+-----------------------------+       +-----------------------------+
                

mapping from multiple equipment model to one model.

Figure 3

5. Considerations by using YMC

6. Acknowledgements

This document is Supported by BUPT Excellent Ph.D. Students Foundation (CX2019314).

7. IANA Considerations

This memo includes no request to IANA.

8. Security Considerations

9. References

9.1. Normative References

9.2. Informative References

Appendix A. Additional Stuff

This becomes an Appendix.

Authors' Addresses