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