idnits 2.17.1 draft-wu-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 (January 5, 2017) is 2661 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-netmod-yang-model-classification-04 == Outdated reference: A later version (-07) exists of draft-ietf-bess-evpn-yang-01 == Outdated reference: A later version (-10) exists of draft-ietf-bess-l2vpn-yang-02 == Outdated reference: A later version (-04) exists of draft-wen-l2sm-l2vpn-service-model-03 -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 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: July 9, 2017 A. Farrel 6 Juniper Networks 7 January 5, 2017 9 Service Models Explained 10 draft-wu-opsawg-service-model-explained-05 12 Abstract 14 The IETF has produced a considerable number of data models in the 15 YANG modelling language. The majority of these models are used to 16 model devices or monolithic functions and they allow access for 17 configuration and to read operational status. 19 A small number of YANG modules have been defined to model services 20 (for example, the Layer Three Virtual Private Network Service Model 21 produced by the L3SM working group). 23 This document briefly sets out the scope of and purpose of an IETF 24 service model, and it also shows where a service model might fit into 25 a Software Defined Networking architecture. Note that service models 26 do not make any assumption of how a service is actually engineered 27 and delivered to a customer; details of how network protocols and 28 devices are engineered to deliver a service are captured in other 29 models that are not exposed through the Customer- Provider Interface. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on July 9, 2017. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terms and Concepts . . . . . . . . . . . . . . . . . . . . . 3 67 3. Using Service Models . . . . . . . . . . . . . . . . . . . . 6 68 4. Service Models in an SDN Context . . . . . . . . . . . . . . 7 69 5. Possible Causes of Confusion . . . . . . . . . . . . . . . . 10 70 6. Comparison With Other Work . . . . . . . . . . . . . . . . . 11 71 6.1. Comparison With Network Service Models . . . . . . . . . 12 72 6.2. Service Delivery Model Work . . . . . . . . . . . . . . . 13 73 6.3. Customer Service Model Work . . . . . . . . . . . . . . . 14 74 6.4. The MEF Architecture . . . . . . . . . . . . . . . . . . 15 75 7. Further Concepts . . . . . . . . . . . . . . . . . . . . . . 16 76 7.1. Technology Agnostic . . . . . . . . . . . . . . . . . . . 16 77 7.2. Relationship to Policy . . . . . . . . . . . . . . . . . 16 78 7.3. Operator-Specific Features . . . . . . . . . . . . . . . 17 79 7.4. Supporting Multiple Services . . . . . . . . . . . . . . 17 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 81 9. Manageability Considerations . . . . . . . . . . . . . . . . 18 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 83 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 86 12.2. Informative References . . . . . . . . . . . . . . . . . 18 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 89 1. Introduction 91 In recent years the number of data models written in the YANG 92 modelling language [RFC6020] for configuration and monitoring has 93 blossomed. Many of these are used for device-level configuration 94 (for example, [RFC7223]) or for control of monolithic functions or 95 protocol instances (for example, [RFC7407]). 97 Within the context of Software Defined Networking (SDN) [RFC7426] 98 YANG data models may be used on Southbound Interfaces (SBIs) between 99 a controller and network devices, and between network orchestrators 100 and controllers. There may also be a hierarchy of such components 101 with super-controllers, domain controllers, and device controllers 102 all exchanging information and instructions using YANG models. 104 Recently there has been interest in using YANG to define and document 105 data models that describe services in a portable way that is 106 independent of which network operator uses the model. These models 107 may be used in manual and even paper-driven service request processes 108 moving to IT-based mechanisms. Ultimately they could be used in 109 online, software-driven dynamic systems. 111 This document explains the scope and purpose of service models within 112 the IETF and describes how a service model can be used by a network 113 operator. Equally, this document clarifies what a service model is 114 not, and dispels some common misconceptions. 116 The document also shows where a service model might fit into an SDN 117 architecture, but it is important to note that a service model does 118 not require or preclude the use of SDN. Note that service models do 119 not make any assumption of how a service is actually engineered and 120 delivered to a customer; details of how network protocols and devices 121 are engineered to deliver a service are captured in other models that 122 are not exposed through the Customer- Provider Interface. 124 Other work on classifying YANG data models has been done in 125 [I-D.ietf-netmod-yang-model-classification]. That document provides 126 an important reference for this document, and also uses the term 127 "service model". Section 6.1 provides a comparison between these two 128 classifications. 130 2. Terms and Concepts 132 Readers should familiarize themselves with the description and 133 classification of YANG models provided in 134 [I-D.ietf-netmod-yang-model-classification]. 136 The following terms are used in this document: 138 Network Operator: This term is used to refer to the company that 139 owns and operates one or more networks that provide Internet 140 connectivity services and/or other services. The term is also 141 used to refer to an individual who performs operations and 142 management on those networks. 144 Customer: Someone who purchases a service (including connectivity) 145 from a network operator. In the context of this document, a 146 customer is usually the company that runs their own network or 147 computing platforms and wishes to connect to the Internet or 148 between sites. Such a customer may operate an enterprise network 149 or a data center. Sometimes this term may also be used to refer 150 to the individual in such a company who contracts to buy services 151 from a network operator. A customer as described here is a 152 separate commercial operation from the network operator, but some 153 companies may operate with internal customers so that, for 154 example, an IP/MPLS packet network is the customer of an optical 155 transport network. 157 Service: A network operator delivers one or more services to a 158 customer. A service in the context of this document (sometimes 159 called a Network Service) is some form of connectivity between 160 customer sites and the Internet or between customer sites across 161 the network operator's network and across the Internet, however a 162 distinction should be drawn between the parameters that describe a 163 service as included in a customer service model (q.v.) and a 164 Service Level Agreement (SLA) as discussed in Section 5 and 165 Section 7.2. 167 A service may be limited to simple connectivity (such as IP-based 168 Internet access), may be a tunnel (such as a virtual circuit), or 169 may be a more complex connectivity model (such as a multi-site 170 virtual private network). Services may be further enhanced by 171 additional functions providing security, load-balancing, 172 accounting, and so forth. Additionally, services usually include 173 guarantees of quality, throughput, and fault reporting. 175 This document makes a distinction between a service as delivered 176 to a customer (that is, the service as discussed on the interface 177 between a customer and the network operator) and the service as 178 realized within the network (as described in 179 [I-D.ietf-netmod-yang-model-classification]). This distinction is 180 discussed further in Section 6 182 Readers may also refer to [RFC7297] for an example of how an IP 183 connectivity service may be characterized. 185 Data Model: The concepts of information models and data models are 186 described in [RFC3444]. That document defines a data model by 187 contrasting it with the definition of an information model, so it 188 may be helpful to quote some text to give context within this 189 document. 191 The main purpose of an information model is to model managed 192 objects at a conceptual level, independent of any specific 193 implementations or protocols used to transport the data. The 194 degree of specificity (or detail) of the abstractions defined 195 in the information model depends on the modeling needs of its 196 designers. In order to make the overall design as clear as 197 possible, an information model should hide all protocol and 198 implementation details. Another important characteristic of an 199 information model is that it defines relationships between 200 managed objects. 202 Data models, conversely, are defined at a lower level of 203 abstraction and include many details. They are intended for 204 implementors and include protocol-specific constructs. 206 Service Model: A service model is a specific type of data model. It 207 describes a service and the parameters of the service in a 208 portable way. The service model may be divided into two 209 categories: 211 Customer Service Model: A customer service model is used to 212 describe a service as offered or delivered to a customer by a 213 network operator. It can be used by a human (via a user 214 interface such as a GUI, web form, or CLI) or by software to 215 configure or request a service and may equally be consumed by a 216 human (such as via an order fulfillment system) or by a 217 software component. Such models are sometimes referred to 218 simply as "service models" [I-D.ietf-l3sm-l3vpn-service-model]. 219 A customer service model is expressed as a core set of 220 parameters that are common across network operators: additional 221 features that are specific to the offerings of individual 222 network operators would be defined in extensions or 223 augmentations of the model. Except where specific technology 224 details (such as encapsulations, or mechanisms applied on 225 access links) are directly pertinent to the customer, customer 226 service models are technology agnostic so that the customer 227 does have influence over or knowledge of how the network 228 operator engineers the service. 230 Service Delivery Model: A service delivery model is used by a 231 network operator to define and manage how a service is 232 engineered in the network. It can be used by a human operator 233 (such as via a management station) or by a software tool to 234 instruct network components. Such models are sometimes 235 referred to as "network service models" 236 [I-D.ietf-netmod-yang-model-classification]. A service 237 delivery model is expressed as a core set of parameters that 238 are common across a network type and technology: additional 239 features that are specific to the configuration of individual 240 vendor equipment or proprietary protocols would be defined in 241 extensions or augmentations of the model. Service delivery 242 models include technology-specific modules. 244 The distinction between a customer service model and a service 245 delivery model needs to be repeatedly clarified. A customer service 246 model is not a data model used to directly configure network devices, 247 protocols, or functions: it is not something that is sent to network 248 devices (i.e., routers or switches) for processing. Equally, a 249 customer service model is not a data model that describes how a 250 network operator realizes and delivers the service described by the 251 model. This distinction is discussed further in later sections. 253 3. Using Service Models 255 As already indicated, customer service models are used on the 256 interface between customers and network operators. This is shown 257 simply in Figure 1 259 The language in which a customer service model is described is a 260 choice for whoever specifies the model. The IETF uses the YANG data 261 modeling language defined in [RFC6020] 263 The encoding and communication protocol used to exchange a customer 264 service model between customer and network operator are deployment- 265 and implementation-specific. The IETF has standardized the NETCONF 266 protocol [RFC6241] and the RESTCONF protocol 267 [I-D.ietf-netconf-restconf] for interactions "on the wire" between 268 software components with data encoded in XML or JSON. However, co- 269 located software components might use an API, while systems with more 270 direct human interactions might use web pages or even paper forms. 272 -------------- Customer ---------------------- 273 | | Service Model | | 274 | Customer | <-----------------> | Network Operator | 275 | | | | 276 -------------- ---------------------- 278 Figure 1: The Customer Service Models used on the Interface between 279 Customers and Network Operators 281 How a network operator processes a customer's service request 282 described with a customer service model depends on the commercial and 283 operational tools, processes, and policies used by the operator. 284 These may vary considerably from one network operator to another. 286 However, the intent is that the network operator maps the service 287 request into configuration and operational parameters that control 288 one or more networks to deliver the requested services. That means 289 that the network operator (or software run by the network operator) 290 takes the information in the customer service model and determines 291 how to deliver the service by enabling and configuring network 292 protocols and devices. They may achieve this by constructing service 293 delivery models and passing them to network orchestrators or 294 controllers. The use of standard customer service models eases 295 service delivery by means of automation. 297 4. Service Models in an SDN Context 299 In an SDN system, the management of network resources and protocols 300 is performed by software systems that determine how best to utilize 301 the network. Figure 2 shows a sample architectural view of an SDN 302 system where network elements are programmed by a component called an 303 "SDN controller" (or "controller" for short), and where controllers 304 are instructed by an orchestrator that has a wider view of the whole 305 of, or part of, a network. The internal organization of an SDN 306 control plane is deployment-specific. 308 ------------------ 309 | | 310 | Orchestrator | 311 | | 312 .------------------. 313 . : . 314 . : . 315 ------------ ------------ ------------ 316 | | | | | | 317 | Controller | | Controller | | Controller | 318 | | | | | | 319 ------------ ------------ ------------ 320 : . . : 321 : . . : 322 : . . : 323 --------- --------- --------- --------- 324 | Network | | Network | | Network | | Network | 325 | Element | | Element | | Element | | Element | 326 --------- --------- --------- --------- 328 Figure 2: A Samplen SDN Architecture 330 But a customer's service request is (or should be) technology- 331 agnostic. That is, there should be an independence between the 332 behavior and functions that a customer requests and the technology 333 that the network operator has available to deliver the service. This 334 means that the service request must be mapped to the orchestrator's 335 view, and this mapping may include a choice of which networks and 336 technologies to use depending on which service features have been 337 requested. 339 One implementation option to achieve this mapping is to split the 340 orchestration function between a "Service Orchestrator" and a 341 "Network Orchestrator" as shown in Figure 3. 343 Customer 344 ------------------ Service ---------- 345 | | Model | | 346 | Service |<-------->| Customer | 347 | Orchestrator | (a) | | 348 | | ---------- 349 ------------------ 350 . . 351 . . ----------- 352 . (b) . ......|Application| 353 . . : | BSS/OSS | 354 . . : ----------- 355 . Service Delivery . : 356 . Model . : 357 ------------------ ------------------ 358 | | | | 359 | Network | | Network | 360 | Orchestrator | | Orchestrator | 361 | | | | 362 .------------------ ------------------. 363 . : : . 364 . : Network Configuration : . 365 . : Model : . 366 ------------ ------------ ------------ ------------ 367 | | | | | | | | 368 | Controller | | Controller | | Controller | | Controller | 369 | | | | | | | | 370 ------------ ------------ ------------ ------------ 371 : . . : : 372 : . . Device : : 373 : . . Configuration : : 374 : . . Model : : 375 --------- --------- --------- --------- --------- 376 | Network | | Network | | Network | | Network | | Network | 377 | Element | | Element | | Element | | Element | | Element | 378 --------- --------- --------- --------- --------- 380 Figure 3: An Example SDN Architecture with a Service Orchestrator 382 Figure 3 also shows where different data models might be applied 383 within the architecture. 385 The split between control components that exposes a "service 386 interface" is present in many figures showing extended SDN 387 architectures: 389 o Figure 1 of [RFC7426] shows a separation of the "Application 390 Plane", the "Network Services Abstraction Layer (NSAL)", and the 391 "Control Plane". It marks the "Service Interface" as situated 392 between the NSAL and the Control Plane. 394 o [RFC7491] describes an interface between an "Application Service 395 Coordinator" and an "Application-Based Network Operations 396 Controller". 398 o Figure 1 of [I-D.ietf-netmod-yang-model-classification] shows an 399 interface from an Operations Support System (OSS) or a Business 400 Support System (BSS) that is expressed in "service models". 402 This can all lead to some confusion around the definition of a 403 "service interface" and a "service model". Some previous literature 404 considers the interface northbound of the Network Orchestrator 405 (labeled "(b)" in Figure 3) to be a "service interface" used by an 406 application, but the service described at this interface is network- 407 centric and is aware of many features such as topology, technology, 408 and operator policy. Thus, we make a distinction between this type 409 of service interface and the more abstract service interface (labeled 410 "(a)" in Figure 3) where the service is described by a service model 411 and the interaction is between customer and operator. Further 412 discussion of this point is provided in Section 5. 414 5. Possible Causes of Confusion 416 In discussing service models, there are several possible causes of 417 confusion: 419 o The services we are discussing are services provided by network 420 operators to customers. This is a completely different thing to 421 "Foo as a Service" (for example, Infrastructure as a Service 422 (IaaS)) where a service provider offers a service at some location 423 that is reached across a network. The confusion arises not only 424 because of the use of the word "service", but also because network 425 operators may offer value-added services as well as network 426 connection services to their customers. 428 o Network operation is completely out of scope in the discussion of 429 services between a network operator and a customer. That means 430 that the customer service model does not reveal to the customer 431 anything about how the network operator delivers the service. The 432 model does not expose details of technology or network resources 433 used to provide the service. For example, in the simple case of 434 point-to-point virtual link connectivity provided by a network 435 tunnel (such as an MPLS pseudowire) the network operator does not 436 expose the path through the network that the tunnel follows. Of 437 course, this does not preclude the network operator from taking 438 guidance from the customer (such as to avoid routing traffic 439 through a particular country) or from disclosing specific details 440 (such as might be revealed by a route trace), but these are not 441 standard features of the service as described in the customer 442 service model. 444 o The network operator may use further data models (service delivery 445 models) that help to describe how the service is realized in the 446 network. These models might be used on the interface between the 447 Service Orchestrator and the Network Orchestrator as shown in 448 Figure 3 and might include many of the pieces of information from 449 the customer service model alongside protocol parameters and 450 device configuration information. 451 [I-D.ietf-netmod-yang-model-classification] also terms these data 452 models as "service models" and a comparison is provided in 453 Section 6.1. It is important that the Service Orchestrator should 454 be able to map from a customer service model to these service 455 delivery models, but they are not the same things. 457 o Commercial terms are generally not a good subject for 458 standardization. It is possible that some network operators will 459 enhance standard customer service models to include commercial 460 information, but the way this is done is likely to vary widely 461 between network operators. 463 o Service Level Agreements (SLAs) have a high degree of overlap with 464 the definition of services present in customer service models. 465 Requests for specific bandwidth, for example, might be present in 466 a customer service model, and agreement to deliver a service is a 467 commitment to the description of the service in the customer 468 service model. However, SLAs typically include a number of fine- 469 grained details about how services are allowed to vary, by how 470 much, and how often. SLAs are also linked to commercial terms 471 with penalties and so forth, and so are also not good topics for 472 standardization. 474 6. Comparison With Other Work 476 Other work has classified YANG models, produced parallel 477 architectures, and developed a range of YANG models. This section 478 briefly examines that other work and shows how it fits with the 479 description of service models introduced in this document. 481 6.1. Comparison With Network Service Models 483 As previously noted, [I-D.ietf-netmod-yang-model-classification] 484 provides a classification of YANG data models. It introduces the 485 term "Network Service YANG Module" to identify the type of model used 486 to "describe the configuration, state data and operations of an 487 abstract representation of a service implemented on one or multiple 488 network elements." These are service delivery models as described in 489 this document, that is, they are the models used on the interface 490 between the Service Orchestrator or OSS/BSS and the Network 491 Orchestrator as shown in Figure 3. 493 Figure 1 of [I-D.ietf-netmod-yang-model-classification] can be 494 modified to make this more clear and to add an additional example of 495 a Network Service YANG model as shown in Figure 4. 497 +---------------+ 498 | | 499 | Customers | 500 | | 501 +---------------+ 503 - - - - - - - - - - - - - - 504 Service YANG Modules 506 +--------------------------+ +--------------------------+ 507 | | | Operations and Business | 508 | Service Orchestrator | | Support Systems | 509 | | | (OSS/BSS) | 510 +--------------------------+ +--------------------------+ 512 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 513 Network Service YANG Modules 515 +------------+ +-------------+ +-------------+ +-------------+ 516 | | | | | | | | 517 | - L2VPN | | - L2VPN | | EVPN | | L3VPN | 518 | - VPWS | | - VPLS | | | | | 519 | | | | | | | | 520 +------------+ +-------------+ +-------------+ +-------------+ 522 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 523 Network Element YANG Modules 525 +------------+ +------------+ +-------------+ +------------+ 526 | | | | | | | | 527 | MPLS | | BGP | | IPv4 / IPv6 | | Ethernet | 528 | | | | | | | | 529 +------------+ +------------+ +-------------+ +------------+ 531 L2VPN: Layer 2 Virtual Private Network 532 L3VPN: Layer 3 Virtual Private Network 533 VPWS: Virtual Private Wire Service 534 VPLS: Virtual Private LAN Service 536 Figure 4: YANG Module Layers Showing Service Models 538 6.2. Service Delivery Model Work 540 A number of IETF working groups are developing YANG models related to 541 services. These models focus on how the network operator configures 542 the network through protocols and devices to deliver a service. 544 A sample set of these models is listed here: 546 o [I-D.dhjain-bess-bgp-l3vpn-yang] defines a YANG model that can be 547 used to configure and manage BGP Layer 3 VPNs. 549 o [I-D.ietf-bess-l2vpn-yang] documents a YANG model that it is 550 expected will be used by the management tools run by the network 551 operators in order to manage and monitor the network resources 552 that they use to deliver L2VPN services. 554 o [I-D.ietf-bess-evpn-yang] defines YANG models for delivering an 555 Ethernet VPN service. 557 All of these models are service delivery models in the context of 558 this document. 560 6.3. Customer Service Model Work 562 Several initiatives within the IETF are developing customer service 563 models. The most advanced presents the Layer Three Virtual Private 564 Network (L3VPN) service as described by a network operator to a 565 customer. This L3VPN service model (L3SM) is documented in 566 [I-D.ietf-l3sm-l3vpn-service-model] where its usage is described as 567 in Figure 5 which is reproduced from that document. As can be seen, 568 the L3SM is a customer service model as described in this document. 570 L3VPN-SVC | 571 MODEL | 572 | 573 +------------------+ +-----+ 574 | Orchestration | < --- > | OSS | 575 +------------------+ +-----+ 576 | | 577 +----------------+ | 578 | Config manager | | 579 +----------------+ | 580 | | 581 | Netconf/CLI ... 582 | | 583 +------------------------------------------------+ 584 Network 586 Figure 5: The L3SM Service Architecture 588 A Layer Two VPN service model (L2SM) is defined in 589 [I-D.wen-l2sm-l2vpn-service-model]. That model's usage is described 590 as in Figure 6 which is a reproduction of Figure 5 from that 591 document. As can be seen, the L2SM is a customer service model as 592 described in this document. 594 ---------------------------- 595 | Customer Service Requester | 596 ---------------------------- 597 | 598 L2VPN | 599 Service | 600 Model | 601 | 602 ----------------------- 603 | Service Orchestration | 604 ----------------------- 605 | 606 | Service +-------------+ 607 | Delivery +------>| Application | 608 | Model | | BSS/OSS | 609 | V +-------------+ 610 ----------------------- 611 | Network Orchestration | 612 ----------------------- 613 | | 614 +----------------+ | 615 | Config manager | | 616 +----------------+ | Device 617 | | Models 618 | | 619 -------------------------------------------- 620 Network 622 Figure 6: The L2SM Service Architecture 624 6.4. The MEF Architecture 626 The MEF Forum has developed an architecture for network management 627 and operation. It is documented as the Lifecycle Service 628 Orchestration (LSO) Reference Architecture and illustrated in 629 Figure 2 of [MEF-55]. 631 The work of the MEF Forum embraces all aspects of Lifecycle Service 632 Orchestration including billing, SLAs, order management, and life- 633 cycle management. The IETF's work on service models is typically 634 smaller offering a simple, self-contained service YANG module. Thus, 635 it may be impractical to fit IETF service models into the MEF Forum 636 LSO architecture. This does not invalidate either approach, but only 637 observes that they are different. 639 7. Further Concepts 641 This section introduces a few further, more advanced concepts 643 7.1. Technology Agnostic 645 Service models should generally be technology agnostic. That is to 646 say, the customer should not care how the service is provided so long 647 as the service is delivered. 649 However, some technologies reach the customer site and make a 650 definition to the type of service delivered. Such features do need 651 to be described in the service model. 653 Two examples are: 655 o The data passed between customer equipment and network operator 656 equipment will be encapsulated in a specific way, and that data 657 plane type forms part of the service. 659 o Protocols that are run between customer equipment and network 660 operator equipment (for example, Operations, Administration, and 661 Maintenance protocols, or protocols for exchanging routing 662 information) need to be selected and configured as part of the 663 service description. 665 7.2. Relationship to Policy 667 Policy appears as a crucial function in many places during network 668 orchestration. A Service Orchestrator will, for example, apply the 669 network operator's policies to determine how to provide a service for 670 a particular customer (possibly considering commercial terms). 671 However, the policies within a service model are limited to those 672 over which a customer has direct influence, but which are acted on by 673 the network operator. 675 The policies that express desired behavior of services on occurrence 676 of specific events are close to SLA definitions: they should only be 677 included in the base service model where they are common to all 678 network operators' offerings. Policies that describe who at a 679 customer may request or modify services (that is, authorization) are 680 close to commercial terms: they, too, should only be included in the 681 base service model where they are common to all network operators' 682 offerings. 684 Nevertheless, policy is so important that all service models should 685 be designed to be easily extensible to allow policy components to be 686 added and associated with services as needed. 688 7.3. Operator-Specific Features 690 When work in Layer Three Virtual Private Network Service Model (L3SM) 691 was started, there was some doubt as to whether network operators 692 would be able to agree on a common description of the services that 693 they offer to their customers because, in a competitive environment, 694 each markets the services in a different way with different 695 additional features. Thus, when a basic description of the core 696 service is agreed and documented in a service model, it is important 697 that that model should be easily extended or augmented by each 698 network operator so that the standardized model can be used in a 699 common way and only the operator- specific features vary from one 700 environment to another. 702 7.4. Supporting Multiple Services 704 Network operators will, in general, offer many different services to 705 their customers. Each would normally be the subject of a separate 706 service model. 708 It is an implementation and deployment choice whether all service 709 models are processed by a single Service Orchestrator that can 710 coordinate between the different services, or whether each service 711 model is handled by a specialized Service Orchestrator able to 712 provide tuned behavior for a specific service. 714 8. Security Considerations 716 The interface between customer and service provider is a commercial 717 interface and needs to be subject to appropriate confidentiality. 718 Additionally, knowledge of what services are provided to a customer 719 or delivered by a network operator may supply information that can be 720 used in a variety of security attacks. 722 Clearly, the ability to modify information exchanges between customer 723 and network operator may result in bogus requests, unwarranted 724 billing, and false expectations. Furthermore, in an automated 725 system, modifications to service requests or the injection of bogus 726 requests may lead to attacks on the network and delivery of customer 727 traffic to the wrong place. 729 Therefore it is important that the protocol interface used to 730 exchange service request information between customer and network 731 operator is subject to authorization, authentication, and encryption. 733 This document discusses modeling that information, not how it is 734 exchanged. 736 9. Manageability Considerations 738 TBD 740 10. IANA Considerations 742 This document makes no requests for IANA action 744 11. Acknowledgements 746 Thanks to Daniel King, Xian Zhang, and Michael Scharf for useful 747 review and comments. Med Boucadair gave thoughtful and detailed 748 comments on version -04 of this document. 750 12. References 752 12.1. Normative References 754 [I-D.ietf-l3sm-l3vpn-service-model] 755 Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 756 Model for L3VPN service delivery", draft-ietf-l3sm-l3vpn- 757 service-model-19 (work in progress), November 2016. 759 [I-D.ietf-netmod-yang-model-classification] 760 Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 761 Classification", draft-ietf-netmod-yang-model- 762 classification-04 (work in progress), October 2016. 764 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 765 Information Models and Data Models", RFC 3444, 766 DOI 10.17487/RFC3444, January 2003, 767 . 769 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 770 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 771 Defined Networking (SDN): Layers and Architecture 772 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 773 2015, . 775 12.2. Informative References 777 [I-D.dhjain-bess-bgp-l3vpn-yang] 778 Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., 779 Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model 780 for BGP/MPLS L3 VPNs", draft-dhjain-bess-bgp-l3vpn-yang-02 781 (work in progress), August 2016. 783 [I-D.ietf-bess-evpn-yang] 784 Brissette, P., Sajassi, A., Shah, H., Li, Z., 785 Tiruveedhula, K., Hussain, I., and J. Rabadan, "Yang Data 786 Model for EVPN", draft-ietf-bess-evpn-yang-01 (work in 787 progress), July 2016. 789 [I-D.ietf-bess-l2vpn-yang] 790 Shah, H., Brissette, P., Chen, I., Hussain, I., and B. 791 Wen, "YANG Data Model for MPLS-based L2VPN", draft-ietf- 792 bess-l2vpn-yang-02 (work in progress), October 2016. 794 [I-D.ietf-netconf-restconf] 795 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 796 Protocol", draft-ietf-netconf-restconf-18 (work in 797 progress), October 2016. 799 [I-D.wen-l2sm-l2vpn-service-model] 800 Wen, B., Fioccola, G., Xie, C., and L. Jalil, "A YANG Data 801 Model for L2VPN Service Delivery", draft-wen-l2sm-l2vpn- 802 service-model-03 (work in progress), October 2016. 804 [MEF-55] MEF Forum, "Service Operations Specification MEF 55 : 805 Lifecycle Service Orchestration (LSO) Reference 806 Architecture and Framework", March 2016. 808 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 809 the Network Configuration Protocol (NETCONF)", RFC 6020, 810 DOI 10.17487/RFC6020, October 2010, 811 . 813 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 814 and A. Bierman, Ed., "Network Configuration Protocol 815 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 816 . 818 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 819 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 820 . 822 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 823 Connectivity Provisioning Profile (CPP)", RFC 7297, 824 DOI 10.17487/RFC7297, July 2014, 825 . 827 [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for 828 SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, 829 December 2014, . 831 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 832 Application-Based Network Operations", RFC 7491, 833 DOI 10.17487/RFC7491, March 2015, 834 . 836 Authors' Addresses 838 Qin Wu 839 Huawei Technologies 841 Email: bill.wu@huawei.com 843 Will Liu 844 Huawei Technologies 846 Email: liushucheng@huawei.com 848 Adrian Farrel 849 Juniper Networks 851 Email: afarrel@juniper.net