idnits 2.17.1 draft-ietf-opsawg-service-model-explained-02.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 (August 24, 2017) is 2436 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-bess-evpn-yang-02 == Outdated reference: A later version (-10) exists of draft-ietf-bess-l2vpn-yang-06 == Outdated reference: A later version (-10) exists of draft-ietf-l2sm-l2vpn-service-model-02 -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) -- Obsolete informational reference (is this intentional?): RFC 8049 (Obsoleted by RFC 8299) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPS Area Working Group Q. Wu 3 Internet-Draft W. Liu 4 Intended status: Informational Huawei Technologies 5 Expires: February 25, 2018 A. Farrel 6 Juniper Networks 7 August 24, 2017 9 Service Models Explained 10 draft-ietf-opsawg-service-model-explained-02 12 Abstract 14 The IETF has produced many data modules in the YANG modeling 15 language. The majority of these modules are used to construct data 16 models to model devices or monolithic functions. 18 A small number of YANG modules have been defined to model services 19 (for example, the Layer Three Virtual Private Network Service Model 20 produced by the L3SM working group and documented in RFC 8049). 22 This document describes service models as used within the IETF, and 23 also shows where a service model might fit into a Software Defined 24 Networking architecture. Note that service models do not make any 25 assumption of how a service is actually engineered and delivered for 26 a customer; details of how network protocols and devices are 27 engineered to deliver a service are captured in other models that are 28 not exposed through the Customer-Provider Interface. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on February 25, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terms and Concepts . . . . . . . . . . . . . . . . . . . . . 3 66 3. Using Service Models . . . . . . . . . . . . . . . . . . . . 6 67 4. Service Models in an SDN Context . . . . . . . . . . . . . . 8 68 5. Possible Causes of Confusion . . . . . . . . . . . . . . . . 10 69 6. Comparison With Other Work . . . . . . . . . . . . . . . . . 12 70 6.1. Comparison With Network Service Models . . . . . . . . . 12 71 6.2. Service Delivery and Network Element Model Work . . . . . 14 72 6.3. Customer Service Model Work . . . . . . . . . . . . . . . 14 73 6.4. The MEF Architecture . . . . . . . . . . . . . . . . . . 16 74 7. Further Concepts . . . . . . . . . . . . . . . . . . . . . . 17 75 7.1. Technology Agnostic . . . . . . . . . . . . . . . . . . . 17 76 7.2. Relationship to Policy . . . . . . . . . . . . . . . . . 17 77 7.3. Operator-Specific Features . . . . . . . . . . . . . . . 18 78 7.4. Supporting Multiple Services . . . . . . . . . . . . . . 18 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 80 9. Manageability Considerations . . . . . . . . . . . . . . . . 19 81 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 82 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 85 12.2. Informative References . . . . . . . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 88 1. Introduction 90 In recent years the number of data modules written in the YANG 91 modeling language [RFC6020] for configuration and monitoring has 92 blossomed. Many of these are used for device-level configuration 93 (for example, [RFC7223]) or for control of monolithic functions or 94 protocol instances (for example, [RFC7407]). 96 Within the context of Software Defined Networking (SDN) [RFC7149] 97 [RFC7426] YANG data models may be used on the interface between a 98 controller and network devices, and between network orchestrators and 99 controllers. There may also be a hierarchy of such components with 100 super controllers, domain controllers, and device controllers all 101 exchanging information and instructions using YANG models. 103 There has been interest in using YANG to define and document data 104 models that describe services in a portable way that is independent 105 of which network operator uses the model. For example, the Layer 106 Three Virtual Private Network Service Model (L3SM) [RFC8049]. Such 107 models may be used in manual and even paper-driven service request 108 processes with a gradual transition to IT-based mechanisms. 109 Ultimately they could be used in online, software-driven dynamic 110 systems, and eventually as part of an SDN system. 112 This document explains the scope and purpose of service models within 113 the IETF and describes how a service model can be used by a network 114 operator. Equally, this document clarifies what a service model is 115 not, and dispels some common misconceptions. 117 The document also shows where a service model might fit into an SDN 118 architecture, but it is important to note that a service model does 119 not require or preclude the use of SDN. Note that service models do 120 not make any assumption of how a service is actually engineered and 121 delivered to a customer; details of how network protocols and devices 122 are engineered to deliver a service are captured in other models that 123 are not exposed through the Customer-Provider Interface. 125 In summary, a service model is a formal representation of the data 126 elements that describe a network service as that service is described 127 to or requested by a customer of a network operator. Details 128 included in the service model include a description of the service as 129 experienced by the customer, but not features of how that service is 130 delivered or realized by the service provider. 132 Other work on classifying YANG data models has been done in 133 [RFC8199]. That document provides an important reference for this 134 document, and also uses the term "service model". Section 6.1 in 135 this document provides a comparison between these two uses of the 136 same terminology. 138 2. Terms and Concepts 140 Readers should familiarize themselves with the description and 141 classification of YANG models provided in [RFC8199]. 143 The following terms are used in this document: 145 Network Operator: This term is used to refer to the company that 146 owns and operates one or more networks that provide Internet 147 connectivity services and/or other services. 149 Customer: This term refers to someone who purchases a service 150 (including connectivity) from a network operator. In the context 151 of this document, a customer is usually a company that runs their 152 own network or computing platforms and wishes to connect to the 153 Internet or between sites. Such a customer may operate an 154 enterprise network or a data center. Sometimes this term may also 155 be used to refer to the individual in such a company who contracts 156 to buy services from a network operator. A customer as described 157 here is a separate commercial operation from the network operator, 158 but some companies may operate with internal customers so that, 159 for example, an IP/MPLS packet network may be the customer of an 160 optical transport network. 162 Service: A network operator delivers one or more services to a 163 customer. A service in the context of this document (sometimes 164 called a Network Service) is some form of connectivity between 165 customer sites and the Internet, or between customer sites across 166 the network operator's network and across the Internet. However, 167 a distinction should be drawn between the parameters that describe 168 a service as included in a customer service model (q.v.) and a 169 Service Level Agreement (SLA) as discussed in Section 5 and 170 Section 7.2. 172 A service may be limited to simple connectivity (such as IP-based 173 Internet access), may be a tunnel (such as a virtual circuit), or 174 may be a more complex connectivity model (such as a multi-site 175 virtual private network). Services may be further enhanced by 176 additional functions providing security, load-balancing, 177 accounting, and so forth. Additionally, services usually include 178 guarantees of quality, throughput, and fault reporting. 180 This document makes a distinction between a service as delivered 181 to a customer (that is, the service as discussed on the interface 182 between a customer and the network operator) and the service as 183 realized within the network (as described in [RFC8199]). This 184 distinction is discussed further in Section 6. 186 Readers may also refer to [RFC7297] for an example of how an IP 187 connectivity service may be characterized. 189 Data Model: The concepts of information models and data models are 190 described in [RFC3444]. That document defines a data model by 191 contrasting it with the definition of an information model as 192 follows: 194 The main purpose of an information model is to model managed 195 objects at a conceptual level, independent of any specific 196 implementations or protocols used to transport the data. The 197 degree of specificity (or detail) of the abstractions defined 198 in the information model depends on the modeling needs of its 199 designers. In order to make the overall design as clear as 200 possible, an information model should hide all protocol and 201 implementation details. Another important characteristic of an 202 information model is that it defines relationships between 203 managed objects. 205 Data models, conversely, are defined at a lower level of 206 abstraction and include many details. They are intended for 207 implementors and include protocol-specific constructs. 209 Service Model: A service model is a specific type of data model. It 210 describes a service and the parameters of the service in a 211 portable way. The service model may be divided into two 212 categories: 214 Customer Service Model: A customer service model is used to 215 describe a service as offered or delivered to a customer by a 216 network operator. It can be used by a human (via a user 217 interface such as a GUI, web form, or CLI) or by software to 218 configure or request a service, and may equally be consumed by 219 a human (such as via an order fulfillment system) or by a 220 software component. Such models are sometimes referred to 221 simply as "service models" [RFC8049]. A customer service model 222 is expressed as a core set of parameters that are common across 223 network operators: additional features that are specific to the 224 offerings of individual network operators would be defined in 225 extensions or augmentations of the model. Except where 226 specific technology details (such as encapsulations, or 227 mechanisms applied on access links) are directly pertinent to 228 the customer, customer service models are technology agnostic 229 so that the customer does not have influence over or knowledge 230 of how the network operator engineers the service. 232 An example of where such details are relevant to the customer 233 are when they describe the behavior or interactions on the 234 interface between the equipment at the customer site (often 235 referred to as the Customer Edge or CE equipment) and the 236 equipment at the network operator's site (usually referred to 237 as the Provider Edge or PE equipment). 239 Service Delivery Model: A service delivery model is used by a 240 network operator to define and manage how a service is 241 engineered in the network. It can be used by a human operator 242 (such as via a management station) or by a software tool to 243 instruct network components. Such models are sometimes 244 referred to as "network service models" [RFC8199] and are 245 consumed by "external systems" such as Operations Support 246 System (OSS). A service delivery model is expressed as a core 247 set of parameters that are common across a network type and 248 technology: additional features that are specific to the 249 configuration of individual vendor equipment or proprietary 250 protocols would be defined in extensions or augmentations of 251 the model. Service delivery models include technology-specific 252 modules. 254 The distinction between a customer service model and a service 255 delivery model needs to be repeatedly clarified. A customer service 256 model is not a data model used to directly configure network devices, 257 protocols, or functions: it is not something that is sent to network 258 devices (i.e., routers or switches) for processing. Equally, a 259 customer service model is not a data model that describes how a 260 network operator realizes and delivers the service described by the 261 model. This distinction is discussed further in later sections. 263 3. Using Service Models 265 As already indicated, customer service models are used on the 266 interface between customers and network operators. This is shown 267 simply in Figure 1. 269 The language in which a customer service model is described is a 270 choice for whoever specifies the model. The IETF uses the YANG data 271 modeling language defined in [RFC6020]. 273 The encoding and communication protocol used to exchange a customer 274 service model between customer and network operator are deployment- 275 and implementation-specific. The IETF has standardized the NETCONF 276 protocol [RFC6241] and the RESTCONF protocol [RFC8040] for 277 interactions "on the wire" between software components with data 278 encoded in XML or JSON. However, co-located software components 279 might use an internal API, while systems with more direct human 280 interactions might use web pages or even paper forms. 282 -------------- Customer ---------------------- 283 | | Service Model | | 284 | Customer | <-----------------> | Network Operator | 285 | | | | 286 -------------- ---------------------- 288 Figure 1: The Customer Service Models used on the Interface between 289 Customers and Network Operators 291 How a network operator processes a customer's service request 292 described with a customer service model depends on the commercial and 293 operational tools, processes, and policies used by the network 294 operator. These may vary considerably from one network operator to 295 another. 297 However, the intent is that the network operator maps the service 298 request into configuration and operational parameters that control 299 one or more networks to deliver the requested services. That means 300 that the network operator (or software run by the network operator) 301 takes the information in the customer service model and determines 302 how to deliver the service by enabling and configuring network 303 protocols and devices. They may achieve this by constructing service 304 delivery models and passing them to network orchestrators or 305 controllers. The use of standard customer service models eases 306 service delivery by means of automation. 308 The practicality of customer service models has been repeatedly 309 debated. It has been suggested that network operators have radically 310 different business modes and widely diverse commercial offerings 311 making a common customer service model is impractical. However, the 312 L3SM [RFC8049] results from the consensus of multiple individuals 313 working at network operators and offers a common core of service 314 options that can be augmented according to the needs of individual 315 network operators. 317 It has also been suggested that there should be a single, base 318 customer service module, and that details of individual services 319 should be offered as extensions or augmentations of this. It is 320 quite possible that a number of service parameters (such as the 321 identity and postal address of a customer) will be common and it 322 would be a mistake to define them multiple times, once in each 323 customer service model. However, the distinction between a 'module' 324 and a 'model' should be considered at this point: modules are how the 325 data for models is logically broken out and documented especially for 326 re-use in multiple models. 328 4. Service Models in an SDN Context 330 In an SDN system, the management of network resources and protocols 331 is performed by software systems that determine how best to utilize 332 the network. Figure 2 shows a sample architectural view of an SDN 333 system where network elements are programmed by a component called an 334 "SDN controller" (or "controller" for short), and where controllers 335 are instructed by an orchestrator that has a wider view of the whole 336 of, or part of, a network. The internal organization of an SDN 337 control plane is deployment-specific. 339 ------------------ 340 | | 341 | Orchestrator | 342 | | 343 .------------------. 344 . : . 345 . : . 346 ------------ ------------ ------------ 347 | | | | | | 348 | Controller | | Controller | | Controller | 349 | | | | | | 350 ------------ ------------ ------------ 351 : . . : 352 : . . : 353 : . . : 354 --------- --------- --------- --------- 355 | Network | | Network | | Network | | Network | 356 | Element | | Element | | Element | | Element | 357 --------- --------- --------- --------- 359 Figure 2: A Sample SDN Architecture 361 But a customer's service request is (or should be) technology- 362 agnostic. That is, there should be an independence between the 363 behavior and functions that a customer requests and the technology 364 that the network operator has available to deliver the service. The 365 orchestrator must map the service request to its view, and this 366 mapping may include a choice of which networks and technologies to 367 use depending on which service features have been 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 . . (b) ----------- 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 Figure 1 of [RFC7491] shows an interface between an "Application 425 Service Coordinator" and an "Application-Based Network Operations 426 Controller". 428 o Figure 1 of [RFC8199] shows an interface from an OSS or a Business 429 Support System (BSS) that is expressed in "Network Service YANG 430 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. [RFC8199] also terms these data 481 models as "service models" or "Network Service YANG Models" and a 482 comparison is provided in Section 6.1. It is important that the 483 Service Orchestrator should be able to map from a customer service 484 model to these service delivery models, but they are not the same 485 things. 487 o Commercial terms are generally not a good subject for 488 standardization. It is possible that some network operators will 489 enhance standard customer service models to include commercial 490 information, but the way this is done is likely to vary widely 491 between network operators. Thus, this feature is out of scope for 492 standardized customer service models. 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. As with commercial terms, it is expected that 504 some network operators will enhance standard customer service 505 models to include SLA parameters either using their own work or 506 depending on material from standards bodies that specialize in 507 this topic, but this feature is out of scope for the IETF's 508 customer service models. 510 If a network operator chooses to express an SLA using a data 511 model, that model might be referenced as an extension or an 512 augmentation of the customer service model. 514 6. Comparison With Other Work 516 Other work has classified YANG models, produced parallel 517 architectures, and developed a range of YANG models. This section 518 briefly examines that other work and shows how it fits with the 519 description of service models introduced in this document. 521 6.1. Comparison With Network Service Models 523 As previously noted, [RFC8199] provides a classification of YANG data 524 models. It introduces the term "Network Service YANG Module" to 525 identify the type of model used to "describe the configuration, state 526 data, operations and notifications of abstract representations of 527 services implemented on one or multiple network elements." These are 528 service delivery models as described in this document, that is, they 529 are the models used on the interface between the Service Orchestrator 530 or OSS/BSS and the Network Orchestrator as shown in Figure 3. 532 Figure 1 of [RFC8199] can be modified to make this more clear and to 533 add an additional example of a Network Service YANG model as shown in 534 Figure 4. This figure illustrates a functional architecture and an 535 implementation might choose to make different distinctions and 536 separations between components so that the functional units and 537 interfaces illustrated might fall within a single implementation. 539 +---------------+ 540 | | 541 | Customers | 542 | | 543 +---------------+ 545 - - - - - - - - - - - - - - 546 Customer Service YANG Modules 548 +-------------------------------------------------------+ 549 | | 550 | +----------------------+ | 551 | | | Operations and Business | 552 | | Service Orchestrator | Support Systems | 553 | | | (OSS/BSS) | 554 | +----------------------+ | 555 | | 556 | | 557 +-------------------------------------------------------+ 559 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 560 Network Service YANG Modules 562 +------------+ +-------------+ +-------------+ +-------------+ 563 | | | | | | | | 564 | - L2VPN | | - L2VPN | | EVPN | | L3VPN | 565 | - VPWS | | - VPLS | | | | | 566 | | | | | | | | 567 +------------+ +-------------+ +-------------+ +-------------+ 569 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 570 Network Element YANG Modules 572 +------------+ +------------+ +-------------+ +------------+ 573 | | | | | | | | 574 | MPLS | | BGP | | IPv4 / IPv6 | | Ethernet | 575 | | | | | | | | 576 +------------+ +------------+ +-------------+ +------------+ 578 L2VPN: Layer 2 Virtual Private Network 579 L3VPN: Layer 3 Virtual Private Network 580 VPWS: Virtual Private Wire Service 581 VPLS: Virtual Private LAN Service 583 Figure 4: YANG Module Layers Showing Service Models 585 6.2. Service Delivery and Network Element Model Work 587 A number of IETF working groups are developing YANG models related to 588 services. These models focus on how the network operator configures 589 the network through protocols and devices to deliver a service. Some 590 of these models are classified as service delivery models while 591 others have details that are related to specific element 592 configuration and so are classed as network element models (also 593 called device models). 595 A sample set of these models is listed here: 597 o [I-D.dhjain-bess-bgp-l3vpn-yang] defines a YANG model that can be 598 used to configure and manage BGP L3VPNs. 600 o [I-D.ietf-bess-l2vpn-yang] documents a YANG model that it is 601 expected will be used by the management tools run by the network 602 operators in order to manage and monitor the network resources 603 that they use to deliver L2VPN services. 605 o [I-D.ietf-bess-evpn-yang] defines YANG models for delivering an 606 Ethernet VPN service. 608 6.3. Customer Service Model Work 610 Several initiatives within the IETF are developing customer service 611 models. The most advanced presents the L3VPN service as described by 612 a network operator to a customer. The L3SM is described as in 613 Figure 5 which is reproduced from [RFC8049]. As can be seen, the 614 L3SM is a customer service model as described in this document. 616 L3VPN-SVC | 617 MODEL | 618 | 619 +------------------+ +-----+ 620 | Orchestration | < --- > | OSS | 621 +------------------+ +-----+ 622 | | 623 +----------------+ | 624 | Config manager | | 625 +----------------+ | 626 | | 627 | Netconf/CLI ... 628 | | 629 +------------------------------------------------+ 630 Network 632 Figure 5: The L3SM Service Architecture 634 A Layer Two VPN service model (L2SM) is defined in 635 [I-D.ietf-l2sm-l2vpn-service-model]. That model's usage is described 636 as in Figure 6 which is a reproduction of Figure 5 from that 637 document. As can be seen, the L2SM is a customer service model as 638 described in this document. 640 ---------------------------- 641 | Customer Service Requester | 642 ---------------------------- 643 | 644 L2VPN | 645 Service | 646 Model | 647 | 648 ----------------------- 649 | Service Orchestration | 650 ----------------------- 651 | 652 | Service +-------------+ 653 | Delivery +------>| Application | 654 | Model | | BSS/OSS | 655 | V +-------------+ 656 ----------------------- 657 | Network Orchestration | 658 ----------------------- 659 | | 660 +----------------+ | 661 | Config manager | | 662 +----------------+ | Device 663 | | Models 664 | | 665 -------------------------------------------- 666 Network 668 Figure 6: The L2SM Service Architecture 670 6.4. The MEF Architecture 672 The MEF Forum has developed an architecture for network management 673 and operation. It is documented as the Lifecycle Service 674 Orchestration (LSO) Reference Architecture and illustrated in 675 Figure 2 of [MEF-55]. 677 The work of the MEF Forum embraces all aspects of Lifecycle Service 678 Orchestration including billing, SLAs, order management, and life- 679 cycle management. The IETF's work on service models is typically 680 smaller offering a simple, self-contained service YANG module. Thus, 681 it may be impractical to fit IETF service models into the MEF Forum 682 LSO architecture. This does not invalidate either approach, but only 683 observes that they are different. 685 7. Further Concepts 687 This section introduces a few further, more advanced concepts 689 7.1. Technology Agnostic 691 Service models should generally be technology agnostic. That is to 692 say, the customer should not care how the service is provided so long 693 as the service is delivered. 695 However, some technologies reach the customer site and make a 696 difference to the type of service delivered. Such features do need 697 to be described in the service model. 699 Two examples are: 701 o The data passed between customer equipment and network operator 702 equipment will be encapsulated in a specific way, and that data 703 plane type forms part of the service. 705 o Protocols that are run between customer equipment and network 706 operator equipment (for example, Operations, Administration, and 707 Maintenance protocols, protocols for discovery, or protocols for 708 exchanging routing information) need to be selected and configured 709 as part of the service description. 711 7.2. Relationship to Policy 713 Policy appears as a crucial function in many places during network 714 orchestration. A Service Orchestrator will, for example, apply the 715 network operator's policies to determine how to provide a service for 716 a particular customer (possibly considering commercial terms). 717 However, the policies within a service model are limited to those 718 over which a customer has direct influence and that are acted on by 719 the network operator. 721 The policies that express desired behavior of services on occurrence 722 of specific events are close to SLA definitions: they should only be 723 included in the base service model where they are common to all 724 network operators' offerings. Policies that describe who at a 725 customer may request or modify services (that is, authorization) are 726 close to commercial terms: they, too, should only be included in the 727 base service model where they are common to all network operators' 728 offerings. 730 As with commercial terms and SLAs discussed in Section 5 it is 731 expected that some network operators will enhance standard customer 732 service models to include policy parameters either using their own 733 work or depending on specific policy models built in the IETF or 734 other standards bodies. 736 Nevertheless, policy is so important that all service models should 737 be designed to be easily extensible to allow policy components to be 738 added and associated with services as needed. 740 7.3. Operator-Specific Features 742 When work on the L3SM was started, there was some doubt as to whether 743 network operators would be able to agree on a common description of 744 the services that they offer to their customers because, in a 745 competitive environment, each markets the services in a different way 746 with different additional features. However, the working group was 747 able to agree on a core set of features that multiple network 748 operators were willing to consider as "common". They also understood 749 that should an individual network operator want to describe 750 additional features (operator-specific features) they could do so by 751 extending or augmenting the L3SM model. 753 Thus, when a basic description of a core service is agreed and 754 documented in a service model, it is important that that model should 755 be easily extended or augmented by each network operator so that the 756 standardized model can be used in a common way and only the operator- 757 specific features varied from one environment to another. 759 7.4. Supporting Multiple Services 761 Network operators will, in general, offer many different services to 762 their customers. Each would normally be the subject of a separate 763 service model. 765 It is an implementation and deployment choice whether all service 766 models are processed by a single Service Orchestrator that can 767 coordinate between the different services, or whether each service 768 model is handled by a specialized Service Orchestrator able to 769 provide tuned behavior for a specific service. 771 It is expected that, over time, certain elements of the service 772 models will be seen to repeat in each model. An example of such an 773 element is the postal address of the customer. 775 It is anticipated that, while access to such information from each 776 service model is important, the data will be described in its own 777 module and may form part of the service model either by inclusion or 778 by index. 780 8. Security Considerations 782 The interface between customer and service provider is a commercial 783 interface and needs to be subject to appropriate confidentiality. 784 Additionally, knowledge of what services are provided to a customer 785 or delivered by a network operator may supply information that can be 786 used in a variety of security attacks. 788 Clearly, the ability to modify information exchanges between customer 789 and network operator may result in bogus requests, unwarranted 790 billing, and false expectations. Furthermore, in an automated 791 system, modifications to service requests or the injection of bogus 792 requests may lead to attacks on the network and delivery of customer 793 traffic to the wrong place. 795 Therefore it is important that the protocol interface used to 796 exchange service request information between customer and network 797 operator is subject to authorization, authentication, and encryption. 798 Equally, all external intefaces, such as any of those between the 799 functional components in Figure 3 needs to be correctly secured. 801 This document discusses modeling the information, not how it is 802 exchanged. 804 9. Manageability Considerations 806 This whole document discusses issues related to network management 807 and control. 809 It is important to observe that automated service provisioning 810 resulting from use of a customer service model may result in rapid 811 and significant changes in traffic load within a network and that 812 that might have an effect on other services carried in a network. 814 It is expected, therefore, that a Service Orchestration component has 815 awareness of other service commitments, that the Network 816 Orchestration component will not commit network resources to fulfill 817 a service unless doing so is appropriate, and that a feedback loop 818 will be provided to report on degradation of the network that will 819 impact the service. 821 The operational state of a service does not form part of a customer 822 service model. However, it is likely that a network operator may 823 want to report some state information about various components of the 824 service, and that could be achieved through extensions to the core 825 service model just as SLA extensions could be made as described in 826 Section 5. 828 10. IANA Considerations 830 This document makes no requests for IANA action 832 11. Acknowledgements 834 Thanks to Daniel King, Xian Zhang, Michael Scharf, Med Boucadair, and 835 Luis Miguel Contreras Murillo for useful review and comments. 837 Thanks to Dean Bogdanovic, Tianran Zhou, and Carl Moberg for their 838 help coordinating with [RFC8199]. 840 Many thanks to Jerry Bonner for spotting a tiny, one-word, but 841 critical typo. 843 12. References 845 12.1. Normative References 847 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 848 Information Models and Data Models", RFC 3444, 849 DOI 10.17487/RFC3444, January 2003, . 852 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 853 Classification", RFC 8199, DOI 10.17487/RFC8199, July 854 2017, . 856 12.2. Informative References 858 [I-D.dhjain-bess-bgp-l3vpn-yang] 859 Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., 860 Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model 861 for BGP/MPLS L3 VPNs", draft-dhjain-bess-bgp-l3vpn-yang-02 862 (work in progress), August 2016. 864 [I-D.ietf-bess-evpn-yang] 865 Brissette, P., Sajassi, A., Shah, H., Li, Z., 866 Tiruveedhula, K., Hussain, I., and J. Rabadan, "Yang Data 867 Model for EVPN", draft-ietf-bess-evpn-yang-02 (work in 868 progress), March 2017. 870 [I-D.ietf-bess-l2vpn-yang] 871 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 872 and K. Tiruveedhula, "YANG Data Model for MPLS-based 873 L2VPN", draft-ietf-bess-l2vpn-yang-06 (work in progress), 874 June 2017. 876 [I-D.ietf-l2sm-l2vpn-service-model] 877 Wen, B., Fioccola, G., Xie, C., and L. Jalil, "A YANG Data 878 Model for L2VPN Service Delivery", draft-ietf-l2sm-l2vpn- 879 service-model-02 (work in progress), July 2017. 881 [MEF-55] MEF Forum, "Service Operations Specification MEF 55 : 882 Lifecycle Service Orchestration (LSO) Reference 883 Architecture and Framework", March 2016. 885 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 886 the Network Configuration Protocol (NETCONF)", RFC 6020, 887 DOI 10.17487/RFC6020, October 2010, . 890 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 891 and A. Bierman, Ed., "Network Configuration Protocol 892 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 893 . 895 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 896 Networking: A Perspective from within a Service Provider 897 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 898 . 900 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 901 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 902 . 904 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 905 Connectivity Provisioning Profile (CPP)", RFC 7297, 906 DOI 10.17487/RFC7297, July 2014, . 909 [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for 910 SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, 911 December 2014, . 913 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 914 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 915 Defined Networking (SDN): Layers and Architecture 916 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 917 2015, . 919 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 920 Application-Based Network Operations", RFC 7491, 921 DOI 10.17487/RFC7491, March 2015, . 924 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 925 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 926 . 928 [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 929 Model for L3VPN Service Delivery", RFC 8049, 930 DOI 10.17487/RFC8049, February 2017, . 933 Authors' Addresses 935 Qin Wu 936 Huawei Technologies 938 Email: bill.wu@huawei.com 940 Will Liu 941 Huawei Technologies 943 Email: liushucheng@huawei.com 945 Adrian Farrel 946 Juniper Networks 948 Email: afarrel@juniper.net