idnits 2.17.1 draft-ietf-opsawg-service-model-explained-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 (October 12, 2017) is 2387 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-bess-evpn-yang-02 == Outdated reference: A later version (-10) exists of draft-ietf-bess-l2vpn-yang-07 == Outdated reference: A later version (-10) exists of draft-ietf-l2sm-l2vpn-service-model-03 -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) -- Obsolete informational reference (is this intentional?): RFC 8049 (Obsoleted by RFC 8299) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPS Area Working Group Q. Wu 3 Internet-Draft W. Liu 4 Intended status: Informational Huawei Technologies 5 Expires: April 15, 2018 A. Farrel 6 Juniper Networks 7 October 12, 2017 9 Service Models Explained 10 draft-ietf-opsawg-service-model-explained-05 12 Abstract 14 The IETF has produced many modules in the YANG modeling language. 15 The majority of these modules are used to construct data models to 16 model devices or monolithic functions. 18 A small number of YANG modules have been defined to model services 19 (for example, the Layer Three Virtual Private Network Service Model 20 produced by the L3SM working group and documented in RFC 8049). 22 This document describes service models as used within the IETF, and 23 also shows where a service model might fit into a Software Defined 24 Networking architecture. Note that service models do not make any 25 assumption of how a service is actually engineered and delivered for 26 a customer; details of how network protocols and devices are 27 engineered to deliver a service are captured in other modules that 28 are not exposed through the Customer-Provider Interface. 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 https://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 15, 2018. 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 (https://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. Terms and Concepts . . . . . . . . . . . . . . . . . . . . . 4 66 3. Using Service Models . . . . . . . . . . . . . . . . . . . . 6 67 3.1. Practical Considerations . . . . . . . . . . . . . . . . 8 68 4. Service Models in an SDN Context . . . . . . . . . . . . . . 8 69 5. Possible Causes of Confusion . . . . . . . . . . . . . . . . 11 70 6. Comparison With Other Work . . . . . . . . . . . . . . . . . 13 71 6.1. Comparison With Network Service Models . . . . . . . . . 13 72 6.2. Service Delivery and Network Element Model Work . . . . . 15 73 6.3. Customer Service Model Work . . . . . . . . . . . . . . . 15 74 6.4. The MEF Architecture . . . . . . . . . . . . . . . . . . 17 75 7. Further Concepts . . . . . . . . . . . . . . . . . . . . . . 18 76 7.1. Technology Agnostic . . . . . . . . . . . . . . . . . . . 18 77 7.2. Relationship to Policy . . . . . . . . . . . . . . . . . 18 78 7.3. Operator-Specific Features . . . . . . . . . . . . . . . 19 79 7.4. Supporting Multiple Services . . . . . . . . . . . . . . 19 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 81 9. Manageability Considerations . . . . . . . . . . . . . . . . 20 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 83 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 86 12.2. Informative References . . . . . . . . . . . . . . . . . 21 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 89 1. Introduction 91 In recent years the number of modules written in the YANG modeling 92 language [RFC6020] for configuration and monitoring has blossomed. 93 Many of these are used for device-level configuration (for example, 95 [RFC7223]) or for control of monolithic functions or protocol 96 instances (for example, [RFC7407]). 98 [RFC7950] makes a distinction between a "data model" which it defines 99 as describing how data is represented and accessed, and a "YANG 100 module" that defines hierarchies of schema nodes to make a self- 101 contained and compilable block of definitions and inclusions. YANG 102 structures data models into modules for ease of use. 104 Within the context of Software Defined Networking (SDN) [RFC7149] 105 [RFC7426], YANG data modules may be used on the interface between a 106 controller and network devices, and between network orchestrators and 107 controllers. There may also be a hierarchy of such components with 108 super controllers, domain controllers, and device controllers all 109 exchanging information and instructions using YANG modules. 111 There has been interest in using YANG to define and document data 112 models that describe services in a portable way that is independent 113 of which network operator uses the model. For example, the Layer 114 Three Virtual Private Network Service Model (L3SM) [RFC8049]. Such 115 models may be used in manual and even paper-driven service request 116 processes with a gradual transition to IT-based mechanisms. 117 Ultimately they could be used in online, software-driven dynamic 118 systems, and may be used as part of an SDN system. 120 This document explains the scope and purpose of service models within 121 the IETF (and limited to within the scope of the IETF) and describes 122 how a service model can be used by a network operator. Equally, this 123 document clarifies what a service model is not, and dispels some 124 common misconceptions. 126 The document also shows where a service model might fit into an SDN 127 architecture, but it is important to note that a service model does 128 not require or preclude the use of SDN. Note that service models do 129 not make any assumption of how a service is actually engineered and 130 delivered to a customer; details of how network protocols and devices 131 are engineered to deliver a service are captured in other modules 132 that are not exposed through the interface betweeen the customer and 133 the provider. 135 In summary, a service model is a formal representation of the data 136 elements that describe a network service as that service is described 137 to or requested by a customer of a network operator. Details 138 included in the service model include a description of the service as 139 experienced by the customer, but not features of how that service is 140 delivered or realized by the service provider. 142 Other work on classifying YANG modules has been done in [RFC8199]. 143 That document provides an important reference for this document, and 144 also uses the term "service module". Section 6.1 in this document 145 provides a comparison between these two uses of the same terminology. 147 2. Terms and Concepts 149 Readers should familiarize themselves with the description and 150 classification of YANG modules provided in [RFC8199]. 152 The following terms are used in this document: 154 Network Operator: This term is used to refer to the company that 155 owns and operates one or more networks that provide Internet 156 connectivity services and/or other services. 158 Customer: This term refers to someone who purchases a service 159 (including connectivity) from a network operator. In the context 160 of this document, a customer is usually a company that runs their 161 own network or computing platforms and wishes to connect to the 162 Internet or between sites. Such a customer may operate an 163 enterprise network or a data center. Sometimes this term may also 164 be used to refer to the individual in such a company who contracts 165 to buy services from a network operator. A customer as described 166 here is a separate commercial operation from the network operator, 167 but some companies may operate with internal customers so that, 168 for example, an IP/MPLS packet network may be the customer of an 169 optical transport network. 171 Service: A network operator delivers one or more services to a 172 customer. A service in the context of this document (sometimes 173 called a Network Service) is some form of connectivity between 174 customer sites and the Internet, or between customer sites across 175 the network operator's network and across the Internet. However, 176 a distinction should be drawn between the parameters that describe 177 a service as included in a customer service model (see the 178 definition of this term, below) and a Service Level Agreement 179 (SLA) as discussed in Section 5 and Section 7.2. 181 A service may be limited to simple connectivity (such as IP-based 182 Internet access), may be a tunnel (such as a virtual circuit), or 183 may involve more complex connectivity (such as in a multi-site 184 virtual private network). Services may be further enhanced by 185 additional functions providing security, load-balancing, 186 accounting, and so forth. Additionally, services usually include 187 guarantees of quality, throughput, and fault reporting. 189 This document makes a distinction between a service as delivered 190 to a customer (that is, the service as discussed on the interface 191 between a customer and the network operator) and the service as 192 realized within the network (as described in [RFC8199]). This 193 distinction is discussed further in Section 6. 195 Readers may also refer to [RFC7297] for an example of how an IP 196 connectivity service may be characterized. 198 Data Model: The concepts of information models and data models are 199 described in [RFC3444]. That document defines a data model by 200 contrasting it with the definition of an information model as 201 follows: 203 The main purpose of an information model is to model managed 204 objects at a conceptual level, independent of any specific 205 implementations or protocols used to transport the data. The 206 degree of specificity (or detail) of the abstractions defined 207 in the information model depends on the modeling needs of its 208 designers. In order to make the overall design as clear as 209 possible, an information model should hide all protocol and 210 implementation details. Another important characteristic of an 211 information model is that it defines relationships between 212 managed objects. 214 Data models, conversely, are defined at a lower level of 215 abstraction and include many details. They are intended for 216 implementors and include protocol-specific constructs. 218 As mentioned in Section 1, this document also uses the terms "data 219 model" and "YANG module" as defined in [RFC7950]. 221 Service Model: A service model is a specific type of data model. It 222 describes a service and the parameters of the service in a 223 portable way that can be used uniformly independent of the 224 equipment and operating environment. The service model may be 225 divided into two categories: 227 Customer Service Model: A customer service model is used to 228 describe a service as offered or delivered to a customer by a 229 network operator as shown in Figure 1. It can be used by a 230 human (via a user interface such as a GUI, web form, or CLI) or 231 by software to configure or request a service, and may equally 232 be consumed by a human (such as via an order fulfillment 233 system) or by a software component. Such models are sometimes 234 referred to simply as "service models" [RFC8049]. A customer 235 service model is expressed in a YANG module as a core set of 236 parameters that are common across network operators: additional 237 features that are specific to the offerings of individual 238 network operators would be defined in extensions or 239 augmentations of the module. Except where specific technology 240 details (such as encapsulations, or mechanisms applied on 241 access links) are directly pertinent to the customer, customer 242 service models are technology agnostic so that the customer 243 does not have influence over or knowledge of how the network 244 operator engineers the service. 246 An example of where such details are relevant to the customer 247 is when they describe the behavior or interactions on the 248 interface between the equipment at the customer site (often 249 referred to as the Customer Edge or CE equipment) and the 250 equipment at the network operator's site (usually referred to 251 as the Provider Edge or PE equipment). 253 Service Delivery Model: A service delivery model is used by a 254 network operator to define and manage how a service is 255 engineered in the network. It can be used by a human operator 256 (such as via a management station) or by a software tool to 257 instruct network components. The YANG modules that encode such 258 models are sometimes referred to as "network service YANG 259 modules" [RFC8199] and are consumed by "external systems" such 260 as Operations Support System (OSS). A service delivery module 261 is expressed as a core set of parameters that are common across 262 a network type and technology: additional features that are 263 specific to the configuration of individual vendor equipment or 264 proprietary protocols would be defined in extensions or 265 augmentations of the module. Service delivery modules include 266 technology-specific modules. 268 The distinction between a customer service model and a service 269 delivery model needs to be clarified. The modules that encode a 270 customer service model are not used to directly configure network 271 devices, protocols, or functions: it is not something that is sent 272 to network devices (i.e., routers or switches) for processing. 273 Equally, the modules that encode a customer service model do not 274 describes how a network operator realizes and delivers the service 275 described by the module. This distinction is discussed further in 276 later sections. 278 3. Using Service Models 280 As already indicated, customer service models are used on the 281 interface between customers and network operators. This is shown 282 simply in Figure 1. 284 The language in which a customer service model is described is a 285 choice for whoever specifies the model. The IETF uses the YANG data 286 modeling language defined in [RFC6020]. 288 The encoding and communication protocol used to exchange a customer 289 service model between customer and network operator are deployment- 290 and implementation-specific. The IETF has standardized the NETCONF 291 protocol [RFC6241] and the RESTCONF protocol [RFC8040] for 292 interactions "on the wire" between software components with data 293 encoded in XML or JSON. However, co-located software components 294 might use an internal API, while systems with more direct human 295 interactions might use web pages or even paper forms. Where direct 296 human interaction comes into play, interface interactions may be 297 realized via business practices and that may introduce some margin of 298 error, thus raising the priority for automated, deterministic 299 interfaces. 301 -------------- Customer ---------------------- 302 | | Service Model | | 303 | Customer | <-----------------> | Network Operator | 304 | | | | 305 -------------- ---------------------- 307 Figure 1: The Customer Service Models used on the Interface between 308 Customers and Network Operators 310 How a network operator processes a customer's service request 311 described with a customer service model depends on the commercial and 312 operational tools, processes, and policies used by the network 313 operator. These may vary considerably from one network operator to 314 another. 316 However, the intent is that the network operator maps the service 317 request into configuration and operational parameters that control 318 one or more networks to deliver the requested services. That means 319 that the network operator (or software run by the network operator) 320 takes the information in the customer service model and determines 321 how to deliver the service by enabling and configuring network 322 protocols and devices. They may achieve this by constructing service 323 delivery models and passing them to network orchestrators or 324 controllers. The use of standard customer service models eases 325 service delivery by means of automation. 327 3.1. Practical Considerations 329 The practicality of customer service models has been repeatedly 330 debated. It has been suggested that network operators have radically 331 different business modes and widely diverse commercial offerings 332 making a common customer service model is impractical. However, the 333 L3SM [RFC8049] results from the consensus of multiple individuals 334 working at network operators and offers a common core of service 335 options that can be augmented according to the needs of individual 336 network operators. 338 It has also been suggested that there should be a single, base 339 customer service module, and that details of individual services 340 should be offered as extensions or augmentations of this. It is 341 quite possible that a number of service parameters (such as the 342 identity and postal address of a customer) will be common and it 343 would be a mistake to define them multiple times, once in each 344 customer service model. However, the distinction between a 'module' 345 and a 'model' should be considered at this point: modules are how the 346 data for models is logically broken out and documented especially for 347 re-use in multiple models. 349 4. Service Models in an SDN Context 351 In a Software Defined Networking (SDN) system, the management of 352 network resources and protocols is performed by software systems that 353 determine how best to utilize the network. Figure 2 shows a sample 354 architectural view of an SDN system where network elements are 355 programmed by a component called an "SDN controller" (or "controller" 356 for short), and where controllers are instructed by an orchestrator 357 that has a wider view of the whole of, or part of, a network. The 358 internal organization of an SDN control plane is deployment-specific. 360 ------------------ 361 | | 362 | Orchestrator | 363 | | 364 .------------------. 365 . : . 366 . : . 367 ------------ ------------ ------------ 368 | | | | | | 369 | Controller | | Controller | | Controller | 370 | | | | | | 371 ------------ ------------ ------------ 372 : . . : 373 : . . : 374 : . . : 375 --------- --------- --------- --------- 376 | Network | | Network | | Network | | Network | 377 | Element | | Element | | Element | | Element | 378 --------- --------- --------- --------- 380 Figure 2: A Sample SDN Architecture 382 A customer's service request is (or should be) technology-agnostic. 383 That is, a customer is unware of the technology that the network 384 operator has available to deliver the service and so the customer 385 does not make requests specific to the underlying technology, but is 386 limited to making requests specific to the service that is to be 387 delivered. The orchestrator must map the service request to its 388 view, and this mapping may include a choice of which networks and 389 technologies to use depending on which service features have been 390 requested. 392 One implementation option to achieve this mapping is to split the 393 orchestration function between a "Service Orchestrator" and a 394 "Network Orchestrator" as shown in Figure 3. 396 Customer 397 ------------------ Service ---------- 398 | | Model | | 399 | Service |<-------->| Customer | 400 | Orchestrator | (a) | | 401 | | ---------- 402 ------------------ 403 . . 404 . . (b) ----------- 405 . (b) . ......|Application| 406 . . : | BSS/OSS | 407 . . : ----------- 408 . Service Delivery . : 409 . Model . : 410 ------------------ ------------------ 411 | | | | 412 | Network | | Network | 413 | Orchestrator | | Orchestrator | 414 | | | | 415 .------------------ ------------------. 416 . : : . 417 . : Network Configuration : . 418 . : Model : . 419 ------------ ------------ ------------ ------------ 420 | | | | | | | | 421 | Controller | | Controller | | Controller | | Controller | 422 | | | | | | | | 423 ------------ ------------ ------------ ------------ 424 : . . : : 425 : . . Device : : 426 : . . Configuration : : 427 : . . Model : : 428 --------- --------- --------- --------- --------- 429 | Network | | Network | | Network | | Network | | Network | 430 | Element | | Element | | Element | | Element | | Element | 431 --------- --------- --------- --------- --------- 433 Figure 3: An Example SDN Architecture with a Service Orchestrator 435 Figure 3 also shows where different data models might be applied 436 within the architecture. The Device Confguration Models are used by 437 a Controller to set parameters on an individual network element. The 438 Network Configuration Models are use by a Network Orchestrator to 439 instruct Controllers (that may each be responsible for multiple 440 network elements) how to configure parts of a network. 442 The split between control components that exposes a "service 443 interface" that is present in many figures showing extended SDN 444 architectures: 446 o Figure 1 of [RFC7426] shows a separation of the "Application 447 Plane", the "Network Services Abstraction Layer (NSAL)", and the 448 "Control Plane". It marks the "Service Interface" as situated 449 between the NSAL and the control plane. 451 o Figure 1 of [RFC7491] shows an interface between an "Application 452 Service Coordinator" and an "Application-Based Network Operations 453 Controller". 455 o Figure 1 of [RFC8199] shows an interface from an OSS or a Business 456 Support System (BSS) that is expressed in "Network Service YANG 457 Modules". 459 This can all lead to some confusion around the definition of a 460 "service interface" and a "service model". Some previous literature 461 considers the interface northbound of the Network Orchestrator 462 (labeled "(b)" in Figure 3) to be a "service interface" used by an 463 application, but the service described at this interface is network- 464 centric and is aware of many features such as topology, technology, 465 and operator policy. Thus, we make a distinction between this type 466 of service interface and the more abstract service interface (labeled 467 "(a)" in Figure 3) where the service is described by a service model 468 and the interaction is between customer and network operator. 469 Further discussion of this point is provided in Section 5. 471 5. Possible Causes of Confusion 473 In discussing service models, there are several possible causes of 474 confusion: 476 o The services we are discussing are connectivity services provided 477 by network operators to customers achieved by manipulating the 478 network resources of the operator's network. This is a completely 479 different thing to "Foo as a Service" (for example, Storage as a 480 Service (SaaS)) where a service provider offers reachability to a 481 value-added service that is provided at some location in the 482 network using other resources (compute, storage, ...) that are not 483 part of the network itself. The confusion arises not only because 484 of the use of the word "service" in both cases, but also because 485 network operators may offer both types of service to their 486 customers. 488 o Network operation is normally out of scope in the discussion of 489 services between a network operator and a customer. That means 490 that the customer service model does not reveal to the customer 491 anything about how the network operator delivers the service, nor 492 does the model expose details of technology or network resources 493 used to provide the service (all of these details could, in any 494 case, be considered seecurity vulnerabilities. For example, in 495 the simple case of point-to-point virtual link connectivity 496 provided by a network tunnel (such as an MPLS pseudowire) the 497 network operator does not expose the path through the network that 498 the tunnel follows. Of course, this does not preclude the network 499 operator from taking guidance from the customer (such as to avoid 500 routing traffic through a particular country) or from disclosing 501 specific details (such as might be revealed by a route trace), but 502 these are not standard features of the service as described in the 503 customer service model. 505 o The network operator may use further data models (service delivery 506 models) that help to describe how the service is realized in the 507 network. These models might be used on the interface between the 508 Service Orchestrator and the Network Orchestrator as shown in 509 Figure 3 and might include many of the pieces of information from 510 the customer service model alongside protocol parameters and 511 device configuration information. [RFC8199] also terms these data 512 models as "service models" and encode them as "Network Service 513 YANG Modules" and a comparison is provided in Section 6.1. It is 514 important that the Service Orchestrator should be able to map from 515 a customer service model to these service delivery models, but 516 they are not the same things. 518 o Commercial terms (such as cost per byte, per minute, scoped by 519 quality and type of service, and related to payment terms) are 520 generally not a good subject for standardization. It is possible 521 that some network operators will enhance standard customer service 522 models to include commercial information, but the way this is done 523 is likely to vary widely between network operators. Thus, this 524 feature is out of scope for standardized customer service models. 526 o Service Level Agreements (SLAs) have a high degree of overlap with 527 the definition of services present in customer service models. 528 Requests for specific bandwidth, for example, might be present in 529 a customer service model, and agreement to deliver a service is a 530 commitment to the description of the service in the customer 531 service model. However, SLAs typically include a number of fine- 532 grained details about how services are allowed to vary, by how 533 much, and how often. SLAs are also linked to commercial terms 534 with penalties and so forth, and thus are also not good topics for 535 standardization. As with commercial terms, it is expected that 536 some network operators will enhance standard customer service 537 models to include SLA parameters either using their own work or 538 depending on material from standards bodies that specialize in 539 this topic, but this feature is out of scope for the IETF's 540 customer service models. 542 If a network operator chooses to express an SLA using a data 543 model, that model might be referenced as an extension or an 544 augmentation of the customer service model. 546 6. Comparison With Other Work 548 Other work has classified YANG modules, produced parallel 549 architectures, and developed a range of YANG modules. This section 550 briefly examines that other work and shows how it fits with the 551 description of service models introduced in this document. 553 6.1. Comparison With Network Service Models 555 As previously noted, [RFC8199] provides a classification of YANG 556 modules. It introduces the term "Network Service YANG Module" to 557 identify the type of module used to "describe the configuration, 558 state data, operations and notifications of abstract representations 559 of services implemented on one or multiple network elements." These 560 modules are used to construct the service delivery models as 561 described in this document; that is, they are the modules used on the 562 interface between the Service Orchestrator or OSS/BSS and the Network 563 Orchestrator as shown in Figure 3. 565 Figure 1 of [RFC8199] can be modified to make this more clear and to 566 add an additional example of a Network Service YANG module as shown 567 in Figure 4. As can be seen, the highest classification of modules 568 collects those that are used to deliver operations support and 569 business support. These might be consumed by an Operations Support 570 System (OSS) or a Business Support System (BSS), and a Service 571 Orchestrator may form part of an OSS/BSS or may be a separate 572 component. This highest layer in the figure is divided into the 573 Customer Service Modules that are used to describe services to a 574 customer as discussed in this document, and other modules that 575 describe further OSS/BSS function such as billing and SLAs. 577 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 578 Operations Support and Business Support YANG Modules 580 +-----------------------+ +-----------------------+ 581 | | | | 582 | Customer Service | | Other | 583 | YANG Modules | | Operations Support | 584 | | | and | 585 | +------+ +------+ | | Business Support | 586 | | | | | | | YANG Modules | 587 | | L2SM | | L3SM | | | | 588 | | | | | | | | 589 | +------+ +------+ | | | 590 | | | | 591 +-----------------------+ +-----------------------+ 593 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 594 Network Service YANG Modules 596 +------------+ +-------------+ +-------------+ +-------------+ 597 | | | | | | | | 598 | - L2VPN | | - L2VPN | | EVPN | | L3VPN | 599 | - VPWS | | - VPLS | | | | | 600 | | | | | | | | 601 +------------+ +-------------+ +-------------+ +-------------+ 603 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 604 Network Element YANG Modules 606 +------------+ +------------+ +-------------+ +------------+ 607 | | | | | | | | 608 | MPLS | | BGP | | IPv4 / IPv6 | | Ethernet | 609 | | | | | | | | 610 +------------+ +------------+ +-------------+ +------------+ 612 Key: 613 EVPN: Ethernet Virtual Private Network 614 L2SM: Layer 2 Virtual Private Network Service Model 615 L2VPN: Layer 2 Virtual Private Network 616 L3SM: Layer 3 Virtual Private Network Service Model 617 L3VPN: Layer 3 Virtual Private Network 618 VPLS: Virtual Private LAN Service 619 VPWS: Virtual Private Wire Service 621 Figure 4: YANG Module Abstaction Layers Showing Customer Service 622 Modules 624 6.2. Service Delivery and Network Element Model Work 626 A number of IETF working groups are developing YANG modules related 627 to services. These models focus on how the network operator 628 configures the network through protocols and devices to deliver a 629 service. Some of these models are classified as network service 630 delivery models (also called service delivery models or network 631 configuation models depending on the level at which they are 632 pitched), while others have details that are related to specific 633 element configuration and so are classed as network element models 634 (also called device models). 636 A sample set of these models is listed here: 638 o [I-D.dhjain-bess-bgp-l3vpn-yang] defines a YANG module that can be 639 used to configure and manage BGP L3VPNs. 641 o [I-D.ietf-bess-l2vpn-yang] documents a data model that it is 642 expected will be used by the management tools run by the network 643 operators in order to manage and monitor the network resources 644 that they use to deliver L2VPN services. 646 o [I-D.ietf-bess-evpn-yang] defines YANG modules for delivering an 647 Ethernet VPN service. 649 6.3. Customer Service Model Work 651 Several initiatives within the IETF are developing customer service 652 models. The L3SM presents the L3VPN service as described by a 653 network operator to a customer. Figure 5, which is reproduced from 654 [RFC8049], shows that the L3SM is a customer service model as 655 described in this document. 657 L3VPN-SVC | 658 MODEL | 659 | 660 +------------------+ +-----+ 661 | Orchestration | < --- > | OSS | 662 +------------------+ +-----+ 663 | | 664 +----------------+ | 665 | Config manager | | 666 +----------------+ | 667 | | 668 | Netconf/CLI ... 669 | | 670 +------------------------------------------------+ 671 Network 673 Figure 5: The L3SM Service Architecture 675 A Layer Two VPN service model (L2SM) is defined in 676 [I-D.ietf-l2sm-l2vpn-service-model]. That model's usage is described 677 as in Figure 6 which is a reproduction of Figure 5 from that 678 document. As can be seen, the L2SM is a customer service model as 679 described in this document. 681 ---------------------------- 682 | Customer Service Requester | 683 ---------------------------- 684 | 685 L2VPN | 686 Service | 687 Model | 688 | 689 ----------------------- 690 | Service Orchestration | 691 ----------------------- 692 | 693 | Service +-------------+ 694 | Delivery +------>| Application | 695 | Model | | BSS/OSS | 696 | V +-------------+ 697 ----------------------- 698 | Network Orchestration | 699 ----------------------- 700 | | 701 +----------------+ | 702 | Config manager | | 703 +----------------+ | Device 704 | | Models 705 | | 706 -------------------------------------------- 707 Network 709 Figure 6: The L2SM Service Architecture 711 6.4. The MEF Architecture 713 The MEF Forum has developed an architecture for network management 714 and operation. It is documented as the Lifecycle Service 715 Orchestration (LSO) Reference Architecture and illustrated in 716 Figure 2 of [MEF-55]. 718 The work of the MEF Forum embraces all aspects of Lifecycle Service 719 Orchestration including billing, SLAs, order management, and life- 720 cycle management. The IETF's work on service models is typically 721 smaller offering a simple, self-contained service YANG module. This 722 does not invalidate either approach: it only observes that they are 723 different approaches. 725 7. Further Concepts 727 This section introduces a few further, more advanced concepts 729 7.1. Technology Agnostic 731 Service models should generally be technology agnostic. That is to 732 say, the customer should not care how the service is provided so long 733 as the service is delivered. 735 However, some technologies reach the customer site and make a 736 difference to the type of service delivered. Such features do need 737 to be described in the service model. 739 Two examples are: 741 o The data passed between customer equipment and network operator 742 equipment will be encapsulated in a specific way, and that data 743 plane type forms part of the service. 745 o Protocols that are run between customer equipment and network 746 operator equipment (for example, Operations, Administration, and 747 Maintenance protocols, protocols for discovery, or protocols for 748 exchanging routing information) need to be selected and configured 749 as part of the service description. 751 7.2. Relationship to Policy 753 Policy appears as a crucial function in many places during network 754 orchestration. A Service Orchestrator will, for example, apply the 755 network operator's policies to determine how to provide a service for 756 a particular customer (possibly considering commercial terms). 757 However, the policies within a service model are limited to those 758 over which a customer has direct influence and that are acted on by 759 the network operator. 761 The policies that express desired behavior of services on occurrence 762 of specific events are close to SLA definitions: they should only be 763 included in the base service model where they are common to all 764 network operators' offerings. Policies that describe who at a 765 customer may request or modify services (that is, authorization) are 766 close to commercial terms: they, too, should only be included in the 767 base service model where they are common to all network operators' 768 offerings. 770 As with commercial terms and SLAs discussed in Section 5, it is 771 expected that some network operators will enhance standard customer 772 service models to include policy parameters either using their own 773 work or depending on specific policy models built in the IETF or 774 other standards bodies. 776 Nevertheless, policy is so important that all service models should 777 be designed to be easily extensible to allow policy components to be 778 added and associated with services as needed. 780 7.3. Operator-Specific Features 782 When work on the L3SM was started, there was some doubt as to whether 783 network operators would be able to agree on a common description of 784 the services that they offer to their customers because, in a 785 competitive environment, each markets the services in a different way 786 with different additional features. However, the working group was 787 able to agree on a core set of features that multiple network 788 operators were willing to consider as "common". They also understood 789 that, should an individual network operator want to describe 790 additional features (operator-specific features), they could do so by 791 extending or augmenting the L3SM model. 793 Thus, when a basic description of a core service is agreed and 794 documented in a service model, it is important that that model should 795 be easily extended or augmented by each network operator so that the 796 standardized model can be used in a common way and only the operator- 797 specific features varied from one environment to another. 799 7.4. Supporting Multiple Services 801 Network operators will, in general, offer many different services to 802 their customers. Each would normally be the subject of a separate 803 service model. 805 Whether each service model is handled by a specialized Service 806 Orchestrator able to provide tuned behavior for a specific service or 807 whether all service models are handled by a single Service 808 Orchestrator is an implementation and deployment choice. 810 It is expected that, over time, certain elements of the service 811 models will be seen to repeat in each model. An example of such an 812 element is the postal address of the customer. 814 It is anticipated that, while access to such information from each 815 service model is important, the data will be described in its own 816 module and may form part of the service model either by inclusion or 817 by index. 819 8. Security Considerations 821 The interface between customer and service provider is a commercial 822 interface and needs to be subject to appropriate confidentiality. 823 Additionally, knowledge of what services are provided to a customer 824 or delivered by a network operator may supply information that can be 825 used in a variety of security attacks. The service model itself will 826 expose security-related parameters for the specific service where the 827 related functon is available to the customer. 829 Clearly, the ability to modify information exchanges between customer 830 and network operator may result in bogus requests, unwarranted 831 billing, and false expectations. Furthermore, in an automated 832 system, modifications to service requests or the injection of bogus 833 requests may lead to attacks on the network and delivery of customer 834 traffic to the wrong place. 836 Therefore it is important that the protocol interface used to 837 exchange service request information between customer and network 838 operator is subject to authorization, authentication, and encryption. 839 Clearly, the level of abstraction provided by a service model 840 protects the operator from unwarranted visibility into their network, 841 and the fact that it is entirely up to the operator how they deliver 842 the service provides additional protection. 844 Equally, all external interfaces, such as any of those between the 845 functional components in Figure 3 needs to be correctly secured. 846 This document discusses modeling the information, not how it is 847 exchanged. 849 9. Manageability Considerations 851 This whole document discusses issues related to network management 852 and control. 854 It is important to observe that automated service provisioning 855 resulting from use of a customer service model may result in rapid 856 and significant changes in traffic load within a network and that 857 that might have an effect on other services carried in a network. 859 It is expected, therefore, that a Service Orchestration component has 860 awareness of other service commitments, that the Network 861 Orchestration component will not commit network resources to fulfill 862 a service unless doing so is appropriate, and that a feedback loop 863 will be provided to report on degradation of the network that will 864 impact the service. 866 The operational state of a service does not form part of a customer 867 service model. However, it is likely that a network operator may 868 want to report some state information about various components of the 869 service, and that could be achieved through extensions to the core 870 service model just as SLA extensions could be made as described in 871 Section 5. 873 10. IANA Considerations 875 This document makes no requests for IANA action. 877 11. Acknowledgements 879 Thanks to Daniel King, Xian Zhang, Michael Scharf, Med Boucadair, 880 Luis Miguel Contreras Murillo, Joe Salowey, Benoit Claise, Robert 881 Sparks, Tom Petch, David Sinicrope, and Deborah Brungard for useful 882 review and comments. 884 Thanks to Dean Bogdanovic, Tianran Zhou, and Carl Moberg for their 885 help coordinating with [RFC8199]. 887 Many thanks to Jerry Bonner for spotting a tiny, one-word, but 888 critical typo. 890 12. References 892 12.1. Normative References 894 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 895 Information Models and Data Models", RFC 3444, 896 DOI 10.17487/RFC3444, January 2003, 897 . 899 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 900 Classification", RFC 8199, DOI 10.17487/RFC8199, July 901 2017, . 903 12.2. Informative References 905 [I-D.dhjain-bess-bgp-l3vpn-yang] 906 Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., 907 Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model 908 for BGP/MPLS L3 VPNs", draft-dhjain-bess-bgp-l3vpn-yang-02 909 (work in progress), August 2016. 911 [I-D.ietf-bess-evpn-yang] 912 Brissette, P., Sajassi, A., Shah, H., Li, Z., 913 Tiruveedhula, K., Hussain, I., and J. Rabadan, "Yang Data 914 Model for EVPN", draft-ietf-bess-evpn-yang-02 (work in 915 progress), March 2017. 917 [I-D.ietf-bess-l2vpn-yang] 918 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 919 and K. Tiruveedhula, "YANG Data Model for MPLS-based 920 L2VPN", draft-ietf-bess-l2vpn-yang-07 (work in progress), 921 October 2017. 923 [I-D.ietf-l2sm-l2vpn-service-model] 924 Wen, B., Fioccola, G., Xie, C., and L. Jalil, "A YANG Data 925 Model for L2VPN Service Delivery", draft-ietf-l2sm-l2vpn- 926 service-model-03 (work in progress), September 2017. 928 [MEF-55] MEF Forum, "Service Operations Specification MEF 55 : 929 Lifecycle Service Orchestration (LSO) Reference 930 Architecture and Framework", March 2016. 932 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 933 the Network Configuration Protocol (NETCONF)", RFC 6020, 934 DOI 10.17487/RFC6020, October 2010, 935 . 937 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 938 and A. Bierman, Ed., "Network Configuration Protocol 939 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 940 . 942 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 943 Networking: A Perspective from within a Service Provider 944 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 945 . 947 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 948 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 949 . 951 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 952 Connectivity Provisioning Profile (CPP)", RFC 7297, 953 DOI 10.17487/RFC7297, July 2014, 954 . 956 [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for 957 SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, 958 December 2014, . 960 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 961 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 962 Defined Networking (SDN): Layers and Architecture 963 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 964 2015, . 966 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 967 Application-Based Network Operations", RFC 7491, 968 DOI 10.17487/RFC7491, March 2015, 969 . 971 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 972 RFC 7950, DOI 10.17487/RFC7950, August 2016, 973 . 975 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 976 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 977 . 979 [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 980 Model for L3VPN Service Delivery", RFC 8049, 981 DOI 10.17487/RFC8049, February 2017, 982 . 984 Authors' Addresses 986 Qin Wu 987 Huawei Technologies 989 Email: bill.wu@huawei.com 991 Will Liu 992 Huawei Technologies 994 Email: liushucheng@huawei.com 996 Adrian Farrel 997 Juniper Networks 999 Email: afarrel@juniper.net