idnits 2.17.1 draft-ietf-netmod-yang-model-classification-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6020]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 4, 2016) is 2942 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-07 == Outdated reference: A later version (-29) exists of draft-ietf-ospf-yang-04 == Outdated reference: A later version (-02) exists of draft-openconfig-netmod-model-catalog-00 -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD D. Bogdanovic 3 Internet-Draft 4 Intended status: Informational B. Claise 5 Expires: October 6, 2016 C. Moberg 6 Cisco Systems, Inc. 7 April 4, 2016 9 YANG Model Classification 10 draft-ietf-netmod-yang-model-classification-01 12 Abstract 14 The YANG [RFC6020] data modeling language is currently being 15 considered for a wide variety of applications throughout the 16 networking industry at large. Many standards-defining organizations 17 (SDOs), open source software projects, vendors and users are using 18 YANG to develop and publish models of configuration, state data and 19 operations for a wide variety of applications. At the same time, 20 there is currently no well-known terminology to categorize various 21 types of YANG models. 23 A consistent terminology would help with the categorization of 24 models, assist in the analysis the YANG data modeling efforts in the 25 IETF and other organizations, and bring clarity to the YANG-related 26 discussions between the different groups. 28 This document describes a set of concepts and associated terms to 29 support consistent classification of YANG models. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on October 6, 2016. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. First Dimension: YANG Model Abstraction Layers . . . . . . . 3 67 2.1. Network Service YANG Data Models . . . . . . . . . . . . 4 68 2.2. Network Element YANG Data models . . . . . . . . . . . . 5 69 3. Second Dimension: Model Types . . . . . . . . . . . . . . . . 6 70 3.1. Standard YANG Models . . . . . . . . . . . . . . . . . . 6 71 3.2. Vendor-specific YANG Models and Extensions . . . . . . . 6 72 3.3. User-specific YANG Models and Extensions . . . . . . . . 7 73 3.4. Adding Models to Catalogs . . . . . . . . . . . . . . . . 7 74 3.5. Security Considerations . . . . . . . . . . . . . . . . . 8 75 3.6. IANA Considerations . . . . . . . . . . . . . . . . . . . 8 76 3.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 8 77 3.8. Change log [RFC Editor: Please remove] . . . . . . . . . 8 78 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 4.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 4.2. Informative References . . . . . . . . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 The Internet Engineering Steering Group (IESG) has been actively 86 encouraging IETF working groups to use the NETCONF [RFC6241] and YANG 87 standards for configuration management purposes, especially in new 88 working group charters [Writable-MIB-Module-IESG-Statement]. 90 YANG is also gaining wide acceptance as the de-facto standard 91 modeling language in the broader industry. This extends beyond the 92 IETF, including many standards development organizations, industry 93 consortia, ad hoc groups, open source projects, vendors, and end- 94 users. 96 There are currently no clear guidelines on how to classify the 97 layering of YANG models according to abstraction, or how to classify 98 models along the continuum spanning formal standards publications, 99 vendor-specific models and models provided by end-users. 101 This document presents a set of concepts and terms to form a useful 102 taxonomy for consistent classification of YANG models in two 103 dimensions: 105 o The layering of models based on their abstraction levels 107 o The type of model based on the nature and intent of the content 109 The two categories are covered in the next two sections. 111 2. First Dimension: YANG Model Abstraction Layers 113 Model developers have taken two approaches to developing YANG models: 114 top-down and bottom-up. The top-down approach starts with high level 115 abstractions modeling business or customer requirements and maps them 116 to specific networking technologies. The bottom-up approach starts 117 with fundamental networking technologies and maps them into more 118 abstract constructs. 120 There are currently no specific requirements on, or well-defined best 121 practices around the development of models. For the purpose of this 122 document we assume that both approaches (bottom-up and top-down) will 123 be used as they both provide benefits that appeal to different 124 groups. 126 For layering purposes, this document suggests the classification of 127 data models into two distinct abstraction layers: 129 o Network Element YANG Models describe the configuration, state data 130 and operations of specific device-centric technologies or features 132 o Network Service YANG Models describe the configuration, state data 133 and operations of an abstract representation of a service 134 implemented on one or multiple network elements 136 Figure 1 illustrates the application of YANG models at different 137 layers of abstraction. Layering of models allows for reusability of 138 existing lower layer models by higher level models while limiting 139 duplication of features across layers. 141 For model developers, per-layer modeling allows for separation of 142 concern across editing teams focusing on specific areas. 144 As an example, experience from the IETF shows that creating useful 145 network element YANG models for e.g. routing or switching protocols 146 requires teams that include developers with experience of 147 implementing those protocols. 149 On the other hand, network service models are best developed by 150 people experienced in defining network services for consumption by 151 programmers developing e.g. flow-through provisioning systems or 152 self-service portals. 154 +--------------------------+ 155 | Operations and Business | 156 | Support Systems | 157 | (OSS/BSS) | 158 +--------------------------+ 160 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 161 Network Service YANG data models 163 +------------+ +-------------+ +-------------+ 164 | | | | | | 165 | - VPWS | | - VPLS | | L3VPN | 166 | - L2VPN | | - L2VPN | | | 167 | | | | | | 168 +------------+ +-------------+ +-------------+ 170 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 171 Network Element YANG data models 173 +------------+ +------------+ +-------------+ +------------+ 174 | | | | | | | | 175 | MPLS | | BGP | | IPv4 & IPv6 | | Ethernet | 176 | | | | | | | | 177 +------------+ +------------+ +-------------+ +------------+ 179 Fig. 1 YANG Model Layers 181 2.1. Network Service YANG Data Models 183 Network Service YANG Data Models describe the characteristics of a 184 service, as agreed upon with consumers of that service. That is, a 185 service model does not expose the detailed configuration parameters 186 of all participating network elements and features, but describes an 187 abstract model that allows instances of the service to be decomposed 188 into instance data according to the Network Element data models of 189 the participating network elements. The service-to-element 190 decomposition is a separate process with details depending on how the 191 network operator chooses to realize the service. For the purpose of 192 this document we will use the term "orchestrator" to describe a 193 system implementing such a process. 195 As an example, the Network Service model included in 196 [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstracted 197 model for Layer 3 IP VPN service configuration. An orchestrator 198 receives operations on service instances according to the service 199 model and decomposes the data into specific Network Element models to 200 configure the participating network elements to perform the intent of 201 the service. 203 Network Service YANG models define services models to be consumed by 204 external systems. These models are commonly designed, developed and 205 deployed by network infrastructure teams. 207 YANG allows for different design patterns to describe network 208 services, ranging from monolithic to component-based approaches. 210 The monolithic approach captures the entire service in a single model 211 and does not put focus on reusability of internal data definitions 212 and groupings. The monolithic approach has the advantages of single- 213 purpose development including speed at the expense of reusability. 215 The component-based approach captures device-centric features (e.g. 216 the definition of a VRF, routing protocols, or packet filtering) in a 217 vendor-independent manner. The components are designed for reuse 218 across many services. The set of components required for a specific 219 service is then composed into the higher-level service. The 220 component-based approach has the advantages of modular development 221 including a higher degree of reusability at the expense of initial 222 speed. 224 As an example, an L2VPN service can be built on many different types 225 of transport network technologies, including e.g. MPLS or carrier 226 ethernet. A component-based approach would allow for reuse of e.g. 227 UNI-interface definitions independent of the underlying transport 228 network (e.g. MEF UNI interface or MPLS interface). The monolithic 229 approach would assume a specific set of transport technologies and 230 interface definitions. 232 2.2. Network Element YANG Data models 234 Network Element YANG Data Models describe the configuration, state 235 data and operations of a network device as defined by the vendor of 236 that device. The models are commonly structured around features of 237 the device, e.g. interface configuration [RFC7223], OSPF 238 configuration [I-D.ietf-ospf-yang], and firewall rules definitions 239 [I-D.ietf-netmod-acl-model]. The model provides a coherent data 240 model representation of what is commonly a very mixed software 241 environment consisting of the operating system and applications 242 running on the device. 244 The decomposition, ordering, and execution of changes to the 245 operating system and application configuration is the task of the 246 management framework that implements the YANG model. 248 3. Second Dimension: Model Types 250 This document suggests classifying YANG model types as either 251 standard YANG models, vendor-specific YANG models and extensions, and 252 user-specific YANG models and extensions 254 The suggested classification applies to both Network Element YANG 255 Data Models and Network Service YANG Data Models. 257 It is to be expected that real-world implementations of both Network 258 Service and Network Element models will include a mix of all three 259 types of models. 261 3.1. Standard YANG Models 263 Standard YANG models are published by standards-defining 264 organizations (SDOs). While there is no formal definition of what 265 construes an SDO, a common feature is that they publish 266 specifications along specific processes with content that reflects 267 some sort of membership consensus. The specifications are developed 268 for wide use among the membership or for audiences beyond that. 270 The lifecycle of these models is driven by the editing cycle of the 271 specification and not tied to a specific implementation. 273 Examples of SDOs in the networking industry are the IETF, the IEEE 274 and the MEF. 276 3.2. Vendor-specific YANG Models and Extensions 278 Vendor-specific YANG models are developed by organizations with the 279 intent to support a specific set of implementations under control of 280 that organization. The intent of these models range from providing 281 openly published YANG models that may eventually be contributed back 282 to, or adopted by an SDO, to strictly internal YANG models not 283 intended for external consumption. 285 The lifecycle of these models are generally aligned with the release 286 cycle of the product or open source software project deliverables. 288 It is worth noting that there is an increasing amount of interaction 289 between open source projects and SDOs in the networking industry. 290 This includes open source projects implementing published standards 291 as well as open source projects contributing content to SDO 292 processes. 294 Vendors also develop Vendor-specific Extensions to standard models 295 using YANG constructs for extending data definitions of previously 296 published models. This is done using the 'augment' statement that 297 allows locally defined data trees to be augmented into locations in 298 externally defined data trees. 300 Vendors use this to extend standard data models to cover the full 301 scope of features in implementations, which commonly is broader than 302 what is covered by the standard model. 304 3.3. User-specific YANG Models and Extensions 306 User-specific YANG models are developed by organizations that operate 307 YANG-based infrastructure including devices and orchestrators. The 308 intent of these models is to express the specific needs for a certain 309 implementation, above and beyond what is provided by vendors. 311 This model type obviously requires the infrastructure to support the 312 introduction of user-provided models and extensions. This would 313 include ability to describe the service-to-network decomposition in 314 orchestrators and the model to configuration decomposition in 315 devices. 317 The lifecycle of these models are generally aligned with the change 318 cadence of the infrastructure. 320 3.4. Adding Models to Catalogs 322 The suggested classification in this document supports the creation 323 of catalogs, such as proposed in 324 [I-D.openconfig-netmod-model-catalog]. Such catalogs allows for easy 325 lookup and reusability of YANG models. SDO-classified models also 326 provide an educational resource providing architectural guidelines 327 for model development, based on a membership reviewn and consensus. 329 3.5. Security Considerations 331 At this stage, authors of the draft didn't look into security 332 considerations. 334 3.6. IANA Considerations 336 This document requests no action by IANA. 338 3.7. Acknowledgements 340 Thanks to David Ball and David Hansford for feedback and suggestions. 342 3.8. Change log [RFC Editor: Please remove] 344 version 00: Renamed and small fixes based on WG feedback. 346 version 01: Language fixes, collapsing of vendor models and 347 extensions, and the introduction of user models and extensions. 349 version 02: Added two sections, Model Catalog and Benefits of model 350 classification. 352 4. References 354 4.1. Normative References 356 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 357 the Network Configuration Protocol (NETCONF)", RFC 6020, 358 DOI 10.17487/RFC6020, October 2010, 359 . 361 4.2. Informative References 363 [I-D.ietf-netmod-acl-model] 364 Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, 365 "Network Access Control List (ACL) YANG Data Model", 366 draft-ietf-netmod-acl-model-07 (work in progress), March 367 2016. 369 [I-D.ietf-ospf-yang] 370 Yeung, D., Qu, Y., Zhang, J., Bogdanovic, D., and K. 371 Koushik, "Yang Data Model for OSPF Protocol", draft-ietf- 372 ospf-yang-04 (work in progress), March 2016. 374 [I-D.openconfig-netmod-model-catalog] 375 D'Souza, K., Shaikh, A., and R. Shakir, "Catalog and 376 registry for YANG models", draft-openconfig-netmod-model- 377 catalog-00 (work in progress), October 2015. 379 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 380 and A. Bierman, Ed., "Network Configuration Protocol 381 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 382 . 384 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 385 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 386 . 388 [Writable-MIB-Module-IESG-Statement] 389 "Writable MIB Module IESG Statement", 390 . 393 [YANG-Data-Model-for-L3VPN-service-delivery] 394 "YANG Data Model for L3VPN service delivery", 395 . 397 Authors' Addresses 399 Dean Bogdanovic 401 Email: ivandean@gmail.com 403 Benoit Claise 404 Cisco Systems, Inc. 406 Email: bclaise@cisco.com 408 Carl Moberg 409 Cisco Systems, Inc. 411 Email: camoberg@cisco.com