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