idnits 2.17.1 draft-yby-netmod-usecase-of-ymc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 14, 2020) is 1444 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force B. Yan, Ed. 3 Internet-Draft Z. Li, Ed. 4 Intended status: Informational Y. Zhao, Ed. 5 Expires: November 15, 2020 Beijing Univ. of Posts and Telecom. 6 May 14, 2020 8 The use cases of yang model conversion 9 draft-yby-netmod-usecase-of-ymc-00 11 Abstract 13 This document contains the brief description and the guidelines for 14 the usage of Yang model conversion (YMC). It demonstrates the 15 benefits of YMC for both communication vendors and network operators, 16 provides several use cases to show the proper operations, and 17 provides the recommendations for the development. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 15, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. The usage limitation of Yang model conversion . . . . . . . . 3 56 4. Use cases for Yang model conversion . . . . . . . . . . . . . 4 57 4.1. Use case for vendors . . . . . . . . . . . . . . . . . . 4 58 4.2. Use case for operators . . . . . . . . . . . . . . . . . 4 59 4.3. Use case for multiple Yang model organizations . . . . . 5 60 5. Considerations by using YMC . . . . . . . . . . . . . . . . . 6 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 9.2. Informative References . . . . . . . . . . . . . . . . . 7 67 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 The Yang standards with version 1.0 RFC 6020 [RFC6020] and version 73 1.1 RFC 7950 [RFC7950] define a domain- specific language for network 74 data modeling. By using Yang models, several network management 75 protocols like NETCONF [RFC6241] and RESTCONF [RFC8040] are proposed. 76 These protocols are deployed widely in network management systems 77 (including network controllers in SDN). The Yang-model-driven 78 systems generally generate codes from yang models by using Yang 79 compiler, and executes network operations on these model data. A lot 80 of Yang models are defined for the networks in different layers. The 81 combination of multiple Yang models form a complete network model 82 under specific scenarios. 84 A Yang model is composed of different statements. According to the 85 descriptions in Yang standards, these statements could be divided 86 into module statement, submodule statement, typedef statement, 87 container statement, leaf-list statement, list statement, choice 88 statement, etc. In order to manage the updates for Yang models in 89 the equipment development, Yang standard introduces revision 90 statement and augment statement to indicate the version and extension 91 for a Yang model. However, these statements could only handle the 92 model management in an incremental updating way, but couldn't handle 93 the mapping problem between two similar Yang models. And with the 94 widespread adoption of Yang, such a mapping problem occurs. 96 Until now, many Yang models have been defined by different 97 organizations, vendors, network operators, and foundations. These 98 existed Yang models are deployed in different scenarios. However, 99 these models don't coordinate with each other very well. For a 100 certain part, the authors usually define duplicated and conflicted 101 models to make this part meet their own requirements. And once the 102 data conversion from one model to another is required, there is no 103 such a solution defined. In order to address this problem, Yang 104 model conversion is introduced. In reality, such a model conversion 105 happens when: 107 o A vendor is required to provide different models for different 108 customers (telecom operators, cloud computing companies, etc.) on 109 the same equipment. 111 o A network operator needs to map all network models defined by all 112 network equipment into its own complete network model. 114 o An organization needs to map its own models into the models 115 defined by another organization. 117 The conversion between two Yang models enables the concrete 118 definition of model difference. In all conversion use cases, such a 119 definition enhances the conversion robustness. Besides, it also make 120 all gap between models evaluable. 122 2. Keywords 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 3. The usage limitation of Yang model conversion 130 The model conversion MAY introduce information loss or information 131 deviation while mapping the data from one model to another. 132 Therefore, the conversion could not be applied when the gap between 133 two models are non-negligible. Usually, only the mapping between two 134 models that define the same equipment component MAY succeeds. Yang 135 model conversion is not recommended if the mapping problem could be 136 solved by simple augmentation, or other solutions without information 137 loss or information deviation. 139 In database, there MAY be only one model stored, and other model data 140 are generated by Yang model conversion timely. Some nodes defined in 141 schema tree MAY be skipped after model conversion. If the rpc 142 service or notification service include these skipped nodes, these 143 services are not available. 145 4. Use cases for Yang model conversion 147 Yang model conversion is useful for all users. The following use 148 cases show how to use it: 150 4.1. Use case for vendors 152 Matching between vendor's private model and operator's models. 154 +-------------------------------------+ 155 | Communication Equipment | 156 | | 157 | +---------------------+ | 158 | | internal YANG model | | 159 | +---------------------+ | 160 | /\ | 161 | Sync || | 162 | \/ | 163 | +---------------------+ | 164 | |Yang Model Conversion| | 165 | +---------------------+ | 166 | | | | | 167 | +---------+ +---------+ +---------+ | 168 | | model A | | model B | | model X | | 169 | +---------+ +---------+ +---------+ | 170 | / | \ | 171 +-------------------------------------+ 172 / | \ 173 / | \ 174 / | ... \ 175 +------------+ +------------+ +------------+ 176 | Operator A | | Operator B | ... | Operator X | 177 +------------+ +------------+ +------------+ 179 mapping from vendor internal model to multiple operators' models. 181 Figure 1 183 4.2. Use case for operators 185 Matching between operator's private model to vendor's models. 187 Data migration for the existed huge performance data. 189 +-------------------------------+ 190 | Network Controller | 191 | | 192 | +---------------------+ | 193 | | internal YANG model | | 194 | +---------------------+ | 195 | /\ | 196 | Sync || | 197 | \/ | 198 | +---------------------+ | 199 | |Yang Model Conversion| | 200 | +---------------------+ | 201 | / | \ | 202 +-------------------------------+ 203 / | \ 204 / | \ 205 / | ... \ 206 +-------------+ +-------------+ +-------------+ 207 | Equipment A | | Equipment B | ... | Equipment X | 208 +-------------+ +-------------+ +-------------+ 210 mapping from multiple equipment model to one model. 212 Figure 2 214 4.3. Use case for multiple Yang model organizations 215 +---------------------------------+ 216 | organization A | 217 ____|__\ +-----------------------+ | 218 | | / | model A1 | /__|__ 219 | | +-----------------------+ \ | | 220 | | +-----------------------+ | | 221 | | | model A2 | /__|__|_____________ 222 | | +-----------------------+ \ | | | 223 | | /\ | | | 224 | +-----|---------------------------+ | | 225 | _____|_________________________ | | 226 | | | | | | 227 | | | __________________________________ | 228 | | | | | | | | 229 +-----------------------------+ +-----------------------------+ 230 | | | | | | | | | | | | 231 | \/ \/ \/ \/ | | \/ \/ \/ \/ | 232 | +----------+ +----------+ | | +----------+ +----------+ | 233 | | model B1 | | model B2 | | | | model C1 | | model C2 | | 234 | +----------+ +----------+ | | +----------+ +----------+ | 235 | organization B | | organization C | 236 +-----------------------------+ +-----------------------------+ 238 mapping from multiple equipment model to one model. 240 Figure 3 242 5. Considerations by using YMC 244 6. Acknowledgements 246 This document is Supported by BUPT Excellent Ph.D. Students 247 Foundation (CX2019314). 249 7. IANA Considerations 251 This memo includes no request to IANA. 253 8. Security Considerations 255 9. References 257 9.1. Normative References 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, 261 DOI 10.17487/RFC2119, March 1997, 262 . 264 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 265 the Network Configuration Protocol (NETCONF)", RFC 6020, 266 DOI 10.17487/RFC6020, October 2010, 267 . 269 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 270 RFC 7950, DOI 10.17487/RFC7950, August 2016, 271 . 273 9.2. Informative References 275 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 276 and A. Bierman, Ed., "Network Configuration Protocol 277 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 278 . 280 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 281 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 282 . 284 Appendix A. Additional Stuff 286 This becomes an Appendix. 288 Authors' Addresses 290 Boyuan Yan (editor) 291 Beijing Univ. of Posts and Telecom. 292 No. 10 Xitucheng Rd. 293 Beijing, Haidian Dist. 294 CN 296 Phone: +86 188 1052 8290 297 Email: yanboyuan@bupt.edu.cn 299 Zhuotong Li (editor) 300 Beijing Univ. of Posts and Telecom. 301 No. 10 Xitucheng Rd. 302 Beijing, Haidian Dist. 303 CN 305 Email: lizhuotong@bupt.edu.cn 306 Yongli Zhao (editor) 307 Beijing Univ. of Posts and Telecom. 308 No. 10 Xitucheng Rd. 309 Beijing, Haidian Dist. 310 CN 312 Email: yonglizhao@bupt.edu.cn