idnits 2.17.1 draft-ietf-netmod-yang-model-classification-06.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 (April 27, 2017) is 2556 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) ** Obsolete normative reference: RFC 8049 (Obsoleted by RFC 8299) == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-10 == Outdated reference: A later version (-29) exists of draft-ietf-ospf-yang-07 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: October 29, 2017 C. Moberg 6 Cisco Systems, Inc. 7 April 27, 2017 9 YANG Module Classification 10 draft-ietf-netmod-yang-model-classification-06 12 Abstract 14 The YANG data modeling language is currently being considered for a 15 wide variety of applications throughout the networking industry at 16 large. Many standards-defining organizations (SDOs), open source 17 software projects, vendors and users are using YANG to develop and 18 publish YANG modules for a wide variety of applications. At the same 19 time, there is currently no well-known terminology to categorize 20 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 October 29, 2017. 47 Copyright Notice 49 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . 10 76 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 10 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 data modeling 86 language [RFC7950], [RFC7950] and NETCONF protocol [RFC6241] for 87 configuration management purposes, especially in new working group 88 charters [Writable-MIB-Module-IESG-Statement]. 90 YANG is also gaining wide acceptance as the de-facto standard data 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 as a service model by network operator. Alternatively, it 139 might be a Network Element YANG module that contains the L2VPN 140 data definitions 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 support 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 hierarchies of schema nodes. With 155 its definitions and the definitions it imports or includes from 156 elsewhere, a module is self-contained and "compilable". 158 2. First Dimension: YANG Module Abstraction Layers 160 Module developers have taken two approaches to developing YANG 161 modules: top-down and bottom-up. The top-down approach starts with 162 high level abstractions modeling business or customer requirements 163 and maps them to specific networking technologies. The bottom-up 164 approach starts with fundamental networking technologies and maps 165 them into more abstract constructs. 167 There are currently no specific requirements on, or well-defined best 168 practices around the development of YANG modules. For the purpose of 169 this document we assume that both approaches (bottom-up and top-down) 170 will be used as they both provide benefits that appeal to different 171 groups. 173 For layering purposes, this document suggests the classification of 174 YANG modules into two distinct abstraction layers: 176 o Network Element YANG Modules describe the configuration, state 177 data, operations and notifications of specific device-centric 178 technologies or features 180 o Network Service YANG Modules describe the configuration, state 181 data, operations and notifications of abstract representations of 182 services implemented on one or multiple network elements 183 +--------------------------+ 184 | Operations and Business | 185 | Support Systems | 186 | (OSS/BSS) | 187 +--------------------------+ 189 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 190 Network Service YANG Modules 192 +------------+ +-------------+ +-------------+ 193 | | | | | | 194 | - L2VPN | | - L2VPN | | L3VPN | 195 | - VPWS | | - VPLS | | | 196 | | | | | | 197 +------------+ +-------------+ +-------------+ 199 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 200 Network Element YANG Modules 202 +------------+ +------------+ +-------------+ +------------+ 203 | | | | | | | | 204 | MPLS | | BGP | | IPv4 / IPv6 | | Ethernet | 205 | | | | | | | | 206 +------------+ +------------+ +-------------+ +------------+ 208 L2VPN: Layer 2 Virtual Private Network 209 L3VPN: Layer 3 Virtual Private Network 210 VPWS: Virtual Private Wire Service 211 VPLS: Virtual Private LAN Service 213 Figure 1: YANG Module Layers 215 Figure 1 illustrates the application of YANG modules at different 216 layers of abstraction. Layering of modules allows for reusability of 217 existing lower layer modules by higher level modules while limiting 218 duplication of features across layers. 220 For module developers, per-layer modeling allows for separation of 221 concern across editing teams focusing on specific areas. 223 As an example, experience from the IETF shows that creating useful 224 network element YANG modules for e.g. routing or switching protocols 225 requires teams that include developers with experience of 226 implementing those protocols. 228 On the other hand, network service YANG modules are best developed by 229 network operators experienced in defining network services for 230 consumption by programmers developing e.g. flow-through provisioning 231 systems or self-service portals. 233 2.1. Network Service YANG Modules 235 Network Service YANG Modules describe the characteristics of a 236 service, as agreed upon with consumers of that service. That is, a 237 service module does not expose the detailed configuration parameters 238 of all participating network elements and features, but describes an 239 abstract model that allows instances of the service to be decomposed 240 into instance data according to the Network Element YANG Modules of 241 the participating network elements. The service-to-element 242 decomposition is a separate process with details depending on how the 243 network operator chooses to realize the service. For the purpose of 244 this document we will use the term "orchestrator" to describe a 245 system implementing such a process. 247 Network Service YANG Modules define service models to be consumed by 248 external systems. External systems can be provisioning systems, 249 service orchestrators, Operations Support Systems, Business Support 250 Systems and applications exposed to network service consumers, being 251 either internal network operations peole or extarnal customers. 252 These modules are commonly designed, developed and deployed by 253 network infrastructure teams. 255 YANG allows for different design patterns to describe network 256 services, ranging from monolithic to component-based approaches. 258 The monolithic approach captures the entire service in a single 259 module and does not put focus on reusability of internal data 260 definitions and groupings. The monolithic approach has the 261 advantages of single-purpose development including speed at the 262 expense of reusability. 264 The component-based approach captures device-centric features (e.g. 265 the definition of a VRF, routing protocols, or packet filtering) in a 266 vendor-independent manner. The components are designed for reuse 267 across many service modules. The set of components required for a 268 specific service is then composed into the higher-level service. The 269 component-based approach has the advantages of modular development 270 including a higher degree of reusability at the expense of initial 271 speed. 273 As an example, an L2VPN service can be built on many different types 274 of transport network technologies, including e.g. MPLS or carrier 275 ethernet. A component-based approach would allow for reuse of e.g. 276 UNI-interface definitions independent of the underlying transport 277 network (e.g. MEF UNI interface or MPLS interface). The monolithic 278 approach would assume a specific set of transport technologies and 279 interface definitions. 281 Another example for a network service model is [RFC8049]. Although 282 it provides information that can be used to achieve customer service 283 service level agreement, which is more then network service module 284 classification describes in this document, it provides an abstract 285 model for Layer 3 IP VPN service configuration which is a good 286 network service model. This module includes e.g. the concept of a 287 'site-network-access' to represent bearer and connection parameters. 288 An orchestrator receives operations on service instances according to 289 the service module and decomposes the data into specific Network 290 Element YANG Modules to configure the participating network elements 291 to the service. In the case of the L3VPN module, this would include 292 translating the 'site-network-access' parameters to the appropriate 293 parameters in the Network Element YANG Module implemented on the 294 constituent elements. 296 2.2. Network Element YANG Modules 298 Network Element YANG Modules describe the characteristics of a 299 network device as defined by the vendor of that device. The modules 300 are commonly structured around features of the device, e.g. interface 301 configuration [RFC7223], OSPF configuration [I-D.ietf-ospf-yang], and 302 firewall rules definitions [I-D.ietf-netmod-acl-model]. 304 Although the [RFC7950], [RFC7950] doesn't explain the relationship of 305 the terms '(YANG) data model' and '(YANG) module', the authors 306 understand there is a 1:1 relationship between a data model and a 307 YANG module, but a data model may also be expressed using a 308 collection of YANG modules (and submodules). The module provides a 309 coherent data model representation of the software environment 310 consisting of the operating system and applications running on the 311 device. The decomposition, ordering, and execution of changes to the 312 operating system and application configuration is the task of the 313 agent that implements the module. 315 3. Second Dimension: Module Types 317 This document suggests classifying YANG module types as standard YANG 318 modules, vendor-specific YANG modules and extensions, or user- 319 specific YANG modules and extensions 321 The suggested classification applies to both Network Element YANG 322 Modules and Network Service YANG Modules. 324 It is to be expected that real-world implementations of both Network 325 Service YANG Modules and Network Element YANG Modules will include a 326 mix of all three types of modules. 328 Figure 2 illustrates the relationship between the three types of 329 modules. 331 +--------------+ 332 | User | 333 | Extensions | 334 +------+-------+ 335 Augments 336 +------+-------+ +--------------+ +--------------+ 337 | Vendor | | User | | User | 338 | Extensions | | Extensions | | Extensions | 339 +------+-------+ +------+-------+ +------+-------+ 340 Augments Augments Augments 341 +------+-----------------+-------+ +------+-------+ +--------------+ 342 | Standard | | Vendor | | User | 343 | Modules | | Modules | | Modules | 344 +--------------------------------+ +--------------+ +--------------+ 346 Figure 2: YANG Module Types 348 3.1. Standard YANG Modules 350 Standard YANG Modules are published by standards-defining 351 organizations (SDOs). While there is no formal definition of what 352 construes an SDO, a common feature is that they publish 353 specifications along specific processes with content that reflects 354 some sort of membership consensus. The specifications are developed 355 for wide use among the membership or for audiences beyond that. 357 The lifecycle of these modules is driven by the editing cycle of the 358 specification and not tied to a specific implementation. 360 Examples of SDOs in the networking industry are the IETF, the IEEE 361 and the MEF. 363 3.2. Vendor-specific YANG Modules and Extensions 365 Vendor-specific YANG Modules are developed by organizations with the 366 intent to support a specific set of implementations under control of 367 that organization. For example vendors of virtual or physical 368 equipment, industry consortia, and opensource projects. The intent 369 of these modules range from providing openly published YANG modules 370 that may eventually be contributed back to, or adopted by, an SDO, to 371 strictly internal YANG modules not intended for external consumption. 373 The lifecycle of these modules are generally aligned with the release 374 cycle of the product or open source software project deliverables. 376 It is worth noting that there is an increasing amount of interaction 377 between open source projects and SDOs in the networking industry. 378 This includes open source projects implementing published standards 379 as well as open source projects contributing content to SDO 380 processes. 382 Vendors also develop Vendor-specific Extensions to standard modules 383 using YANG constructs for extending data definitions of previously 384 published modules. This is done using the 'augment' statement that 385 allows locally defined data trees to be augmented into locations in 386 externally defined data trees. 388 Vendors use this to extend standard modules to cover the full scope 389 of features in implementations, which commonly is broader than that 390 covered by the standard module. 392 3.3. User-specific YANG Modules and Extensions 394 User-specific YANG Modules are developed by organizations that 395 operate YANG-based infrastructure including devices and 396 orchestrators. For example, network administrators in enterprises, 397 or at service providers. The intent of these modules is to express 398 the specific needs for a certain implementation, above and beyond 399 what is provided by vendors. 401 This module type obviously requires the infrastructure to support the 402 introduction of user-provided modules and extensions. This would 403 include ability to describe the service-to-network decomposition in 404 orchestrators and the module to configuration decomposition in 405 devices. 407 The lifecycles of these modules are generally aligned with the change 408 cadence of the infrastructure. 410 4. Security Considerations 412 This document doesn't have any Security Considerations. 414 5. IANA Considerations 416 This document has no IANA actions. 418 6. Acknowledgements 420 Thanks to David Ball and David Hansford for feedback and suggestions. 422 7. Change log [RFC Editor: Please remove] 424 version 00: Renamed and small fixes based on WG feedback. 426 version 01: Language fixes, collapsing of vendor data models and 427 extensions, and the introduction of user data models and extensions. 429 version 02: Updated the YANG Module Catalog section, terminology 430 alignment (YANG data model versus YANG module), explain better the 431 distinction between the Network Element and Service YANG data models 432 even if sometimes there are grey areas, editorial pass. Changed the 433 use of the term 'model' to 'module' to be better aligned with 434 RFC6020. 436 version 06: updates based on comments from Adrian Farrel about YANG 437 Data Model for L3VPN Service Delivery. 439 8. References 441 8.1. Normative References 443 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 444 and A. Bierman, Ed., "Network Configuration Protocol 445 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 446 . 448 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 449 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 450 . 452 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 453 RFC 7950, DOI 10.17487/RFC7950, August 2016, 454 . 456 [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 457 Model for L3VPN Service Delivery", RFC 8049, DOI 10.17487/ 458 RFC8049, February 2017, 459 . 461 8.2. Informative References 463 [I-D.ietf-netmod-acl-model] 464 Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, 465 "Network Access Control List (ACL) YANG Data Model", 466 draft-ietf-netmod-acl-model-10 (work in progress), March 467 2017. 469 [I-D.ietf-ospf-yang] 470 Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, 471 "Yang Data Model for OSPF Protocol", draft-ietf-ospf- 472 yang-07 (work in progress), March 2017. 474 [Writable-MIB-Module-IESG-Statement] 475 "Writable MIB Module IESG Statement", 476 . 479 Authors' Addresses 481 Dean Bogdanovic 482 Volta Networks, Inc. 484 Email: dean@voltanet.io 486 Benoit Claise 487 Cisco Systems, Inc. 488 De Kleetlaan 6a b1 489 1831 Diegem 490 Belgium 492 Phone: +32 2 704 5622 493 Email: bclaise@cisco.com 495 Carl Moberg 496 Cisco Systems, Inc. 498 Email: camoberg@cisco.com