idnits 2.17.1 draft-ietf-netmod-yang-model-classification-07.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 (May 16, 2017) is 2537 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: November 17, 2017 C. Moberg 6 Cisco Systems, Inc. 7 May 16, 2017 9 YANG Module Classification 10 draft-ietf-netmod-yang-model-classification-07 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 November 17, 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] . . . . . . . . . . . 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 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. While the classification 111 boundaries are at times blurry, this document should provide a robust 112 starting point as the YANG community gains further experience with 113 designing and deploying modules. To be more explicit, it is expected 114 that the classification criteria will change over time. 116 A number of module types have created substantial discussion during 117 the development of this document including those concerned with 118 topologies. Topology modules are useful both on the Network Element 119 level (e.g. link-state database content) as well as on the Network 120 Service level (e.g. network-wide, configured topologies). In the 121 end, it is the module developer that classifies the module according 122 to the initial intent of the module content. 124 This document should provide benefits to multiple audiences: 126 o First, a common taxonomy helps with the different standards 127 development organizations and industry consortia discussions, 128 whose goals are determined in their respective areas of work. 130 o Second, operators might look at the YANG module classification 131 type to understand which Network Service YANG modules and Network 132 Element YANG modules are available for their service composition. 133 It is difficult to determine the module type without inspecting 134 the YANG module itself. The YANG module name might provide some 135 useful information but is not a definite answer. For example, an 136 L2VPN YANG module might be a Network Service YANG module, ready to 137 be used as a service model by a network operator. Alternatively, 138 it might be a Network Element YANG module that contains the L2VPN 139 data definitions required to be configured on a single device. 141 o And thirdly, this taxonomy would help equipment vendors (whether 142 physical or virtual), controller vendors, orchestrator vendors to 143 explain to their customers the relationship between the different 144 YANG modules they support in their products. See Figure 1. 146 1.1. Terminology 148 [RFC7950] specifies: 150 o data model: A data model describes how data is represented and 151 accessed. 153 o module: A YANG module defines hierarchies of schema nodes. With 154 its definitions and the definitions it imports or includes from 155 elsewhere, a module is self-contained and "compilable". 157 2. First Dimension: YANG Module Abstraction Layers 159 Module developers have taken two approaches to developing YANG 160 modules: top-down and bottom-up. The top-down approach starts with 161 high level abstractions modeling business or customer requirements 162 and maps them to specific networking technologies. The bottom-up 163 approach starts with fundamental networking technologies and maps 164 them into more abstract constructs. 166 There are currently no specific requirements on, or well-defined best 167 practices around the development of YANG modules. This document 168 considers both bottom-up and top-down approaches as they are both 169 used and they each provide benefits that appeal to different groups. 171 For layering purposes, this document suggests the classification of 172 YANG modules into two distinct abstraction layers: 174 o Network Element YANG Modules describe the configuration, state 175 data, operations and notifications of specific device-centric 176 technologies or features 178 o Network Service YANG Modules describe the configuration, state 179 data, operations and notifications of abstract representations of 180 services implemented on one or multiple network elements 181 +--------------------------+ 182 | Operations and Business | 183 | Support Systems | 184 | (OSS/BSS) | 185 +--------------------------+ 187 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 188 Network Service YANG Modules 190 +------------+ +-------------+ +-------------+ 191 | | | | | | 192 | - L2VPN | | - L2VPN | | L3VPN | 193 | - VPWS | | - VPLS | | | 194 | | | | | | 195 +------------+ +-------------+ +-------------+ 197 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 198 Network Element YANG Modules 200 +------------+ +------------+ +-------------+ +------------+ 201 | | | | | | | | 202 | MPLS | | BGP | | IPv4 / IPv6 | | Ethernet | 203 | | | | | | | | 204 +------------+ +------------+ +-------------+ +------------+ 206 L2VPN: Layer 2 Virtual Private Network 207 L3VPN: Layer 3 Virtual Private Network 208 VPWS: Virtual Private Wire Service 209 VPLS: Virtual Private LAN Service 211 Figure 1: YANG Module Layers 213 Figure 1 illustrates the application of YANG modules at different 214 layers of abstraction. Layering of modules allows for reusability of 215 existing lower layer modules by higher level modules while limiting 216 duplication of features across layers. 218 For module developers, per-layer modeling allows for separation of 219 concern across editing teams focusing on specific areas. 221 As an example, experience from the IETF shows that creating useful 222 network element YANG modules for e.g. routing or switching protocols 223 requires teams that include developers with experience of 224 implementing those protocols. 226 On the other hand, network service YANG modules are best developed by 227 network operators experienced in defining network services for 228 consumption by programmers developing e.g. flow-through provisioning 229 systems or self-service portals. 231 2.1. Network Service YANG Modules 233 Network Service YANG Modules describe the characteristics of a 234 service, as agreed upon with consumers of that service. That is, a 235 service module does not expose the detailed configuration parameters 236 of all participating network elements and features, but describes an 237 abstract model that allows instances of the service to be decomposed 238 into instance data according to the Network Element YANG Modules of 239 the participating network elements. The service-to-element 240 decomposition is a separate process with details depending on how the 241 network operator chooses to realize the service. For the purpose of 242 this document, the term "orchestrator" is used to describe to 243 describe a system implementing such a process. 245 Network Service YANG Modules define service models to be consumed by 246 external systems. External systems can be provisioning systems, 247 service orchestrators, Operations Support Systems, Business Support 248 Systems and applications exposed to network service consumers, being 249 either internal network operations people or external customers. 250 These modules are commonly designed, developed and deployed by 251 network infrastructure teams. 253 YANG allows for different design patterns to describe network 254 services, ranging from monolithic to component-based approaches. 256 The monolithic approach captures the entire service in a single 257 module and does not put focus on reusability of internal data 258 definitions and groupings. The monolithic approach has the 259 advantages of single-purpose development including development speed 260 at the expense of reusability. 262 The component-based approach captures device-centric features (e.g. 263 the definition of a VRF, routing protocols, or packet filtering) in a 264 vendor-independent manner. The components are designed for reuse 265 across many service modules. The set of components required for a 266 specific service is then composed into the higher-level service. The 267 component-based approach has the advantages of modular development 268 including a higher degree of reusability at the expense of initial 269 development speed. 271 As an example, an L2VPN service can be built on many different types 272 of transport network technologies, including e.g. MPLS or carrier 273 ethernet. A component-based approach would allow for reuse of e.g. 274 UNI-interface definitions independent of the underlying transport 275 network (e.g. MEF UNI interface or MPLS interface). The monolithic 276 approach would assume a specific set of transport technologies and 277 interface definitions. 279 An example of a network service module is in [RFC8049]. It provides 280 an abstract model for Layer 3 IP VPN service configuration. This 281 module includes e.g. the concept of a 'site-network-access' to 282 represent bearer and connection parameters. An orchestrator receives 283 operations on service instances according to the service module and 284 decomposes the data into configuration data according to specific 285 Network Element YANG Modules to configure the participating network 286 elements to the service. In the case of the L3VPN module, this would 287 include translating the 'site-network-access' parameters to the 288 appropriate parameters in the Network Element YANG Module implemented 289 on the constituent elements. 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 development 341 organizations (SDOs). Most SDOs create specifications according to a 342 formal process in order to produce a standard that is useful for 343 their constituencies. 345 The lifecycle of these modules is driven by the editing cycle of the 346 specification and not tied to a specific implementation. 348 Examples of SDOs in the networking industry are the IETF, the IEEE 349 and the MEF. 351 3.2. Vendor-specific YANG Modules and Extensions 353 Vendor-specific YANG Modules are developed by organizations with the 354 intent to support a specific set of implementations under control of 355 that organization. For example vendors of virtual or physical 356 equipment, industry consortia, and opensource projects. The intent 357 of these modules range from providing openly published YANG modules 358 that may eventually be contributed back to, or adopted by, an SDO, to 359 strictly internal YANG modules not intended for external consumption. 361 The lifecycle of these modules are generally aligned with the release 362 cycle of the product or open source software project deliverables. 364 It is worth noting that there is an increasing amount of interaction 365 between open source projects and SDOs in the networking industry. 366 This includes open source projects implementing published standards 367 as well as open source projects contributing content to SDO 368 processes. 370 Vendors also develop Vendor-specific Extensions to standard modules 371 using YANG constructs for extending data definitions of previously 372 published modules. This is done using the 'augment' statement that 373 allows locally defined data trees to be added into locations in 374 externally defined data trees. 376 Vendors use this to extend standard modules to cover the full scope 377 of features in implementations, which commonly is broader than that 378 covered by the standard module. 380 3.3. User-specific YANG Modules and Extensions 382 User-specific YANG Modules are developed by organizations that 383 operate YANG-based infrastructure including devices and 384 orchestrators. For example, network administrators in enterprises, 385 or at service providers. The intent of these modules is to express 386 the specific needs for a certain implementation, above and beyond 387 what is provided by vendors. 389 This module type obviously requires the infrastructure to support the 390 introduction of user-provided modules and extensions. This would 391 include the ability to describe the service-to-network decomposition 392 in orchestrators and the module to configuration decomposition in 393 devices. 395 The lifecycles of these modules are generally aligned with the change 396 cadence of the infrastructure. 398 4. Security Considerations 400 This document doesn't have any Security Considerations. 402 5. IANA Considerations 404 This document has no IANA actions. 406 6. Acknowledgements 408 Thanks to David Ball and Jonathen Hansford for feedback and 409 suggestions. 411 7. Change log [RFC Editor: Please remove] 413 version 00: Renamed and small fixes based on WG feedback. 415 version 01: Language fixes, collapsing of vendor data models and 416 extensions, and the introduction of user data models and extensions. 418 version 02: Updated the YANG Module Catalog section, terminology 419 alignment (YANG data model versus YANG module), explain better the 420 distinction between the Network Element and Service YANG data models 421 even if sometimes there are grey areas, editorial pass. Changed the 422 use of the term 'model' to 'module' to be better aligned with 423 RFC6020. 425 version 06: updates based on comments from Adrian Farrel about YANG 426 Data Model for L3VPN Service Delivery. 428 version 07: updates based on comments from Pete Resnick 430 8. References 432 8.1. Normative References 434 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 435 and A. Bierman, Ed., "Network Configuration Protocol 436 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 437 . 439 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 440 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 441 . 443 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 444 RFC 7950, DOI 10.17487/RFC7950, August 2016, 445 . 447 [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 448 Model for L3VPN Service Delivery", RFC 8049, 449 DOI 10.17487/RFC8049, February 2017, 450 . 452 8.2. Informative References 454 [I-D.ietf-netmod-acl-model] 455 Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, 456 "Network Access Control List (ACL) YANG Data Model", 457 draft-ietf-netmod-acl-model-10 (work in progress), March 458 2017. 460 [I-D.ietf-ospf-yang] 461 Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, 462 "Yang Data Model for OSPF Protocol", draft-ietf-ospf- 463 yang-07 (work in progress), March 2017. 465 [Writable-MIB-Module-IESG-Statement] 466 "Writable MIB Module IESG Statement", 467 . 470 Authors' Addresses 472 Dean Bogdanovic 473 Volta Networks, Inc. 475 Email: dean@voltanet.io 477 Benoit Claise 478 Cisco Systems, Inc. 479 De Kleetlaan 6a b1 480 1831 Diegem 481 Belgium 483 Phone: +32 2 704 5622 484 Email: bclaise@cisco.com 486 Carl Moberg 487 Cisco Systems, Inc. 489 Email: camoberg@cisco.com