[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]



Internet Engineering Task Force                              B. Yan, Ed.
Internet-Draft                                                Z. Li, Ed.
Intended status: Informational                              Y. Zhao, Ed.
Expires: November 15, 2020           Beijing Univ. of Posts and Telecom.
                                                            May 14, 2020


                 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




Yan, et al.             Expires November 15, 2020               [Page 1]


Internet-Draft              Abbreviated Title                   May 2020


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

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

1.  Introduction

   The Yang standards with version 1.0 RFC 6020 [RFC6020] and version
   1.1 RFC 7950 [RFC7950] define a domain- specific language for network
   data modeling.  By using Yang models, several network management
   protocols like NETCONF [RFC6241] and RESTCONF [RFC8040] 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.




Yan, et al.             Expires November 15, 2020               [Page 2]


Internet-Draft              Abbreviated Title                   May 2020


   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:

   o  A vendor is required to provide different models for different
      customers (telecom operators, cloud computing companies, etc.) on
      the same equipment.

   o  A network operator needs to map all network models defined by all
      network equipment into its own complete network model.

   o  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 [RFC2119].

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.



Yan, et al.             Expires November 15, 2020               [Page 3]


Internet-Draft              Abbreviated Title                   May 2020


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.








Yan, et al.             Expires November 15, 2020               [Page 4]


Internet-Draft              Abbreviated Title                   May 2020


                 +-------------------------------+
                 |       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

























Yan, et al.             Expires November 15, 2020               [Page 5]


Internet-Draft              Abbreviated Title                   May 2020


              +---------------------------------+
              |          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

   [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>.



Yan, et al.             Expires November 15, 2020               [Page 6]


Internet-Draft              Abbreviated Title                   May 2020


   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [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>.

9.2.  Informative References

   [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>.

   [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>.

Appendix A.  Additional Stuff

   This becomes an Appendix.

Authors' Addresses

   Boyuan Yan (editor)
   Beijing Univ. of Posts and Telecom.
   No. 10 Xitucheng Rd.
   Beijing, Haidian Dist.
   CN

   Phone: +86 188 1052 8290
   Email: yanboyuan@bupt.edu.cn


   Zhuotong Li (editor)
   Beijing Univ. of Posts and Telecom.
   No. 10 Xitucheng Rd.
   Beijing, Haidian Dist.
   CN

   Email: lizhuotong@bupt.edu.cn








Yan, et al.             Expires November 15, 2020               [Page 7]


Internet-Draft              Abbreviated Title                   May 2020


   Yongli Zhao (editor)
   Beijing Univ. of Posts and Telecom.
   No. 10 Xitucheng Rd.
   Beijing, Haidian Dist.
   CN

   Email: yonglizhao@bupt.edu.cn












































Yan, et al.             Expires November 15, 2020               [Page 8]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/