idnits 2.17.1 draft-ietf-netmod-yang-model-classification-05.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 (March 13, 2017) is 2598 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-10 == Outdated reference: A later version (-29) exists of draft-ietf-ospf-yang-06 Summary: 1 error (**), 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: September 14, 2017 C. Moberg 6 Cisco Systems, Inc. 7 March 13, 2017 9 YANG Module Classification 10 draft-ietf-netmod-yang-model-classification-05 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 September 14, 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 . . . . . . . . . . . . . . . . . . . . . . 9 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 As an example, the Network Service YANG Module defined in 248 [draft-ietf-l3sm-l3vpn-service-model] provides an abstract model for 249 Layer 3 IP VPN service configuration. This module includes e.g. the 250 concept of a 'site-network-access' to represent bearer and connection 251 parameters. An orchestrator receives operations on service instances 252 according to the service module and decomposes the data into specific 253 Network Element YANG Modules to configure the participating network 254 elements to the service. In the case of the L3VPN module, this would 255 include translating the 'site-network-access' parameters to the 256 appropriate parameters in the Network Element YANG Module implemented 257 on the constituent elements. 259 Network Service YANG Modules define service models to be consumed by 260 external systems. External systems can be provisioning systems, 261 service orchestrators, Operations Support Systems, Business Support 262 Systems and applications exposed to network service consumers, being 263 either internal network operations peole or extarnal customers. 264 These modules are commonly designed, developed and deployed by 265 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 characteristics of a 296 network device as defined by the vendor of that device. The modules 297 are commonly structured around features of the device, e.g. interface 298 configuration [RFC7223], OSPF configuration [I-D.ietf-ospf-yang], and 299 firewall rules definitions [I-D.ietf-netmod-acl-model]. 301 Although the [RFC7950], [RFC7950] doesn't explain the relationship of 302 the terms '(YANG) data model' and '(YANG) module', the authors 303 understand there is a 1:1 relationship between a data model and a 304 YANG module, but a data model may also be expressed using a 305 collection of YANG modules (and submodules). The module provides a 306 coherent data model representation of the software environment 307 consisting of the operating system and applications running on the 308 device. The decomposition, ordering, and execution of changes to the 309 operating system and application configuration is the task of the 310 agent that implements the module. 312 3. Second Dimension: Module Types 314 This document suggests classifying YANG module types as standard YANG 315 modules, vendor-specific YANG modules and extensions, or user- 316 specific YANG modules and extensions 318 The suggested classification applies to both Network Element YANG 319 Modules and Network Service YANG Modules. 321 It is to be expected that real-world implementations of both Network 322 Service YANG Modules and Network Element YANG Modules will include a 323 mix of all three types of modules. 325 Figure 2 illustrates the relationship between the three types of 326 modules. 328 +--------------+ 329 | User | 330 | Extensions | 331 +------+-------+ 332 Augments 333 +------+-------+ +--------------+ +--------------+ 334 | Vendor | | User | | User | 335 | Extensions | | Extensions | | Extensions | 336 +------+-------+ +------+-------+ +------+-------+ 337 Augments Augments Augments 338 +------+-----------------+-------+ +------+-------+ +--------------+ 339 | Standard | | Vendor | | User | 340 | Modules | | Modules | | Modules | 341 +--------------------------------+ +--------------+ +--------------+ 343 Figure 2: YANG Module Types 345 3.1. Standard YANG Modules 347 Standard YANG Modules are published by standards-defining 348 organizations (SDOs). While there is no formal definition of what 349 construes an SDO, a common feature is that they publish 350 specifications along specific processes with content that reflects 351 some sort of membership consensus. The specifications are developed 352 for wide use among the membership or for audiences beyond that. 354 The lifecycle of these modules is driven by the editing cycle of the 355 specification and not tied to a specific implementation. 357 Examples of SDOs in the networking industry are the IETF, the IEEE 358 and the MEF. 360 3.2. Vendor-specific YANG Modules and Extensions 362 Vendor-specific YANG Modules are developed by organizations with the 363 intent to support a specific set of implementations under control of 364 that organization. For example vendors of virtual or physical 365 equipment, industry consortia, and opensource projects. The intent 366 of these modules range from providing openly published YANG modules 367 that may eventually be contributed back to, or adopted by, an SDO, to 368 strictly internal YANG modules not intended for external consumption. 370 The lifecycle of these modules are generally aligned with the release 371 cycle of the product or open source software project deliverables. 373 It is worth noting that there is an increasing amount of interaction 374 between open source projects and SDOs in the networking industry. 375 This includes open source projects implementing published standards 376 as well as open source projects contributing content to SDO 377 processes. 379 Vendors also develop Vendor-specific Extensions to standard modules 380 using YANG constructs for extending data definitions of previously 381 published modules. This is done using the 'augment' statement that 382 allows locally defined data trees to be augmented into locations in 383 externally defined data trees. 385 Vendors use this to extend standard modules to cover the full scope 386 of features in implementations, which commonly is broader than that 387 covered by the standard module. 389 3.3. User-specific YANG Modules and Extensions 391 User-specific YANG Modules are developed by organizations that 392 operate YANG-based infrastructure including devices and 393 orchestrators. For example, network administrators in enterprises, 394 or at service providers. The intent of these modules is to express 395 the specific needs for a certain implementation, above and beyond 396 what is provided by vendors. 398 This module type obviously requires the infrastructure to support the 399 introduction of user-provided modules and extensions. This would 400 include ability to describe the service-to-network decomposition in 401 orchestrators and the module to configuration decomposition in 402 devices. 404 The lifecycles of these modules are generally aligned with the change 405 cadence of the infrastructure. 407 4. Security Considerations 409 This document doesn't have any Security Considerations. 411 5. IANA Considerations 413 This document has no IANA actions. 415 6. Acknowledgements 417 Thanks to David Ball and David Hansford for feedback and suggestions. 419 7. Change log [RFC Editor: Please remove] 421 version 00: Renamed and small fixes based on WG feedback. 423 version 01: Language fixes, collapsing of vendor data models and 424 extensions, and the introduction of user data models and extensions. 426 version 02: Updated the YANG Module Catalog section, terminology 427 alignment (YANG data model versus YANG module), explain better the 428 distinction between the Network Element and Service YANG data models 429 even if sometimes there are grey areas, editorial pass. Changed the 430 use of the term 'model' to 'module' to be better aligned with 431 RFC6020. 433 8. References 435 8.1. Normative References 437 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 438 and A. Bierman, Ed., "Network Configuration Protocol 439 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 440 . 442 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 443 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 444 . 446 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 447 RFC 7950, DOI 10.17487/RFC7950, August 2016, 448 . 450 8.2. Informative References 452 [draft-ietf-l3sm-l3vpn-service-model] 453 "YANG Data Model for L3VPN service delivery", 454 . 457 [I-D.ietf-netmod-acl-model] 458 Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, 459 "Network Access Control List (ACL) YANG Data Model", 460 draft-ietf-netmod-acl-model-10 (work in progress), March 461 2017. 463 [I-D.ietf-ospf-yang] 464 Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, 465 "Yang Data Model for OSPF Protocol", draft-ietf-ospf- 466 yang-06 (work in progress), October 2016. 468 [Writable-MIB-Module-IESG-Statement] 469 "Writable MIB Module IESG Statement", 470 . 473 Authors' Addresses 475 Dean Bogdanovic 476 Volta Networks, Inc. 478 Email: dean@voltanet.io 480 Benoit Claise 481 Cisco Systems, Inc. 482 De Kleetlaan 6a b1 483 1831 Diegem 484 Belgium 486 Phone: +32 2 704 5622 487 Email: bclaise@cisco.com 489 Carl Moberg 490 Cisco Systems, Inc. 492 Email: camoberg@cisco.com