idnits 2.17.1 draft-ietf-netmod-yang-model-classification-02.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 (June 22, 2016) is 2865 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 Volta Networks, Inc. 4 Intended status: Informational B. Claise 5 Expires: December 24, 2016 C. Moberg 6 Cisco Systems, Inc. 7 June 22, 2016 9 YANG Module Classification 10 draft-ietf-netmod-yang-model-classification-02 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 of configuration, state data 19 and 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 modules. 23 A consistent terminology would help with the categorization of YANG 24 modules, 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 modules. 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 December 24, 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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. First Dimension: YANG Data Model Abstraction Layers . . . . . 4 68 2.1. Network Service YANG Modules . . . . . . . . . . . . . . 6 69 2.2. Network Element YANG Modules . . . . . . . . . . . . . . 7 70 3. Second Dimension: Module Types . . . . . . . . . . . . . . . 7 71 3.1. Standard YANG Modules . . . . . . . . . . . . . . . . . . 8 72 3.2. Vendor-specific YANG Modules and Extensions . . . . . . . 8 73 3.3. User-specific YANG Modules and Extensions . . . . . . . . 9 74 4. Adding The Classification Type to YANG Module Catalogs . . . 9 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 78 8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 10 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 81 9.2. Informative References . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 The Internet Engineering Steering Group (IESG) has been actively 87 encouraging IETF working groups to use the YANG [RFC6020] 88 [I-D.ietf-netmod-rfc6020bis] and NETCONF [RFC6241] and YANG standards 89 for configuration management purposes, especially in new working 90 group charters [Writable-MIB-Module-IESG-Statement]. 92 YANG is also gaining wide acceptance as the de-facto standard 93 modeling language in the broader industry. This extends beyond the 94 IETF, including many standards development organizations, industry 95 consortia, ad hoc groups, open source projects, vendors, and end- 96 users. 98 There are currently no clear guidelines on how to classify the 99 layering of YANG modules according to abstraction, or how to classify 100 modules along the continuum spanning formal standards publications, 101 vendor-specific modules and modules provided by end-users. 103 This document presents a set of concepts and terms to form a useful 104 taxonomy for consistent classification of YANG modules in two 105 dimensions: 107 o The layering of modules based on their abstraction levels 109 o The type of module based on the nature and intent of the content 111 The intent of this document is to provide a taxonomy to simplify 112 human communication around YANG modules. The authors acknowledge 113 that the classification boundaries are at times blurry, but believe 114 that this document should provide a robust starting point as the YANG 115 community gain further experience with designing and deploying 116 modules. To be more explicit, the authors believe that the 117 classification criteria will change over time. 119 An example of a type of module that have created substantial 120 discussion during the development of this document is topologies. 121 Topology models are useful both on the Network Element level (e.g. 122 link-state database content) as well as in the Network Service level 123 (e.g. network-wide, configured topologies). In the end, it is the 124 module developer that classifies the module according to the initial 125 intent of the module content. 127 This document should provide benefits to multiple audiences: 129 o First, a common taxonomy helps with the different standards 130 development organizations and industry consortia discussions, 131 whose goals are determined in their respective areas of work. 133 o Second, operators might look at the YANG module classification 134 type to understand which Network Service YANG modules and Network 135 Element YANG modules are available for their service composition. 136 It is difficult to determine the module type without inspecting 137 the YANG module itself. The YANG module name might provide some 138 useful information but is not a definite answer. For example, an 139 L2VPN YANG module might be a Network Service YANG module, ready to 140 be used by the operators. Alternatively, it might be a Network 141 Element YANG module that contains the L2VPN data definitions 142 required to be configured on a single device. 144 o And thirdly, this taxonomy would help equipment vendors (whether 145 physical or virtual), controller vendors, orchestrator vendors to 146 explain to their customers the relationship between the different 147 YANG modules they propose in their products. See Figure 1. 149 1.1. Terminology 151 RFC6020bis [I-D.ietf-netmod-rfc6020bis] specifies: 153 o data model: A data model describes how data is represented and 154 accessed. 156 o module: A YANG module defines a hierarchy of nodes that can be 157 used for NETCONF-based operations. With its definitions and the 158 definitions it imports or includes from elsewhere, a module is 159 self-contained and "compilable". 161 2. First Dimension: YANG Data Model Abstraction Layers 163 Model developers have taken two approaches to developing YANG 164 modules: top-down and bottom-up. The top-down approach starts with 165 high level abstractions modeling business or customer requirements 166 and maps them to specific networking technologies. The bottom-up 167 approach starts with fundamental networking technologies and maps 168 them into more abstract constructs. 170 There are currently no specific requirements on, or well-defined best 171 practices around the development of YANG modules For the purpose of 172 this document we assume that both approaches (bottom-up and top-down) 173 will be used as they both provide benefits that appeal to different 174 groups. 176 For layering purposes, this document suggests the classification of 177 YANG modules into two distinct abstraction layers: 179 o Network Element YANG Modules describe the configuration, state 180 data and operations of specific device-centric technologies or 181 features 183 o Network Service YANG Modules describe the configuration, state 184 data and operations of an abstract representation of a service 185 implemented on one or multiple network elements 187 Figure 1 illustrates the application of YANG modules at different 188 layers of abstraction. Layering of modules allows for reusability of 189 existing lower layer modules by higher level modules while limiting 190 duplication of features across layers. 192 For module developers, per-layer modeling allows for separation of 193 concern across editing teams focusing on specific areas. 195 As an example, experience from the IETF shows that creating useful 196 network element YANG modules for e.g. routing or switching protocols 197 requires teams that include developers with experience of 198 implementing those protocols. 200 On the other hand, network service YANG modules are best developed by 201 network operators experienced in defining network services for 202 consumption by programmers developing e.g. flow-through provisioning 203 systems or self-service portals. 205 +--------------------------+ 206 | Operations and Business | 207 | Support Systems | 208 | (OSS/BSS) | 209 +--------------------------+ 211 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 212 Network Service YANG Modules 214 +------------+ +-------------+ +-------------+ 215 | | | | | | 216 | - L2VPN | | - L2VPN | | L3VPN | 217 | - VPWS | | - VPLS | | | 218 | | | | | | 219 +------------+ +-------------+ +-------------+ 221 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 222 Network Element YANG Modules 224 +------------+ +------------+ +-------------+ +------------+ 225 | | | | | | | | 226 | MPLS | | BGP | | IPv4 / IPv6 | | Ethernet | 227 | | | | | | | | 228 +------------+ +------------+ +-------------+ +------------+ 230 L2VPN: Layer 2 Virtual Private Network 231 L3VPN: Layer 3 Virtual Private Network 232 VPWS: Virtual Private Wire Service 233 VPLS: Virtual Private LAN Service 235 Figure 1: YANG Module Layers 237 2.1. Network Service YANG Modules 239 Network Service YANG Modules describe the characteristics of a 240 service, as agreed upon with consumers of that service. That is, a 241 service model does not expose the detailed configuration parameters 242 of all participating network elements and features, but describes an 243 abstract model that allows instances of the service to be decomposed 244 into instance data according to the Network Element Modules of the 245 participating network elements. The service-to-element decomposition 246 is a separate process with details depending on how the network 247 operator chooses to realize the service. For the purpose of this 248 document we will use the term "orchestrator" to describe a system 249 implementing such a process. 251 As an example, the Network Service YANG Module included in 252 [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract 253 model for Layer 3 IP VPN service configuration. This model includes 254 e.g. the concept of a 'site-network-access' to represent bearer and 255 connection parameters. An orchestrator receives operations on 256 service instances according to the service model and decomposes the 257 data into specific Network Element Modules to configure the 258 participating network elements to perform the intent of the service. 259 In the case of the L3VPN module, this would include translating the 260 'site-network-access' parameters to the appropriate parameters in the 261 Network Element YANG Module implemented on the constituent elements. 263 Network Service YANG Modules define services models to be consumed by 264 external systems. These modules are commonly designed, developed and 265 deployed by network infrastructure teams. 267 YANG allows for different design patterns to describe network 268 services, ranging from monolithic to component-based approaches. 270 The monolithic approach captures the entire service in a single 271 module and does not put focus on reusability of internal data 272 definitions and groupings. The monolithic approach has the 273 advantages of single-purpose development including speed at the 274 expense of reusability. 276 The component-based approach captures device-centric features (e.g. 277 the definition of a VRF, routing protocols, or packet filtering) in a 278 vendor-independent manner. The components are designed for reuse 279 across many service modules. The set of components required for a 280 specific service is then composed into the higher-level service. The 281 component-based approach has the advantages of modular development 282 including a higher degree of reusability at the expense of initial 283 speed. 285 As an example, an L2VPN service can be built on many different types 286 of transport network technologies, including e.g. MPLS or carrier 287 ethernet. A component-based approach would allow for reuse of e.g. 288 UNI-interface definitions independent of the underlying transport 289 network (e.g. MEF UNI interface or MPLS interface). The monolithic 290 approach would assume a specific set of transport technologies and 291 interface definitions. 293 2.2. Network Element YANG Modules 295 Network Element YANG Modules describe the configuration, state data 296 and operations of a network device as defined by the vendor of that 297 device. The modules are commonly structured around features of the 298 device, e.g. interface configuration [RFC7223], OSPF configuration 299 [I-D.ietf-ospf-yang], and firewall rules definitions 300 [I-D.ietf-netmod-acl-model]. 302 The module provides a coherent data model representation of what is 303 commonly a very mixed software environment consisting of the 304 operating system and applications running on the device. The 305 decomposition, ordering, and execution of changes to the operating 306 system and application configuration is the task of the management 307 framework that implements the YANG module. 309 3. Second Dimension: Module Types 311 This document suggests classifying YANG module types as either 312 standard YANG modules, vendor-specific YANG modules and extensions, 313 and user-specific YANG modules and extensions 315 The suggested classification applies to both Network Element YANG 316 Modules and Network Service YANG Modules. 318 It is to be expected that real-world implementations of both Network 319 Service and Network Element YANG Modules will include a mix of all 320 three types of modules. 322 Figure 2 illustrates the relationship between the three types of 323 modules. 325 +--------------+ 326 | User | 327 | Extensions | 328 +------+-------+ 329 Augments 330 +------+-------+ +--------------+ +--------------+ 331 | Vendor | | User | | User | 332 | Extensions | | Extensions | | Extensions | 333 +------+-------+ +------+-------+ +------+-------+ 334 Augments Augments Augments 335 +------+-----------------+-------+ +------+-------+ +--------------+ 336 | Standard | | Vendor | | User | 337 | Models | | Models | | Models | 338 +--------------------------------+ +--------------+ +--------------+ 340 Figure 2: YANG Module Types 342 3.1. Standard YANG Modules 344 Standard YANG Modules are published by standards-defining 345 organizations (SDOs). While there is no formal definition of what 346 construes an SDO, a common feature is that they publish 347 specifications along specific processes with content that reflects 348 some sort of membership consensus. The specifications are developed 349 for wide use among the membership or for audiences beyond that. 351 The lifecycle of these modules is driven by the editing cycle of the 352 specification and not tied to a specific implementation. 354 Examples of SDOs in the networking industry are the IETF, the IEEE 355 (Institute of Electrical and Electronics Engineers) and the MEF. 357 3.2. Vendor-specific YANG Modules and Extensions 359 Vendor-specific YANG modules are developed by organizations with the 360 intent to support a specific set of implementations under control of 361 that organization. For example vendors of virtual or physical 362 equipment, industry consortia, and opensource projects. The intent 363 of these modules range from providing openly published YANG modules 364 that may eventually be contributed back to, or adopted by an SDO, to 365 strictly internal YANG modules not intended for external consumption. 367 The lifecycle of these modules are generally aligned with the release 368 cycle of the product or open source software project deliverables. 370 It is worth noting that there is an increasing amount of interaction 371 between open source projects and SDOs in the networking industry. 372 This includes open source projects implementing published standards 373 as well as open source projects contributing content to SDO 374 processes. 376 Vendors also develop Vendor-specific Extensions to standard modules 377 using YANG constructs for extending data definitions of previously 378 published modules. This is done using the 'augment' statement that 379 allows locally defined data trees to be augmented into locations in 380 externally defined data trees. 382 Vendors use this to extend standard modules to cover the full scope 383 of features in implementations, which commonly is broader than what 384 is covered by the standard module. 386 3.3. User-specific YANG Modules and Extensions 388 User-specific YANG modules are developed by organizations that 389 operate YANG-based infrastructure including devices and 390 orchestrators. For example, network administrators in enterprises, 391 or operators service providers. The intent of these modules is to 392 express the specific needs for a certain implementation, above and 393 beyond what is provided by vendors. 395 This module type obviously requires the infrastructure to support the 396 introduction of user-provided modules and extensions. This would 397 include ability to describe the service-to-network decomposition in 398 orchestrators and the module to configuration decomposition in 399 devices. 401 The lifecycle of these modules are generally aligned with the change 402 cadence of the infrastructure. 404 4. Adding The Classification Type to YANG Module Catalogs 406 The suggested classification in this document would be an useful 407 information in a catalog of YANG modules. Such catalog allows for 408 easy lookup and reusability of YANG modules. Practically, the YANG 409 module classification type would be an additional leaf to YANG module 410 specified in [I-D.openconfig-netmod-model-catalog]: 412 leaf module-class{ 413 type enum { 414 service 415 device 416 notApplicable 417 } 418 description 419 "Categorization of the YANG module based on 420 draft-ietf-netmod-yang-model-classification."; 421 } 423 Note: this leaf should actually be moved to 424 [I-D.openconfig-netmod-model-catalog]. Note2: since a YANG module 425 can belong to both service and device, the ENUM is not appropriate. 426 A extensible list of module type is more appropriate. 428 Indeed, without inspecting the YANG module itself, it's difficult to 429 determine whether its type is a network service or a network element. 430 The YANG module name might provide some useful information but is not 431 a definite answer. 433 5. Security Considerations 435 This document doesn't have any Security Considerations". 437 6. IANA Considerations 439 This document has no IANA actions. 441 7. Acknowledgements 443 Thanks to David Ball and David Hansford for feedback and suggestions. 445 8. Change log [RFC Editor: Please remove] 447 version 00: Renamed and small fixes based on WG feedback. 449 version 01: Language fixes, collapsing of vendor data models and 450 extensions, and the introduction of user data models and extensions. 452 version 02: Updated the YANG Module Catalog section, terminology 453 alignment (YANG data model versus YANG module), epxlain better the 454 distinction between the Network Element and Service YANG data models 455 even if sometimes there are grey areas, editorial pass. Changed the 456 use of the term 'model' to 'module' to be better aligned with 457 RFC6020. 459 9. References 461 9.1. Normative References 463 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 464 the Network Configuration Protocol (NETCONF)", RFC 6020, 465 DOI 10.17487/RFC6020, October 2010, 466 . 468 9.2. Informative References 470 [I-D.ietf-netmod-acl-model] 471 Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, 472 "Network Access Control List (ACL) YANG Data Model", 473 draft-ietf-netmod-acl-model-07 (work in progress), March 474 2016. 476 [I-D.ietf-netmod-rfc6020bis] 477 Bjorklund, M., "The YANG 1.1 Data Modeling Language", 478 draft-ietf-netmod-rfc6020bis-14 (work in progress), June 479 2016. 481 [I-D.ietf-ospf-yang] 482 Yeung, D., Qu, Y., Zhang, Z., Bogdanovic, D., and K. 483 Koushik, "Yang Data Model for OSPF Protocol", draft-ietf- 484 ospf-yang-04 (work in progress), March 2016. 486 [I-D.openconfig-netmod-model-catalog] 487 D'Souza, K., Shaikh, A., and R. Shakir, "Catalog and 488 registry for YANG models", draft-openconfig-netmod-model- 489 catalog-00 (work in progress), October 2015. 491 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 492 and A. Bierman, Ed., "Network Configuration Protocol 493 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 494 . 496 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 497 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 498 . 500 [Writable-MIB-Module-IESG-Statement] 501 "Writable MIB Module IESG Statement", 502 . 505 [YANG-Data-Model-for-L3VPN-service-delivery] 506 "YANG Data Model for L3VPN service delivery", 507 . 509 Authors' Addresses 511 Dean Bogdanovic 512 Volta Networks, Inc. 514 Email: dean@voltanet.io 516 Benoit Claise 517 Cisco Systems, Inc. 518 De Kleetlaan 6a b1 519 1831 Diegem 520 Belgium 522 Phone: +32 2 704 5622 523 Email: bclaise@cisco.com 525 Carl Moberg 526 Cisco Systems, Inc. 528 Email: camoberg@cisco.com