idnits 2.17.1 draft-ietf-opsawg-service-model-explained-00.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 (June 23, 2017) is 2471 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 8049 (Obsoleted by RFC 8299) == 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-05 == Outdated reference: A later version (-10) exists of draft-ietf-l2sm-l2vpn-service-model-01 -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) Summary: 1 error (**), 0 flaws (~~), 4 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: December 25, 2017 A. Farrel 6 Juniper Networks 7 June 23, 2017 9 Service Models Explained 10 draft-ietf-opsawg-service-model-explained-00 12 Abstract 14 The IETF has produced a considerable number of data modules in the 15 YANG modelling language. The majority of these modules are used to 16 construct data models to model devices or monolithic functions and 17 they allow access for 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 and documented in RFC 8049). 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 for 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 December 25, 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 . . . . . . . . . . . . . . 8 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 and Network Element 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 . . . . . . . . . . . . . . . . . . . 18 81 9. Manageability Considerations . . . . . . . . . . . . . . . . 18 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 83 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 86 12.2. Informative References . . . . . . . . . . . . . . . . . 19 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 89 1. Introduction 91 In recent years the number of data modules 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. For example, 107 the Layer Three Virtual Private Network Service Model (L3SM) 108 [RFC8049]. Such models may be used in manual and even paper-driven 109 service request processes with a gradual transition to IT-based 110 mechanisms. Ultimately they could be used in online, software-driven 111 dynamic systems. 113 This document explains the scope and purpose of service models within 114 the IETF and describes how a service model can be used by a network 115 operator. Equally, this document clarifies what a service model is 116 not, and dispels some common misconceptions. 118 The document also shows where a service model might fit into an SDN 119 architecture, but it is important to note that a service model does 120 not require or preclude the use of SDN. Note that service models do 121 not make any assumption of how a service is actually engineered and 122 delivered to a customer; details of how network protocols and devices 123 are engineered to deliver a service are captured in other models that 124 are not exposed through the Customer- Provider Interface. 126 Other work on classifying YANG data models has been done in 127 [I-D.ietf-netmod-yang-model-classification]. That document provides 128 an important reference for this document, and also uses the term 129 "service model". Section 6.1 provides a comparison between these two 130 uses of the same terminology. 132 2. Terms and Concepts 134 Readers should familiarize themselves with the description and 135 classification of YANG models provided in 136 [I-D.ietf-netmod-yang-model-classification]. 138 The following terms are used in this document: 140 Network Operator: This term is used to refer to the company that 141 owns and operates one or more networks that provide Internet 142 connectivity services and/or other services. The term is also 143 used to refer to an individual who performs operations and 144 management on those networks. 146 Customer: This term refers to someone who purchases a service 147 (including connectivity) from a network operator. In the context 148 of this document, a customer is usually a company that runs their 149 own network or computing platforms and wishes to connect to the 150 Internet or between sites. Such a customer may operate an 151 enterprise network or a data center. Sometimes this term may also 152 be used to refer to the individual in such a company who contracts 153 to buy services from a network operator. A customer as described 154 here is a separate commercial operation from the network operator, 155 but some companies may operate with internal customers so that, 156 for example, an IP/MPLS packet network may be the customer of an 157 optical transport network. 159 Service: A network operator delivers one or more services to a 160 customer. A service in the context of this document (sometimes 161 called a Network Service) is some form of connectivity between 162 customer sites and the Internet, or between customer sites across 163 the network operator's network and across the Internet. However, 164 a distinction should be drawn between the parameters that describe 165 a service as included in a customer service model (q.v.) and a 166 Service Level Agreement (SLA) as discussed in Section 5 and 167 Section 7.2. 169 A service may be limited to simple connectivity (such as IP-based 170 Internet access), may be a tunnel (such as a virtual circuit), or 171 may be a more complex connectivity model (such as a multi-site 172 virtual private network). Services may be further enhanced by 173 additional functions providing security, load-balancing, 174 accounting, and so forth. Additionally, services usually include 175 guarantees of quality, throughput, and fault reporting. 177 This document makes a distinction between a service as delivered 178 to a customer (that is, the service as discussed on the interface 179 between a customer and the network operator) and the service as 180 realized within the network (as described in 181 [I-D.ietf-netmod-yang-model-classification]). This distinction is 182 discussed further in Section 6. 184 Readers may also refer to [RFC7297] for an example of how an IP 185 connectivity service may be characterized. 187 Data Model: The concepts of information models and data models are 188 described in [RFC3444]. That document defines a data model by 189 contrasting it with the definition of an information model, so it 190 may be helpful to quote some text to give context within this 191 document. 193 The main purpose of an information model is to model managed 194 objects at a conceptual level, independent of any specific 195 implementations or protocols used to transport the data. The 196 degree of specificity (or detail) of the abstractions defined 197 in the information model depends on the modeling needs of its 198 designers. In order to make the overall design as clear as 199 possible, an information model should hide all protocol and 200 implementation details. Another important characteristic of an 201 information model is that it defines relationships between 202 managed objects. 204 Data models, conversely, are defined at a lower level of 205 abstraction and include many details. They are intended for 206 implementors and include protocol-specific constructs. 208 Service Model: A service model is a specific type of data model. It 209 describes a service and the parameters of the service in a 210 portable way. The service model may be divided into two 211 categories: 213 Customer Service Model: A customer service model is used to 214 describe a service as offered or delivered to a customer by a 215 network operator. It can be used by a human (via a user 216 interface such as a GUI, web form, or CLI) or by software to 217 configure or request a service, and may equally be consumed by 218 a human (such as via an order fulfillment system) or by a 219 software component. Such models are sometimes referred to 220 simply as "service models" [RFC8049]. A customer service model 221 is expressed as a core set of parameters that are common across 222 network operators: additional features that are specific to the 223 offerings of individual network operators would be defined in 224 extensions or augmentations of the model. Except where 225 specific technology details (such as encapsulations, or 226 mechanisms applied on access links) are directly pertinent to 227 the customer, customer service models are technology agnostic 228 so that the customer does have influence over or knowledge of 229 how the network operator engineers the service. 231 An example of where such details are relevant to the customer 232 are when they describe the behavior or interactions on the 233 interface between the equipment at the customer site (often 234 referred to as the Customer Edge or CE equipment) and the 235 equipment at the network operator's site (usually referred to 236 as the Provider Edge or PE equipment). 238 Service Delivery Model: A service delivery model is used by a 239 network operator to define and manage how a service is 240 engineered in the network. It can be used by a human operator 241 (such as via a management station) or by a software tool to 242 instruct network components. Such models are sometimes 243 referred to as "network service models" 244 [I-D.ietf-netmod-yang-model-classification] and are consumed by 245 "external systems" such as Operations Support System (OSS). A 246 service delivery model is expressed as a core set of parameters 247 that are common across a network type and technology: 248 additional features that are specific to the configuration of 249 individual vendor equipment or proprietary protocols would be 250 defined in extensions or augmentations of the model. Service 251 delivery models include technology-specific modules. 253 The distinction between a customer service model and a service 254 delivery model needs to be repeatedly clarified. A customer service 255 model is not a data model used to directly configure network devices, 256 protocols, or functions: it is not something that is sent to network 257 devices (i.e., routers or switches) for processing. Equally, a 258 customer service model is not a data model that describes how a 259 network operator realizes and delivers the service described by the 260 model. This distinction is discussed further in later sections. 262 3. Using Service Models 264 As already indicated, customer service models are used on the 265 interface between customers and network operators. This is shown 266 simply in Figure 1 268 The language in which a customer service model is described is a 269 choice for whoever specifies the model. The IETF uses the YANG data 270 modeling language defined in [RFC6020] 272 The encoding and communication protocol used to exchange a customer 273 service model between customer and network operator are deployment- 274 and implementation-specific. The IETF has standardized the NETCONF 275 protocol [RFC6241] and the RESTCONF protocol [RFC8040] for 276 interactions "on the wire" between software components with data 277 encoded in XML or JSON. However, co-located software components 278 might use an API, while systems with more direct human interactions 279 might use web pages or even paper forms. 281 -------------- Customer ---------------------- 282 | | Service Model | | 283 | Customer | <-----------------> | Network Operator | 284 | | | | 285 -------------- ---------------------- 287 Figure 1: The Customer Service Models used on the Interface between 288 Customers and Network Operators 290 How a network operator processes a customer's service request 291 described with a customer service model depends on the commercial and 292 operational tools, processes, and policies used by the network 293 operator. These may vary considerably from one network operator to 294 another. 296 However, the intent is that the network operator maps the service 297 request into configuration and operational parameters that control 298 one or more networks to deliver the requested services. That means 299 that the network operator (or software run by the network operator) 300 takes the information in the customer service model and determines 301 how to deliver the service by enabling and configuring network 302 protocols and devices. They may achieve this by constructing service 303 delivery models and passing them to network orchestrators or 304 controllers. The use of standard customer service models eases 305 service delivery by means of automation. 307 The practicality of customer service models has been repeatedly 308 debated. It has been suggested that network operators have such 309 radically different business modes and such diverse commercial 310 offerings that a common customer service model is impractical. 311 However, the L3SM [RFC8049] results from the consensus of multiple 312 individuals working at network operators and offers a common core of 313 service options that can be augmented according to the needs of 314 individual network operators. 316 It has also been suggested that there should be a single, base 317 customer service module, and that details of individual services 318 should be offered as extensions or augmentations of this. It is 319 quite possible that a number of service parameters (such as the 320 identity and postal address of a customer) will be common and it 321 would be a mistake to define them multiple times, once in each 322 customer service model. However, the distinction between a 'module' 323 and a 'model' should be considered at this point: modules are how the 324 data for models is logically broken out and documented especially for 325 re-use in multiple models. 327 4. Service Models in an SDN Context 329 In an SDN system, the management of network resources and protocols 330 is performed by software systems that determine how best to utilize 331 the network. Figure 2 shows a sample architectural view of an SDN 332 system where network elements are programmed by a component called an 333 "SDN controller" (or "controller" for short), and where controllers 334 are instructed by an orchestrator that has a wider view of the whole 335 of, or part of, a network. The internal organization of an SDN 336 control plane is deployment-specific. 338 ------------------ 339 | | 340 | Orchestrator | 341 | | 342 .------------------. 343 . : . 344 . : . 345 ------------ ------------ ------------ 346 | | | | | | 347 | Controller | | Controller | | Controller | 348 | | | | | | 349 ------------ ------------ ------------ 350 : . . : 351 : . . : 352 : . . : 353 --------- --------- --------- --------- 354 | Network | | Network | | Network | | Network | 355 | Element | | Element | | Element | | Element | 356 --------- --------- --------- --------- 358 Figure 2: A Sample SDN Architecture 360 But a customer's service request is (or should be) technology- 361 agnostic. That is, there should be an independence between the 362 behavior and functions that a customer requests and the technology 363 that the network operator has available to deliver the service. This 364 means that the service request must be mapped to the orchestrator's 365 view, and this mapping may include a choice of which networks and 366 technologies to use depending on which service features have been 367 requested. 369 One implementation option to achieve this mapping is to split the 370 orchestration function between a "Service Orchestrator" and a 371 "Network Orchestrator" as shown in Figure 3. 373 Customer 374 ------------------ Service ---------- 375 | | Model | | 376 | Service |<-------->| Customer | 377 | Orchestrator | (a) | | 378 | | ---------- 379 ------------------ 380 . . 381 . . ----------- 382 . (b) . ......|Application| 383 . . : | BSS/OSS | 384 . . : ----------- 385 . Service Delivery . : 386 . Model . : 387 ------------------ ------------------ 388 | | | | 389 | Network | | Network | 390 | Orchestrator | | Orchestrator | 391 | | | | 392 .------------------ ------------------. 393 . : : . 394 . : Network Configuration : . 395 . : Model : . 396 ------------ ------------ ------------ ------------ 397 | | | | | | | | 398 | Controller | | Controller | | Controller | | Controller | 399 | | | | | | | | 400 ------------ ------------ ------------ ------------ 401 : . . : : 402 : . . Device : : 403 : . . Configuration : : 404 : . . Model : : 405 --------- --------- --------- --------- --------- 406 | Network | | Network | | Network | | Network | | Network | 407 | Element | | Element | | Element | | Element | | Element | 408 --------- --------- --------- --------- --------- 410 Figure 3: An Example SDN Architecture with a Service Orchestrator 412 Figure 3 also shows where different data models might be applied 413 within the architecture. 415 The split between control components that exposes a "service 416 interface" is present in many figures showing extended SDN 417 architectures: 419 o Figure 1 of [RFC7426] shows a separation of the "Application 420 Plane", the "Network Services Abstraction Layer (NSAL)", and the 421 "Control Plane". It marks the "Service Interface" as situated 422 between the NSAL and the Control Plane. 424 o [RFC7491] describes an interface between an "Application Service 425 Coordinator" and an "Application-Based Network Operations 426 Controller". 428 o Figure 1 of [I-D.ietf-netmod-yang-model-classification] shows an 429 interface from an OSS or a Business Support System (BSS) that is 430 expressed in "Network Service YANG Models". 432 This can all lead to some confusion around the definition of a 433 "service interface" and a "service model". Some previous literature 434 considers the interface northbound of the Network Orchestrator 435 (labeled "(b)" in Figure 3) to be a "service interface" used by an 436 application, but the service described at this interface is network- 437 centric and is aware of many features such as topology, technology, 438 and operator policy. Thus, we make a distinction between this type 439 of service interface and the more abstract service interface (labeled 440 "(a)" in Figure 3) where the service is described by a service model 441 and the interaction is between customer and network operator. 442 Further discussion of this point is provided in Section 5. 444 5. Possible Causes of Confusion 446 In discussing service models, there are several possible causes of 447 confusion: 449 o The services we are discussing are services provided by network 450 operators to customers. This is a completely different thing to 451 "Foo as a Service" (for example, Infrastructure as a Service 452 (IaaS)) where a service provider offers a service at some location 453 that is reached across a network. The confusion arises not only 454 because of the use of the word "service", but also because network 455 operators may offer value-added services as well as network 456 connection services to their customers. 458 o Network operation is completely out of scope in the discussion of 459 services between a network operator and a customer. That means 460 that the customer service model does not reveal to the customer 461 anything about how the network operator delivers the service. The 462 model does not expose details of technology or network resources 463 used to provide the service. For example, in the simple case of 464 point-to-point virtual link connectivity provided by a network 465 tunnel (such as an MPLS pseudowire) the network operator does not 466 expose the path through the network that the tunnel follows. Of 467 course, this does not preclude the network operator from taking 468 guidance from the customer (such as to avoid routing traffic 469 through a particular country) or from disclosing specific details 470 (such as might be revealed by a route trace), but these are not 471 standard features of the service as described in the customer 472 service model. 474 o The network operator may use further data models (service delivery 475 models) that help to describe how the service is realized in the 476 network. These models might be used on the interface between the 477 Service Orchestrator and the Network Orchestrator as shown in 478 Figure 3 and might include many of the pieces of information from 479 the customer service model alongside protocol parameters and 480 device configuration information. 481 [I-D.ietf-netmod-yang-model-classification] also terms these data 482 models as "service models" or "Network Service YANG Models" and a 483 comparison is provided in Section 6.1. It is important that the 484 Service Orchestrator should be able to map from a customer service 485 model to these service delivery models, but they are not the same 486 things. 488 o Commercial terms are generally not a good subject for 489 standardization. It is possible that some network operators will 490 enhance standard customer service models to include commercial 491 information, but the way this is done is likely to vary widely 492 between network operators. 494 o Service Level Agreements (SLAs) have a high degree of overlap with 495 the definition of services present in customer service models. 496 Requests for specific bandwidth, for example, might be present in 497 a customer service model, and agreement to deliver a service is a 498 commitment to the description of the service in the customer 499 service model. However, SLAs typically include a number of fine- 500 grained details about how services are allowed to vary, by how 501 much, and how often. SLAs are also linked to commercial terms 502 with penalties and so forth, and so are also not good topics for 503 standardization. 505 If a network operator chooses to express an SLA using a data 506 model, that model might be referenced as an extension or an 507 augmentation of the customer service model. 509 6. Comparison With Other Work 511 Other work has classified YANG models, produced parallel 512 architectures, and developed a range of YANG models. This section 513 briefly examines that other work and shows how it fits with the 514 description of service models introduced in this document. 516 6.1. Comparison With Network Service Models 518 As previously noted, [I-D.ietf-netmod-yang-model-classification] 519 provides a classification of YANG data models. It introduces the 520 term "Network Service YANG Module" to identify the type of model used 521 to "describe the configuration, state data, operations and 522 notifications of abstract representations of services implemented on 523 one or multiple network elements." These are service delivery models 524 as described in this document, that is, they are the models used on 525 the interface between the Service Orchestrator or OSS/BSS and the 526 Network Orchestrator as shown in Figure 3. 528 Figure 1 of [I-D.ietf-netmod-yang-model-classification] can be 529 modified to make this more clear and to add an additional example of 530 a Network Service YANG model as shown in Figure 4. 532 +---------------+ 533 | | 534 | Customers | 535 | | 536 +---------------+ 538 - - - - - - - - - - - - - - 539 Customer Service YANG Modules 541 +--------------------------+ +--------------------------+ 542 | | | Operations and Business | 543 | Service Orchestrator | | Support Systems | 544 | | | (OSS/BSS) | 545 +--------------------------+ +--------------------------+ 547 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 548 Network Service YANG Modules 550 +------------+ +-------------+ +-------------+ +-------------+ 551 | | | | | | | | 552 | - L2VPN | | - L2VPN | | EVPN | | L3VPN | 553 | - VPWS | | - VPLS | | | | | 554 | | | | | | | | 555 +------------+ +-------------+ +-------------+ +-------------+ 557 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 558 Network Element YANG Modules 560 +------------+ +------------+ +-------------+ +------------+ 561 | | | | | | | | 562 | MPLS | | BGP | | IPv4 / IPv6 | | Ethernet | 563 | | | | | | | | 564 +------------+ +------------+ +-------------+ +------------+ 566 L2VPN: Layer 2 Virtual Private Network 567 L3VPN: Layer 3 Virtual Private Network 568 VPWS: Virtual Private Wire Service 569 VPLS: Virtual Private LAN Service 571 Figure 4: YANG Module Layers Showing Service Models 573 6.2. Service Delivery and Network Element Model Work 575 A number of IETF working groups are developing YANG models related to 576 services. These models focus on how the network operator configures 577 the network through protocols and devices to deliver a service. Some 578 of these models are classed as service delivery models while others 579 have details that are related to specific element configuration and 580 so are classed as network element models. 582 A sample set of these models is listed here: 584 o [I-D.dhjain-bess-bgp-l3vpn-yang] defines a YANG model that can be 585 used to configure and manage BGP Layer 3 VPNs. 587 o [I-D.ietf-bess-l2vpn-yang] documents a YANG model that it is 588 expected will be used by the management tools run by the network 589 operators in order to manage and monitor the network resources 590 that they use to deliver L2VPN services. 592 o [I-D.ietf-bess-evpn-yang] defines YANG models for delivering an 593 Ethernet VPN service. 595 6.3. Customer Service Model Work 597 Several initiatives within the IETF are developing customer service 598 models. The most advanced presents the Layer Three Virtual Private 599 Network (L3VPN) service as described by a network operator to a 600 customer. This L3VPN service model (L3SM) is documented in [RFC8049] 601 where its usage is described as in Figure 5 which is reproduced from 602 that document. As can be seen, the L3SM is a customer service model 603 as described in this document. 605 L3VPN-SVC | 606 MODEL | 607 | 608 +------------------+ +-----+ 609 | Orchestration | < --- > | OSS | 610 +------------------+ +-----+ 611 | | 612 +----------------+ | 613 | Config manager | | 614 +----------------+ | 615 | | 616 | Netconf/CLI ... 617 | | 618 +------------------------------------------------+ 619 Network 621 Figure 5: The L3SM Service Architecture 623 A Layer Two VPN service model (L2SM) is defined in 624 [I-D.ietf-l2sm-l2vpn-service-model]. That model's usage is described 625 as in Figure 6 which is a reproduction of Figure 5 from that 626 document. As can be seen, the L2SM is a customer service model as 627 described in this document. 629 ---------------------------- 630 | Customer Service Requester | 631 ---------------------------- 632 | 633 L2VPN | 634 Service | 635 Model | 636 | 637 ----------------------- 638 | Service Orchestration | 639 ----------------------- 640 | 641 | Service +-------------+ 642 | Delivery +------>| Application | 643 | Model | | BSS/OSS | 644 | V +-------------+ 645 ----------------------- 646 | Network Orchestration | 647 ----------------------- 648 | | 649 +----------------+ | 650 | Config manager | | 651 +----------------+ | Device 652 | | Models 653 | | 654 -------------------------------------------- 655 Network 657 Figure 6: The L2SM Service Architecture 659 6.4. The MEF Architecture 661 The MEF Forum has developed an architecture for network management 662 and operation. It is documented as the Lifecycle Service 663 Orchestration (LSO) Reference Architecture and illustrated in 664 Figure 2 of [MEF-55]. 666 The work of the MEF Forum embraces all aspects of Lifecycle Service 667 Orchestration including billing, SLAs, order management, and life- 668 cycle management. The IETF's work on service models is typically 669 smaller offering a simple, self-contained service YANG module. Thus, 670 it may be impractical to fit IETF service models into the MEF Forum 671 LSO architecture. This does not invalidate either approach, but only 672 observes that they are different. 674 7. Further Concepts 676 This section introduces a few further, more advanced concepts 678 7.1. Technology Agnostic 680 Service models should generally be technology agnostic. That is to 681 say, the customer should not care how the service is provided so long 682 as the service is delivered. 684 However, some technologies reach the customer site and make a 685 difference to the type of service delivered. Such features do need 686 to be described in the service model. 688 Two examples are: 690 o The data passed between customer equipment and network operator 691 equipment will be encapsulated in a specific way, and that data 692 plane type forms part of the service. 694 o Protocols that are run between customer equipment and network 695 operator equipment (for example, Operations, Administration, and 696 Maintenance protocols, protocols for discovery, or protocols for 697 exchanging routing information) need to be selected and configured 698 as part of the service description. 700 7.2. Relationship to Policy 702 Policy appears as a crucial function in many places during network 703 orchestration. A Service Orchestrator will, for example, apply the 704 network operator's policies to determine how to provide a service for 705 a particular customer (possibly considering commercial terms). 706 However, the policies within a service model are limited to those 707 over which a customer has direct influence and that are acted on by 708 the network operator. 710 The policies that express desired behavior of services on occurrence 711 of specific events are close to SLA definitions: they should only be 712 included in the base service model where they are common to all 713 network operators' offerings. Policies that describe who at a 714 customer may request or modify services (that is, authorization) are 715 close to commercial terms: they, too, should only be included in the 716 base service model where they are common to all network operators' 717 offerings. 719 Nevertheless, policy is so important that all service models should 720 be designed to be easily extensible to allow policy components to be 721 added and associated with services as needed. 723 7.3. Operator-Specific Features 725 When work in the L3SM working group was started, there was some doubt 726 as to whether network operators would be able to agree on a common 727 description of the services that they offer to their customers 728 because, in a competitive environment, each markets the services in a 729 different way with different additional features. However, the 730 working group was able to agree on a core set of features that 731 multiple network operators were willing to consider as "common". 732 They also understood that should an individual network operator want 733 to describe additional features (operator-specific features) they 734 could do so by extending or augmenting the L3SM model. 736 Thus, when a basic description of a core service is agreed and 737 documented in a service model, it is important that that model should 738 be easily extended or augmented by each network operator so that the 739 standardized model can be used in a common way and only the operator- 740 specific features varied from one environment to another. 742 7.4. Supporting Multiple Services 744 Network operators will, in general, offer many different services to 745 their customers. Each would normally be the subject of a separate 746 service model. 748 It is an implementation and deployment choice whether all service 749 models are processed by a single Service Orchestrator that can 750 coordinate between the different services, or whether each service 751 model is handled by a specialized Service Orchestrator able to 752 provide tuned behavior for a specific service. 754 It is expected that, over time, certain elements of the service 755 models will be seen to repeat in each model. An example of such an 756 element is the postal address of the customer. 758 It is anticipated that, while access to such information from each 759 service model is important, the data will be described in its own 760 module and may form part of the service model either by inclusion or 761 by index. 763 8. Security Considerations 765 The interface between customer and service provider is a commercial 766 interface and needs to be subject to appropriate confidentiality. 767 Additionally, knowledge of what services are provided to a customer 768 or delivered by a network operator may supply information that can be 769 used in a variety of security attacks. 771 Clearly, the ability to modify information exchanges between customer 772 and network operator may result in bogus requests, unwarranted 773 billing, and false expectations. Furthermore, in an automated 774 system, modifications to service requests or the injection of bogus 775 requests may lead to attacks on the network and delivery of customer 776 traffic to the wrong place. 778 Therefore it is important that the protocol interface used to 779 exchange service request information between customer and network 780 operator is subject to authorization, authentication, and encryption. 781 This document discusses modeling that information, not how it is 782 exchanged. 784 9. Manageability Considerations 786 This whole document discusses issues related to network management. 788 It is important to observe that automated service provisioning 789 resulting from use of a customer service model may result in rapid 790 and significant changes in traffic load within a network and that 791 that might have an effect on other services carried in a network. 793 It is expected, therefore, that a Service Orchestration component has 794 awareness of other service commitments, that the Network 795 Orchestration component will not commit network resources to fulfill 796 a service unless doing so is appropriate, and that a feedback loop 797 will be provided to report on degradation of the network that will 798 impact the service. 800 The operational state of a service does not form part of a customer 801 service model. However, it is likely that a network operator may 802 want to report some state information about various components of the 803 service, and that could be achieved through extensions to the core 804 service model. 806 10. IANA Considerations 808 This document makes no requests for IANA action 810 11. Acknowledgements 812 Thanks to Daniel King, Xian Zhang, and Michael Scharf for useful 813 review and comments. Med Boucadair gave thoughtful and detailed 814 comments on version -04 of this document. Thanks to Dean Bogdanovic 815 and Tianran Zhou for their help coordinating with [I-D.ietf-netmod- 816 yang-model-classification]. 818 12. References 820 12.1. Normative References 822 [I-D.ietf-netmod-yang-model-classification] 823 Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 824 Classification", draft-ietf-netmod-yang-model- 825 classification-08 (work in progress), June 2017. 827 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 828 Information Models and Data Models", RFC 3444, 829 DOI 10.17487/RFC3444, January 2003, 830 . 832 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 833 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 834 Defined Networking (SDN): Layers and Architecture 835 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 836 2015, . 838 [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 839 Model for L3VPN Service Delivery", RFC 8049, 840 DOI 10.17487/RFC8049, February 2017, 841 . 843 12.2. Informative References 845 [I-D.dhjain-bess-bgp-l3vpn-yang] 846 Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., 847 Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model 848 for BGP/MPLS L3 VPNs", draft-dhjain-bess-bgp-l3vpn-yang-02 849 (work in progress), August 2016. 851 [I-D.ietf-bess-evpn-yang] 852 Brissette, P., Sajassi, A., Shah, H., Li, Z., 853 Tiruveedhula, K., Hussain, I., and J. Rabadan, "Yang Data 854 Model for EVPN", draft-ietf-bess-evpn-yang-02 (work in 855 progress), March 2017. 857 [I-D.ietf-bess-l2vpn-yang] 858 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 859 and K. Tiruveedhula, "YANG Data Model for MPLS-based 860 L2VPN", draft-ietf-bess-l2vpn-yang-05 (work in progress), 861 March 2017. 863 [I-D.ietf-l2sm-l2vpn-service-model] 864 Wen, B., Fioccola, G., Xie, C., and L. Jalil, "A YANG Data 865 Model for L2VPN Service Delivery", draft-ietf-l2sm-l2vpn- 866 service-model-01 (work in progress), May 2017. 868 [MEF-55] MEF Forum, "Service Operations Specification MEF 55 : 869 Lifecycle Service Orchestration (LSO) Reference 870 Architecture and Framework", March 2016. 872 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 873 the Network Configuration Protocol (NETCONF)", RFC 6020, 874 DOI 10.17487/RFC6020, October 2010, 875 . 877 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 878 and A. Bierman, Ed., "Network Configuration Protocol 879 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 880 . 882 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 883 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 884 . 886 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 887 Connectivity Provisioning Profile (CPP)", RFC 7297, 888 DOI 10.17487/RFC7297, July 2014, 889 . 891 [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for 892 SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, 893 December 2014, . 895 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 896 Application-Based Network Operations", RFC 7491, 897 DOI 10.17487/RFC7491, March 2015, 898 . 900 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 901 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 902 . 904 Authors' Addresses 906 Qin Wu 907 Huawei Technologies 909 Email: bill.wu@huawei.com 911 Will Liu 912 Huawei Technologies 914 Email: liushucheng@huawei.com 916 Adrian Farrel 917 Juniper Networks 919 Email: afarrel@juniper.net