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