idnits 2.17.1 draft-ietf-netmod-yang-model-classification-08.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 (June 13, 2017) is 2501 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: December 15, 2017 C. Moberg 6 Cisco Systems, Inc. 7 June 13, 2017 9 YANG Module Classification 10 draft-ietf-netmod-yang-model-classification-08 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 development 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 December 15, 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 Origin Types . . . . . . . . . . . . 7 70 3.1. Standard YANG Modules . . . . . . . . . . . . . . . . . . 8 71 3.2. Vendor-specific YANG Modules and Extensions . . . . . . . 8 72 3.3. User-specific YANG Modules and Extensions . . . . . . . . 9 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 76 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 9 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 8.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 The Internet Engineering Steering Group (IESG) has been actively 85 encouraging IETF working groups to use the YANG 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 module origin type based on the nature and intent of the 108 content 110 The intent of this document is to provide a taxonomy to simplify 111 human communication around YANG modules. While the classification 112 boundaries are at times blurry, this document should provide a robust 113 starting point as the YANG community gains further experience with 114 designing and deploying modules. To be more explicit, it is expected 115 that the classification criteria will change over time. 117 A number of modules have created substantial discussion during the 118 development of this document: for examples, modules 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 abstraction layers 132 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 a network operator. Alternatively, 139 it 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. 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. This document 169 considers both bottom-up and top-down approaches as they are both 170 used and they each provide benefits that appeal to different groups. 172 For layering purposes, this document suggests the classification of 173 YANG modules into two distinct abstraction layers: 175 o Network Element YANG Modules describe the configuration, state 176 data, operations and notifications of specific device-centric 177 technologies or features 179 o Network Service YANG Modules describe the configuration, state 180 data, operations and notifications of abstract representations of 181 services implemented on one or multiple network elements 182 +--------------------------+ 183 | Operations and Business | 184 | Support Systems | 185 | (OSS/BSS) | 186 +--------------------------+ 188 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 189 Network Service YANG Modules 191 +------------+ +-------------+ +-------------+ 192 | | | | | | 193 | - L2VPN | | - L2VPN | | L3VPN | 194 | - VPWS | | - VPLS | | | 195 | | | | | | 196 +------------+ +-------------+ +-------------+ 198 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 199 Network Element YANG Modules 201 +------------+ +------------+ +-------------+ +------------+ 202 | | | | | | | | 203 | MPLS | | BGP | | IPv4 / IPv6 | | Ethernet | 204 | | | | | | | | 205 +------------+ +------------+ +-------------+ +------------+ 207 L2VPN: Layer 2 Virtual Private Network 208 L3VPN: Layer 3 Virtual Private Network 209 VPWS: Virtual Private Wire Service 210 VPLS: Virtual Private LAN Service 212 Figure 1: YANG Module Abstraction Layers 214 Figure 1 illustrates the application of YANG modules at different 215 layers of abstraction. Layering of modules allows for reusability of 216 existing lower layer modules by higher level modules while limiting 217 duplication of features across layers. 219 For module developers, per-layer modeling allows for separation of 220 concern across editing teams focusing on specific areas. 222 As an example, experience from the IETF shows that creating useful 223 Network Element YANG modules for e.g. routing or switching protocols 224 requires teams that include developers with experience of 225 implementing those protocols. 227 On the other hand, Network Service YANG modules are best developed by 228 network operators experienced in defining network services for 229 consumption by programmers developing e.g. flow-through provisioning 230 systems or self-service portals. 232 2.1. Network Service YANG Modules 234 Network Service YANG Modules describe the characteristics of a 235 service, as agreed upon with consumers of that service. That is, a 236 service module does not expose the detailed configuration parameters 237 of all participating network elements and features, but describes an 238 abstract model that allows instances of the service to be decomposed 239 into instance data according to the Network Element YANG Modules of 240 the participating network elements. The service-to-element 241 decomposition is a separate process with details depending on how the 242 network operator chooses to realize the service. For the purpose of 243 this document, the term "orchestrator" is used to describe to 244 describe a system implementing such a process. 246 Network Service YANG Modules define service models to be consumed by 247 external systems. External systems can be provisioning systems, 248 service orchestrators, Operations Support Systems, Business Support 249 Systems and applications exposed to network service consumers, being 250 either internal network operations people or external customers. 251 These modules are commonly designed, developed and deployed by 252 network infrastructure teams. 254 YANG allows for different design patterns to describe network 255 services, ranging from monolithic to component-based approaches. 257 The monolithic approach captures the entire service in a single 258 module and does not put focus on reusability of internal data 259 definitions and groupings. The monolithic approach has the 260 advantages of single-purpose development including development speed 261 at the expense of reusability. 263 The component-based approach captures device-centric features (e.g. 264 the definition of a VPN Routing and Forwarding (VRF), routing 265 protocols, or packet filtering) in a vendor-independent manner. The 266 components are designed for reuse across many service modules. The 267 set of components required for a specific service is then composed 268 into the higher-level service. The component-based approach has the 269 advantages of modular development including a higher degree of 270 reusability at the expense of initial development speed. 272 As an example, an L2VPN service can be built on many different types 273 of transport network technologies, including e.g. MPLS or carrier 274 ethernet. A component-based approach would allow for reuse of e.g. 275 User-Network Interface (UNI) definitions independent of the 276 underlying transport network (e.g. MEF UNI interface or MPLS 277 interface). The monolithic approach would assume a specific set of 278 transport technologies and interface definitions. 280 An example of a Network Service YANG module is in [RFC8049]. It 281 provides an abstract model for Layer 3 IP VPN service configuration. 282 This module includes e.g. the concept of a 'site-network-access' to 283 represent bearer and connection parameters. An orchestrator receives 284 operations on service instances according to the service module and 285 decomposes the data into configuration data according to specific 286 Network Element YANG Modules to configure the participating network 287 elements to the service. In the case of the L3VPN module, this would 288 include translating the 'site-network-access' parameters to the 289 appropriate parameters in the Network Element YANG Module implemented 290 on the constituent elements. 292 2.2. Network Element YANG Modules 294 Network Element YANG Modules describe the characteristics of a 295 network device as defined by the vendor of that device. The modules 296 are commonly structured around features of the device, e.g. interface 297 configuration [RFC7223], OSPF configuration [I-D.ietf-ospf-yang], and 298 firewall rules definitions [I-D.ietf-netmod-acl-model]. 300 The module provides a coherent data model representation of the 301 software environment consisting of the operating system and 302 applications running on the device. The decomposition, ordering, and 303 execution of changes to the operating system and application 304 configuration is the task of the agent that implements the module. 306 3. Second Dimension: Module Origin Types 308 This document suggests classifying YANG module origin types as 309 standard YANG modules, vendor-specific YANG modules and extensions, 310 or user-specific YANG modules and extensions 312 The suggested classification applies to both Network Element YANG 313 Modules and Network Service YANG Modules. 315 It is to be expected that real-world implementations of both Network 316 Service YANG Modules and Network Element YANG Modules will include a 317 mix of all three module origin types. 319 Figure 2 illustrates the relationship between the three types of 320 modules. 322 +--------------+ 323 | User | 324 | Extensions | 325 +------+-------+ 326 Augments 327 +------+-------+ +--------------+ +--------------+ 328 | Vendor | | User | | User | 329 | Extensions | | Extensions | | Extensions | 330 +------+-------+ +------+-------+ +------+-------+ 331 Augments Augments Augments 332 +------+-----------------+-------+ +------+-------+ +--------------+ 333 | Standard | | Vendor | | User | 334 | Modules | | Modules | | Modules | 335 +--------------------------------+ +--------------+ +--------------+ 337 Figure 2: YANG Module Origin Types 339 3.1. Standard YANG Modules 341 Standard YANG Modules are published by standards development 342 organizations (SDOs). Most SDOs create specifications according to a 343 formal process in order to produce a standard that is useful for 344 their constituencies. 346 The lifecycle of these modules is driven by the editing cycle of the 347 specification and not tied to a specific implementation. 349 Examples of SDOs in the networking industry are the IETF and the 350 IEEE. 352 3.2. Vendor-specific YANG Modules and Extensions 354 Vendor-specific YANG Modules are developed by organizations with the 355 intent to support a specific set of implementations under control of 356 that organization. For example vendors of virtual or physical 357 equipment, industry consortia, and opensource projects. The intent 358 of these modules range from providing openly published YANG modules 359 that may eventually be contributed back to, or adopted by, an SDO, to 360 strictly internal YANG modules not intended for external consumption. 362 The lifecycle of these modules are generally aligned with the release 363 cycle of the product or open source software project deliverables. 365 It is worth noting that there is an increasing amount of interaction 366 between open source projects and SDOs in the networking industry. 367 This includes open source projects implementing published standards 368 as well as open source projects contributing content to SDO 369 processes. 371 Vendors also develop Vendor-specific Extensions to standard modules 372 using YANG constructs for extending data definitions of previously 373 published modules. This is done using the 'augment' statement that 374 allows locally defined data trees to be added into locations in 375 externally defined data trees. 377 Vendors use this to extend standard modules to cover the full scope 378 of features in implementations, which commonly is broader than that 379 covered by the standard module. 381 3.3. User-specific YANG Modules and Extensions 383 User-specific YANG Modules are developed by organizations that 384 operate YANG-based infrastructure including devices and 385 orchestrators. For example, network administrators in enterprises, 386 or at service providers. The intent of these modules is to express 387 the specific needs for a certain implementation, above and beyond 388 what is provided by vendors. 390 This module type obviously requires the infrastructure to support the 391 introduction of user-provided modules and extensions. This would 392 include the ability to describe the service-to-network decomposition 393 in orchestrators and the module to configuration decomposition in 394 devices. 396 The lifecycles of these modules are generally aligned with the change 397 cadence of the infrastructure. 399 4. Security Considerations 401 This document doesn't have any Security Considerations. 403 5. IANA Considerations 405 This document has no IANA actions. 407 6. Acknowledgements 409 Thanks to David Ball and Jonathen Hansford for feedback and 410 suggestions. 412 7. Change log [RFC Editor: Please remove] 414 version 00: Renamed and small fixes based on WG feedback. 416 version 01: Language fixes, collapsing of vendor data models and 417 extensions, and the introduction of user data models and extensions. 419 version 02: Updated the YANG Module Catalog section, terminology 420 alignment (YANG data model versus YANG module), explain better the 421 distinction between the Network Element and Service YANG data models 422 even if sometimes there are grey areas, editorial pass. Changed the 423 use of the term 'model' to 'module' to be better aligned with 424 RFC6020. 426 version 06: updates based on comments from Adrian Farrel about YANG 427 Data Model for L3VPN Service Delivery. 429 version 07: updates based on comments from Pete Resnick 431 8. References 433 8.1. Normative References 435 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 436 and A. Bierman, Ed., "Network Configuration Protocol 437 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 438 . 440 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 441 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 442 . 444 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 445 RFC 7950, DOI 10.17487/RFC7950, August 2016, 446 . 448 [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 449 Model for L3VPN Service Delivery", RFC 8049, 450 DOI 10.17487/RFC8049, February 2017, 451 . 453 8.2. Informative References 455 [I-D.ietf-netmod-acl-model] 456 Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, 457 "Network Access Control List (ACL) YANG Data Model", 458 draft-ietf-netmod-acl-model-10 (work in progress), March 459 2017. 461 [I-D.ietf-ospf-yang] 462 Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, 463 "Yang Data Model for OSPF Protocol", draft-ietf-ospf- 464 yang-07 (work in progress), March 2017. 466 [Writable-MIB-Module-IESG-Statement] 467 "Writable MIB Module IESG Statement", 468 . 471 Authors' Addresses 473 Dean Bogdanovic 474 Volta Networks, Inc. 476 Email: dean@voltanet.io 478 Benoit Claise 479 Cisco Systems, Inc. 480 De Kleetlaan 6a b1 481 1831 Diegem 482 Belgium 484 Phone: +32 2 704 5622 485 Email: bclaise@cisco.com 487 Carl Moberg 488 Cisco Systems, Inc. 490 Email: camoberg@cisco.com