idnits 2.17.1 draft-ietf-netmod-yang-model-classification-04.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 (October 26, 2016) is 2732 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-09 == Outdated reference: A later version (-29) exists of draft-ietf-ospf-yang-05 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD D. Bogdanovic 3 Internet-Draft Volta Networks, Inc. 4 Intended status: Informational B. Claise 5 Expires: April 29, 2017 C. Moberg 6 Cisco Systems, Inc. 7 October 26, 2016 9 YANG Module Classification 10 draft-ietf-netmod-yang-model-classification-04 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 YANG modules for a wide variety of 19 applications. At the same time, there is currently no well-known 20 terminology to categorize various types of YANG modules. 22 A consistent terminology would help with the categorization of YANG 23 modules, assist in the analysis of the YANG data modeling efforts in 24 the IETF and other organizations, and bring clarity to the YANG- 25 related discussions between the different groups. 27 This document describes a set of concepts and associated terms to 28 support consistent classification of YANG modules. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 29, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. First Dimension: YANG Module Abstraction Layers . . . . . . . 4 67 2.1. Network Service YANG Modules . . . . . . . . . . . . . . 6 68 2.2. Network Element YANG Modules . . . . . . . . . . . . . . 7 69 3. Second Dimension: Module Types . . . . . . . . . . . . . . . 7 70 3.1. Standard YANG Modules . . . . . . . . . . . . . . . . . . 8 71 3.2. Vendor-specific YANG Modules and Extensions . . . . . . . 8 72 3.3. User-specific YANG Modules and Extensions . . . . . . . . 9 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 76 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 9 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 8.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 The Internet Engineering Steering Group (IESG) has been actively 85 encouraging IETF working groups to use the YANG modeling language 86 [RFC6020], [RFC7950] and NETCONF protocol [RFC6241] for configuration 87 management purposes, especially in new working group charters 88 [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 modules according to abstraction, or how to classify 98 modules along the continuum spanning formal standards publications, 99 vendor-specific modules and modules 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 modules in two 103 dimensions: 105 o The layering of modules based on their abstraction levels 107 o The type of module based on the nature and intent of the content 109 The intent of this document is to provide a taxonomy to simplify 110 human communication around YANG modules. The authors acknowledge 111 that the classification boundaries are at times blurry, but believe 112 that this document should provide a robust starting point as the YANG 113 community gains further experience with designing and deploying 114 modules. To be more explicit, the authors believe that the 115 classification criteria will change over time. 117 A number of module types have created substantial discussion during 118 the development of this document including those concerned with 119 topologies. Topology modules are useful both on the Network Element 120 level (e.g. link-state database content) as well as on the Network 121 Service level (e.g. network-wide, configured topologies). In the 122 end, it is the module developer that classifies the module according 123 to the initial intent of the module content. 125 This document should provide benefits to multiple audiences: 127 o First, a common taxonomy helps with the different standards 128 development organizations and industry consortia discussions, 129 whose goals are determined in their respective areas of work. 131 o Second, operators might look at the YANG module classification 132 type to understand which Network Service YANG modules and Network 133 Element YANG modules are available for their service composition. 134 It is difficult to determine the module type without inspecting 135 the YANG module itself. The YANG module name might provide some 136 useful information but is not a definite answer. For example, an 137 L2VPN YANG module might be a Network Service YANG module, ready to 138 be used by the operators. Alternatively, it might be a Network 139 Element YANG module that contains the L2VPN data definitions 140 required to be configured on a single device. 142 o And thirdly, this taxonomy would help equipment vendors (whether 143 physical or virtual), controller vendors, orchestrator vendors to 144 explain to their customers the relationship between the different 145 YANG modules they propose in their products. See Figure 1. 147 1.1. Terminology 149 [RFC7950] specifies: 151 o data model: A data model describes how data is represented and 152 accessed. 154 o module: A YANG module defines a hierarchy of nodes that can be 155 used for NETCONF-based operations. With its definitions and the 156 definitions it imports or includes from elsewhere, a module is 157 self-contained and "compilable". 159 2. First Dimension: YANG Module Abstraction Layers 161 Module developers have taken two approaches to developing YANG 162 modules: top-down and bottom-up. The top-down approach starts with 163 high level abstractions modeling business or customer requirements 164 and maps them to specific networking technologies. The bottom-up 165 approach starts with fundamental networking technologies and maps 166 them into more abstract constructs. 168 There are currently no specific requirements on, or well-defined best 169 practices around the development of YANG modules. For the purpose of 170 this document we assume that both approaches (bottom-up and top-down) 171 will be used as they both provide benefits that appeal to different 172 groups. 174 For layering purposes, this document suggests the classification of 175 YANG modules into two distinct abstraction layers: 177 o Network Element YANG Modules describe the configuration, state 178 data, operations and notifications of specific device-centric 179 technologies or features 181 o Network Service YANG Modules describe the configuration, state 182 data, operations and notifications of abstract representations of 183 services implemented on one or multiple network elements 184 +--------------------------+ 185 | Operations and Business | 186 | Support Systems | 187 | (OSS/BSS) | 188 +--------------------------+ 190 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 191 Network Service YANG Modules 193 +------------+ +-------------+ +-------------+ 194 | | | | | | 195 | - L2VPN | | - L2VPN | | L3VPN | 196 | - VPWS | | - VPLS | | | 197 | | | | | | 198 +------------+ +-------------+ +-------------+ 200 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 201 Network Element YANG Modules 203 +------------+ +------------+ +-------------+ +------------+ 204 | | | | | | | | 205 | MPLS | | BGP | | IPv4 / IPv6 | | Ethernet | 206 | | | | | | | | 207 +------------+ +------------+ +-------------+ +------------+ 209 L2VPN: Layer 2 Virtual Private Network 210 L3VPN: Layer 3 Virtual Private Network 211 VPWS: Virtual Private Wire Service 212 VPLS: Virtual Private LAN Service 214 Figure 1: YANG Module Layers 216 Figure 1 illustrates the application of YANG modules at different 217 layers of abstraction. Layering of modules allows for reusability of 218 existing lower layer modules by higher level modules while limiting 219 duplication of features across layers. 221 For module developers, per-layer modeling allows for separation of 222 concern across editing teams focusing on specific areas. 224 As an example, experience from the IETF shows that creating useful 225 network element YANG modules for e.g. routing or switching protocols 226 requires teams that include developers with experience of 227 implementing those protocols. 229 On the other hand, network service YANG modules are best developed by 230 network operators experienced in defining network services for 231 consumption by programmers developing e.g. flow-through provisioning 232 systems or self-service portals. 234 2.1. Network Service YANG Modules 236 Network Service YANG Modules describe the characteristics of a 237 service, as agreed upon with consumers of that service. That is, a 238 service module does not expose the detailed configuration parameters 239 of all participating network elements and features, but describes an 240 abstract model that allows instances of the service to be decomposed 241 into instance data according to the Network Element YANG Modules of 242 the participating network elements. The service-to-element 243 decomposition is a separate process with details depending on how the 244 network operator chooses to realize the service. For the purpose of 245 this document we will use the term "orchestrator" to describe a 246 system implementing such a process. 248 As an example, the Network Service YANG Module defined in 249 [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract 250 model for Layer 3 IP VPN service configuration. This module includes 251 e.g. the concept of a 'site-network-access' to represent bearer and 252 connection parameters. An orchestrator receives operations on 253 service instances according to the service module and decomposes the 254 data into specific Network Element YANG Modules to configure the 255 participating network elements to perform the intent of the service. 256 In the case of the L3VPN module, this would include translating the 257 'site-network-access' parameters to the appropriate parameters in the 258 Network Element YANG Module implemented on the constituent elements. 260 Network Service YANG Modules define service models to be consumed by 261 external systems. These modules are commonly designed, developed and 262 deployed by network infrastructure teams. 264 YANG allows for different design patterns to describe network 265 services, ranging from monolithic to component-based approaches. 267 The monolithic approach captures the entire service in a single 268 module and does not put focus on reusability of internal data 269 definitions and groupings. The monolithic approach has the 270 advantages of single-purpose development including speed at the 271 expense of reusability. 273 The component-based approach captures device-centric features (e.g. 274 the definition of a VRF, routing protocols, or packet filtering) in a 275 vendor-independent manner. The components are designed for reuse 276 across many service modules. The set of components required for a 277 specific service is then composed into the higher-level service. The 278 component-based approach has the advantages of modular development 279 including a higher degree of reusability at the expense of initial 280 speed. 282 As an example, an L2VPN service can be built on many different types 283 of transport network technologies, including e.g. MPLS or carrier 284 ethernet. A component-based approach would allow for reuse of e.g. 285 UNI-interface definitions independent of the underlying transport 286 network (e.g. MEF UNI interface or MPLS interface). The monolithic 287 approach would assume a specific set of transport technologies and 288 interface definitions. 290 2.2. Network Element YANG Modules 292 Network Element YANG Modules describe the characteristics of a 293 network device as defined by the vendor of that device. The modules 294 are commonly structured around features of the device, e.g. interface 295 configuration [RFC7223], OSPF configuration [I-D.ietf-ospf-yang], and 296 firewall rules definitions [I-D.ietf-netmod-acl-model]. 298 The module provides a coherent data model representation of the 299 software environment consisting of the operating system and 300 applications running on the device. The decomposition, ordering, and 301 execution of changes to the operating system and application 302 configuration is the task of the agent that implements the module. 304 3. Second Dimension: Module Types 306 This document suggests classifying YANG module types as standard YANG 307 modules, vendor-specific YANG modules and extensions, or user- 308 specific YANG modules and extensions 310 The suggested classification applies to both Network Element YANG 311 Modules and Network Service YANG Modules. 313 It is to be expected that real-world implementations of both Network 314 Service YANG Modules and Network Element YANG Modules will include a 315 mix of all three types of modules. 317 Figure 2 illustrates the relationship between the three types of 318 modules. 320 +--------------+ 321 | User | 322 | Extensions | 323 +------+-------+ 324 Augments 325 +------+-------+ +--------------+ +--------------+ 326 | Vendor | | User | | User | 327 | Extensions | | Extensions | | Extensions | 328 +------+-------+ +------+-------+ +------+-------+ 329 Augments Augments Augments 330 +------+-----------------+-------+ +------+-------+ +--------------+ 331 | Standard | | Vendor | | User | 332 | Modules | | Modules | | Modules | 333 +--------------------------------+ +--------------+ +--------------+ 335 Figure 2: YANG Module Types 337 3.1. Standard YANG Modules 339 Standard YANG Modules are published by standards-defining 340 organizations (SDOs). While there is no formal definition of what 341 construes an SDO, a common feature is that they publish 342 specifications along specific processes with content that reflects 343 some sort of membership consensus. The specifications are developed 344 for wide use among the membership or for audiences beyond that. 346 The lifecycle of these modules is driven by the editing cycle of the 347 specification and not tied to a specific implementation. 349 Examples of SDOs in the networking industry are the IETF, the IEEE 350 and the MEF. 352 3.2. Vendor-specific YANG Modules and Extensions 354 Vendor-specific YANG Modules are developed by organizations with the 355 intent to support a specific set of implementations under control of 356 that organization. For example vendors of virtual or physical 357 equipment, industry consortia, and opensource projects. The intent 358 of these modules range from providing openly published YANG modules 359 that may eventually be contributed back to, or adopted by, an SDO, to 360 strictly internal YANG modules not intended for external consumption. 362 The lifecycle of these modules are generally aligned with the release 363 cycle of the product or open source software project deliverables. 365 It is worth noting that there is an increasing amount of interaction 366 between open source projects and SDOs in the networking industry. 367 This includes open source projects implementing published standards 368 as well as open source projects contributing content to SDO 369 processes. 371 Vendors also develop Vendor-specific Extensions to standard modules 372 using YANG constructs for extending data definitions of previously 373 published modules. This is done using the 'augment' statement that 374 allows locally defined data trees to be augmented into locations in 375 externally defined data trees. 377 Vendors use this to extend standard modules to cover the full scope 378 of features in implementations, which commonly is broader than that 379 covered by the standard module. 381 3.3. User-specific YANG Modules and Extensions 383 User-specific YANG Modules are developed by organizations that 384 operate YANG-based infrastructure including devices and 385 orchestrators. For example, network administrators in enterprises, 386 or at service providers. The intent of these modules is to express 387 the specific needs for a certain implementation, above and beyond 388 what is provided by vendors. 390 This module type obviously requires the infrastructure to support the 391 introduction of user-provided modules and extensions. This would 392 include ability to describe the service-to-network decomposition in 393 orchestrators and the module to configuration decomposition in 394 devices. 396 The lifecycles of these modules are generally aligned with the change 397 cadence of the infrastructure. 399 4. Security Considerations 401 This document doesn't have any Security Considerations. 403 5. IANA Considerations 405 This document has no IANA actions. 407 6. Acknowledgements 409 Thanks to David Ball and David Hansford for feedback and suggestions. 411 7. Change log [RFC Editor: Please remove] 413 version 00: Renamed and small fixes based on WG feedback. 415 version 01: Language fixes, collapsing of vendor data models and 416 extensions, and the introduction of user data models and extensions. 418 version 02: Updated the YANG Module Catalog section, terminology 419 alignment (YANG data model versus YANG module), explain better the 420 distinction between the Network Element and Service YANG data models 421 even if sometimes there are grey areas, editorial pass. Changed the 422 use of the term 'model' to 'module' to be better aligned with 423 RFC6020. 425 8. References 427 8.1. Normative References 429 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 430 the Network Configuration Protocol (NETCONF)", RFC 6020, 431 DOI 10.17487/RFC6020, October 2010, 432 . 434 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 435 and A. Bierman, Ed., "Network Configuration Protocol 436 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 437 . 439 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 440 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 441 . 443 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 444 RFC 7950, DOI 10.17487/RFC7950, August 2016, 445 . 447 8.2. Informative References 449 [I-D.ietf-netmod-acl-model] 450 Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, 451 "Network Access Control List (ACL) YANG Data Model", 452 draft-ietf-netmod-acl-model-09 (work in progress), October 453 2016. 455 [I-D.ietf-ospf-yang] 456 Yeung, D., Qu, Y., Zhang, Z., Bogdanovic, D., and K. 457 Koushik, "Yang Data Model for OSPF Protocol", draft-ietf- 458 ospf-yang-05 (work in progress), July 2016. 460 [Writable-MIB-Module-IESG-Statement] 461 "Writable MIB Module IESG Statement", 462 . 465 [YANG-Data-Model-for-L3VPN-service-delivery] 466 "YANG Data Model for L3VPN service delivery", 467 . 469 Authors' Addresses 471 Dean Bogdanovic 472 Volta Networks, Inc. 474 Email: dean@voltanet.io 476 Benoit Claise 477 Cisco Systems, Inc. 478 De Kleetlaan 6a b1 479 1831 Diegem 480 Belgium 482 Phone: +32 2 704 5622 483 Email: bclaise@cisco.com 485 Carl Moberg 486 Cisco Systems, Inc. 488 Email: camoberg@cisco.com