idnits 2.17.1 draft-bogdanovic-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 : ---------------------------------------------------------------------------- ** 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 (October 17, 2015) is 3107 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-03 == Outdated reference: A later version (-29) exists of draft-ietf-ospf-yang-02 -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD D. Bogdanovic 3 Internet-Draft 4 Intended status: Informational B. Claise 5 Expires: April 19, 2016 C. Moberg 6 Cisco Systems, Inc. 7 October 17, 2015 9 YANG Model Classification 10 draft-bogdanovic-netmod-yang-model-classification-05 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 open source projects, and vendors are using YANG to develop and 18 publish models of configuration, state data and operations for a wide 19 variety of applications. At the same time, there is currently no 20 well-known terminology to categorize various types of YANG models. 22 A consistent terminology would help with the categorization of 23 models, assist in the analysis the YANG data modeling efforts in the 24 IETF and other organizations, and bring clarity to the YANG-related 25 discussions between the different groups. 27 This document describes a set of concepts and associated terms to 28 support consistent classification of YANG models. 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 19, 2016. 47 Copyright Notice 49 Copyright (c) 2015 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 2. First Dimension: YANG Model Abstraction Layers . . . . . . . 3 66 2.1. Network Service YANG Data Models . . . . . . . . . . . . 4 67 2.2. Network Element YANG Data models . . . . . . . . . . . . 5 68 3. Second Dimension: Model Types . . . . . . . . . . . . . . . . 6 69 3.1. Standard YANG Models . . . . . . . . . . . . . . . . . . 6 70 3.2. Vendor-specific YANG Models . . . . . . . . . . . . . . . 6 71 3.3. Vendor-specific Extensions . . . . . . . . . . . . . . . 7 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 75 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 7 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 78 8.2. Informative References . . . . . . . . . . . . . . . . . 8 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 81 1. Introduction 83 The Internet Engineering Steering Group (IESG) has been actively 84 encouraging IETF working groups to use the NETCONF [RFC6241] and YANG 85 standards for configuration management purposes, especially in new 86 working group charters [Writable-MIB-Module-IESG-Statement]. 88 YANG is also gaining wide acceptance as the de-facto standard 89 modeling language in the broader industry. This extends beyond the 90 IETF, including many standards development organizations, industry 91 consortia, ad hoc groups, open source projects and vendors. 93 There are currently no clear guidelines on how to classify the 94 layering of YANG models according to abstraction, or how to classify 95 models along the continuum spanning formal standards publications and 96 vendor-specific models. 98 This document presents a set of concepts and terms to form a useful 99 taxonomy for consistent classification of YANG models in two 100 dimensions: 102 o The layering of models based on their abstraction levels 104 o The type of model based on the nature and intent of the content 106 The two categories are covered in the next two sections. 108 2. First Dimension: YANG Model Abstraction Layers 110 Model developers have taken two approaches to developing YANG model: 111 top-down and bottom-up. The top-down approach starts with high level 112 abstractions modeling business or customer requirements and maps them 113 to specific networking technologies. The bottom-up approach starts 114 with fundamental networking technologies and maps them into more 115 abstract constructs. 117 There are currently no specific requirements on, or well-defined best 118 practices around the development of models. For the purpose of this 119 document we assume that both approaches (bottom-up and top-down) will 120 be used as they both provide benefits that appeals to different 121 groups. 123 For layering purposes, this documents suggests the classification of 124 data models into two distinct abstraction layers: 126 o Network Element YANG Models describe the configuration, state data 127 and operations of a specific device-centric technology or feature. 129 o Network Service YANG Models describes the configuration, state 130 data and operations of an abstract representation of a service 131 implemented on one or multiple network elements 133 Figure 1 illustrates the application of YANG models at different 134 layers of abstraction. Layering of models allow for reusability of 135 existing lower layer models by higher level models while limiting 136 duplication of features across layers. 138 For model developers, per-layer modeling allows for separation of 139 concern across editing teams focusing on specific areas. 141 As an example, experience from the IETF shows that creating useful 142 network element YANG models for e.g routing or switching protocols 143 requires teams that include developers with experience from 144 implementing those protocols. 146 On the other hand, network service models are best developed by 147 people experienced in defining network services for consumption by 148 programmers developing e.g. flow-through provisioning systems or 149 self-service portals. 151 +-----------------------+ 152 | | 153 | OSS/BSS | 154 | | 155 +-----------------------+ 157 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 158 Network Service YANG data models 160 +------------+ +-------------+ +-------------+ 161 | | | | | | 162 | - VPWS | | - VPLS | | L3VPN | 163 | - L2VPN | | - L2VPN | | | 164 | | | | | | 165 +------------+ +-------------+ +-------------+ 167 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 168 Network Element YANG data models 170 +------------+ +------------+ +-------------+ +------------+ 171 | | | | | | | | 172 | MPLS | | BGP | | IPv4 & IPv6 | | Ethernet | 173 | | | | | | | | 174 +------------+ +------------+ +-------------+ +------------+ 176 Fig. 1 YANG Model Layers 178 2.1. Network Service YANG Data Models 180 Network Service YANG Data Models describe the characteristics of a 181 service, as agreed upon with consumers of that service. That is, a 182 service model does not expose the detailed configuration parameters 183 of all participating network elements and features, but describes an 184 abstract model that allows instances of the service to be decomposed 185 into instance data according to the Network Element data models of 186 the participating network elements. The service-to-element 187 decomposition is a separate process with details depending on how the 188 network operator chooses to realize the service. 190 As an example, the Network Service model included in 191 [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstracted 192 model for Layer 3 IP VPN service configuration. An orchestrator 193 receives operations on service instances according to the service 194 model and decomposes the data into specific Network Element models to 195 configure the participating network elements to perform the intent of 196 the service. 198 Network Service YANG models defines services models to be consumed by 199 external systems. These models are commonly designed, developed and 200 deployed by network infrastructure teams. 202 YANG allows for different design patterns to describe network 203 services, ranging from monolithic to component-based approaches. 205 The monolithic approach captures the entire service in a single model 206 and does not put focus on reusability of internal data definitions 207 and groupings. The monolithic approach has the advantages of single- 208 purpose development including speed at the expense of reusability. 210 The component-based approach captures device-centric features (e.g. 211 the definition of a VRF, routing protocols, or packet filtering) in a 212 vendor-independent manner. The components are designed for reuse 213 across many services. The set of components required for a specific 214 service is then composed into the higher-level service. The 215 component-based approach has the advantages of modular development 216 including a higher degree of reusability at the expense of initial 217 speed. 219 As an example, an L2VPN service can be built on many different types 220 of transport network technologies, including e.g. MPLS or carrier 221 ethernet. A component-based approach would allow for reuse of e.g. 222 UNI-interface definitions independent of the underlying transport 223 network (e.g. MEF UNI interface or MPLS interface). The monolithic 224 approach would assume a specific set of transport technologies and 225 interface definitions. 227 2.2. Network Element YANG Data models 229 Network Element YANG Data Models describe the configuration, state 230 data and operations of a network device as defined by the vendor of 231 that device. The models are commonly structured around features of 232 the device, e.g. interface configuration [RFC7223], OSPF 233 configuration [I-D.ietf-ospf-yang], and firewall rules definitions 234 [I-D.ietf-netmod-acl-model]. The model provides a coherent data 235 model representation of what is commonly a very mixed software 236 environment consisting of the operating system and applications 237 running on the device. 239 The decomposition, ordering and execution of changes to the operating 240 system, and application configuration is the task of the management 241 framework that implements the YANG model. 243 3. Second Dimension: Model Types 245 This document suggests classifying YANG model types as either 246 standard YANG models, vendor-specific YANG models, or vendor-specific 247 extensions. 249 The suggested classification applies to both Network Element YANG 250 Data Models and to Network Service YANG Data Models. 252 It is to be expected that real-world implementations of both Network 253 Service and Network Element models will include a mix of all three 254 types of models. 256 3.1. Standard YANG Models 258 Standard YANG models are published by standards defining 259 organizations (SDOs). While there is no formal definition of what 260 construes an SDO, a common feature is that they publish 261 specifications along specific processes with content that reflects 262 some sort of membership consensus. The specifications are developed 263 for wide use among the membership or for audiences beyond that. 265 The lifecycle of these models are driven by the editing cycle of the 266 specification and not tied to a specific implementation. 268 Examples of SDOs in the networking industry are the IETF, the IEEE 269 and the MEF. 271 3.2. Vendor-specific YANG Models 273 Vendor-specific YANG models are developed by organizations with the 274 intent to support a specific set of implementations under control of 275 that organization. The intent of these models range from providing 276 openly published YANG models that may eventually be contributed back 277 to, or adopted by an SDO, to strictly internal YANG models not 278 intended for external consumption. 280 The lifecycle of these models are generally aligned with the release 281 cycle of the product or open source software project deliverables. 283 It is worth noting that there is an increasing amount of interaction 284 between OSS projects and SDOs in the networking industry. This 285 includes OSS projects implementing published standards as well as OSS 286 projects contributing content to standards defining organization 287 processes. 289 3.3. Vendor-specific Extensions 291 Vendors develop Vendor-specific Extensions to standard models using 292 YANG constructs for extending data definitions of previously 293 published models. This is done using the 'augment' statement that 294 allows locally defined data trees to be augmented into locations in 295 externally defined data trees. 297 Vendors use this to extend standard data models to cover the full 298 scope of features in implementations, which commonly is broader than 299 what is covered by the standard model. 301 4. Security Considerations 303 At this stage, authors of the draft didn't look into security 304 considerations. 306 5. IANA Considerations 308 This document requests no action by IANA. 310 6. Acknowledgements 312 Thanks to David Ball for his enlightenments on Metro Ethernet Forum 313 service aspects. 315 7. Change log [RFC Editor: Please remove] 317 version 1: restructure the document, add the two dimensions, add the 318 interaction with the different SDOs and opensource projects, add the 319 definitions. 321 version 2: added definitions for config and service models clarified 322 second dimension of model classification. fixed typos 324 version 3: restructure and partial rewrite of section 2. 326 version 4: Language fixes 328 8. References 329 8.1. Normative References 331 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 332 the Network Configuration Protocol (NETCONF)", RFC 6020, 333 DOI 10.17487/RFC6020, October 2010, 334 . 336 8.2. Informative References 338 [I-D.ietf-netmod-acl-model] 339 Bogdanovic, D., Sreenivasa, K., Huang, L., and D. Blair, 340 "Network Access Control List (ACL) YANG Data Model", 341 draft-ietf-netmod-acl-model-03 (work in progress), June 342 2015. 344 [I-D.ietf-ospf-yang] 345 Yeung, D., Qu, Y., Zhang, J., Bogdanovic, D., and K. 346 Koushik, "Yang Data Model for OSPF Protocol", draft-ietf- 347 ospf-yang-02 (work in progress), September 2015. 349 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 350 and A. Bierman, Ed., "Network Configuration Protocol 351 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 352 . 354 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 355 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 356 . 358 [Writable-MIB-Module-IESG-Statement] 359 "Writable MIB Module IESG Statement", 360 . 363 [YANG-Data-Model-for-L3VPN-service-delivery] 364 "YANG Data Model for L3VPN service delivery", 365 . 367 Authors' Addresses 369 Dean Bogdanovic 371 Email: ivandean@gmail.com 372 Benoit Claise 373 Cisco Systems, Inc. 375 Email: bclaise@cisco.com 377 Carl Moberg 378 Cisco Systems, Inc. 380 Email: camoberg@cisco.com