--- 1/draft-ietf-opsawg-service-model-explained-04.txt 2017-10-12 15:13:09.050903228 -0700 +++ 2/draft-ietf-opsawg-service-model-explained-05.txt 2017-10-12 15:13:09.098904370 -0700 @@ -1,20 +1,20 @@ OPS Area Working Group Q. Wu Internet-Draft W. Liu Intended status: Informational Huawei Technologies -Expires: March 31, 2018 A. Farrel +Expires: April 15, 2018 A. Farrel Juniper Networks - September 27, 2017 + October 12, 2017 Service Models Explained - draft-ietf-opsawg-service-model-explained-04 + draft-ietf-opsawg-service-model-explained-05 Abstract The IETF has produced many modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions. A small number of YANG modules have been defined to model services (for example, the Layer Three Virtual Private Network Service Model produced by the L3SM working group and documented in RFC 8049). @@ -35,21 +35,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 31, 2018. + This Internet-Draft will expire on April 15, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -57,46 +57,48 @@ to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terms and Concepts . . . . . . . . . . . . . . . . . . . . . 4 3. Using Service Models . . . . . . . . . . . . . . . . . . . . 6 + 3.1. Practical Considerations . . . . . . . . . . . . . . . . 8 4. Service Models in an SDN Context . . . . . . . . . . . . . . 8 - 5. Possible Causes of Confusion . . . . . . . . . . . . . . . . 10 - 6. Comparison With Other Work . . . . . . . . . . . . . . . . . 12 - 6.1. Comparison With Network Service Models . . . . . . . . . 12 - 6.2. Service Delivery and Network Element Model Work . . . . . 14 - 6.3. Customer Service Model Work . . . . . . . . . . . . . . . 14 - 6.4. The MEF Architecture . . . . . . . . . . . . . . . . . . 16 - 7. Further Concepts . . . . . . . . . . . . . . . . . . . . . . 17 - 7.1. Technology Agnostic . . . . . . . . . . . . . . . . . . . 17 - 7.2. Relationship to Policy . . . . . . . . . . . . . . . . . 17 - 7.3. Operator-Specific Features . . . . . . . . . . . . . . . 18 - 7.4. Supporting Multiple Services . . . . . . . . . . . . . . 18 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 - 9. Manageability Considerations . . . . . . . . . . . . . . . . 19 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 - 12.2. Informative References . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 + 5. Possible Causes of Confusion . . . . . . . . . . . . . . . . 11 + 6. Comparison With Other Work . . . . . . . . . . . . . . . . . 13 + 6.1. Comparison With Network Service Models . . . . . . . . . 13 + 6.2. Service Delivery and Network Element Model Work . . . . . 15 + 6.3. Customer Service Model Work . . . . . . . . . . . . . . . 15 + 6.4. The MEF Architecture . . . . . . . . . . . . . . . . . . 17 + 7. Further Concepts . . . . . . . . . . . . . . . . . . . . . . 18 + 7.1. Technology Agnostic . . . . . . . . . . . . . . . . . . . 18 + 7.2. Relationship to Policy . . . . . . . . . . . . . . . . . 18 + 7.3. Operator-Specific Features . . . . . . . . . . . . . . . 19 + 7.4. Supporting Multiple Services . . . . . . . . . . . . . . 19 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 9. Manageability Considerations . . . . . . . . . . . . . . . . 20 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 + 12.2. Informative References . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction In recent years the number of modules written in the YANG modeling language [RFC6020] for configuration and monitoring has blossomed. Many of these are used for device-level configuration (for example, + [RFC7223]) or for control of monolithic functions or protocol instances (for example, [RFC7407]). [RFC7950] makes a distinction between a "data model" which it defines as describing how data is represented and accessed, and a "YANG module" that defines hierarchies of schema nodes to make a self- contained and compilable block of definitions and inclusions. YANG structures data models into modules for ease of use. Within the context of Software Defined Networking (SDN) [RFC7149] @@ -106,34 +108,36 @@ super controllers, domain controllers, and device controllers all exchanging information and instructions using YANG modules. There has been interest in using YANG to define and document data models that describe services in a portable way that is independent of which network operator uses the model. For example, the Layer Three Virtual Private Network Service Model (L3SM) [RFC8049]. Such models may be used in manual and even paper-driven service request processes with a gradual transition to IT-based mechanisms. Ultimately they could be used in online, software-driven dynamic - systems, and eventually as part of an SDN system. + systems, and may be used as part of an SDN system. This document explains the scope and purpose of service models within - the IETF and describes how a service model can be used by a network - operator. Equally, this document clarifies what a service model is - not, and dispels some common misconceptions. + the IETF (and limited to within the scope of the IETF) and describes + how a service model can be used by a network operator. Equally, this + document clarifies what a service model is not, and dispels some + common misconceptions. The document also shows where a service model might fit into an SDN architecture, but it is important to note that a service model does not require or preclude the use of SDN. Note that service models do not make any assumption of how a service is actually engineered and delivered to a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules - that are not exposed through the Customer-Provider Interface. + that are not exposed through the interface betweeen the customer and + the provider. In summary, a service model is a formal representation of the data elements that describe a network service as that service is described to or requested by a customer of a network operator. Details included in the service model include a description of the service as experienced by the customer, but not features of how that service is delivered or realized by the service provider. Other work on classifying YANG modules has been done in [RFC8199]. That document provides an important reference for this document, and @@ -209,41 +213,42 @@ Data models, conversely, are defined at a lower level of abstraction and include many details. They are intended for implementors and include protocol-specific constructs. As mentioned in Section 1, this document also uses the terms "data model" and "YANG module" as defined in [RFC7950]. Service Model: A service model is a specific type of data model. It describes a service and the parameters of the service in a - portable way. The service model may be divided into two - categories: + portable way that can be used uniformly independent of the + equipment and operating environment. The service model may be + divided into two categories: Customer Service Model: A customer service model is used to describe a service as offered or delivered to a customer by a - network operator. It can be used by a human (via a user - interface such as a GUI, web form, or CLI) or by software to - configure or request a service, and may equally be consumed by - a human (such as via an order fulfillment system) or by a - software component. Such models are sometimes referred to - simply as "service models" [RFC8049]. A customer service model - is expressed in a YANG module as a core set of parameters that - are common across network operators: additional features that - are specific to the offerings of individual network operators - would be defined in extensions or augmentations of the module. - Except where specific technology details (such as - encapsulations, or mechanisms applied on access links) are - directly pertinent to the customer, customer service models are - technology agnostic so that the customer does not have - influence over or knowledge of how the network operator - engineers the service. + network operator as shown in Figure 1. It can be used by a + human (via a user interface such as a GUI, web form, or CLI) or + by software to configure or request a service, and may equally + be consumed by a human (such as via an order fulfillment + system) or by a software component. Such models are sometimes + referred to simply as "service models" [RFC8049]. A customer + service model is expressed in a YANG module as a core set of + parameters that are common across network operators: additional + features that are specific to the offerings of individual + network operators would be defined in extensions or + augmentations of the module. Except where specific technology + details (such as encapsulations, or mechanisms applied on + access links) are directly pertinent to the customer, customer + service models are technology agnostic so that the customer + does not have influence over or knowledge of how the network + operator engineers the service. An example of where such details are relevant to the customer is when they describe the behavior or interactions on the interface between the equipment at the customer site (often referred to as the Customer Edge or CE equipment) and the equipment at the network operator's site (usually referred to as the Provider Edge or PE equipment). Service Delivery Model: A service delivery model is used by a network operator to define and manage how a service is @@ -256,44 +261,49 @@ is expressed as a core set of parameters that are common across a network type and technology: additional features that are specific to the configuration of individual vendor equipment or proprietary protocols would be defined in extensions or augmentations of the module. Service delivery modules include technology-specific modules. The distinction between a customer service model and a service delivery model needs to be clarified. The modules that encode a customer service model are not used to directly configure network - devices, protocols, or functions: it is not something that is sent to - network devices (i.e., routers or switches) for processing. Equally, - the modules that encode a customer service model do not describes how - a network operator realizes and delivers the service described by the - module. This distinction is discussed further in later sections. + devices, protocols, or functions: it is not something that is sent + to network devices (i.e., routers or switches) for processing. + Equally, the modules that encode a customer service model do not + describes how a network operator realizes and delivers the service + described by the module. This distinction is discussed further in + later sections. 3. Using Service Models As already indicated, customer service models are used on the interface between customers and network operators. This is shown simply in Figure 1. The language in which a customer service model is described is a choice for whoever specifies the model. The IETF uses the YANG data modeling language defined in [RFC6020]. The encoding and communication protocol used to exchange a customer service model between customer and network operator are deployment- and implementation-specific. The IETF has standardized the NETCONF protocol [RFC6241] and the RESTCONF protocol [RFC8040] for interactions "on the wire" between software components with data encoded in XML or JSON. However, co-located software components might use an internal API, while systems with more direct human - interactions might use web pages or even paper forms. + interactions might use web pages or even paper forms. Where direct + human interaction comes into play, interface interactions may be + realized via business practices and that may introduce some margin of + error, thus raising the priority for automated, deterministic + interfaces. -------------- Customer ---------------------- | | Service Model | | | Customer | <-----------------> | Network Operator | | | | | -------------- ---------------------- Figure 1: The Customer Service Models used on the Interface between Customers and Network Operators @@ -307,20 +317,22 @@ request into configuration and operational parameters that control one or more networks to deliver the requested services. That means that the network operator (or software run by the network operator) takes the information in the customer service model and determines how to deliver the service by enabling and configuring network protocols and devices. They may achieve this by constructing service delivery models and passing them to network orchestrators or controllers. The use of standard customer service models eases service delivery by means of automation. +3.1. Practical Considerations + The practicality of customer service models has been repeatedly debated. It has been suggested that network operators have radically different business modes and widely diverse commercial offerings making a common customer service model is impractical. However, the L3SM [RFC8049] results from the consensus of multiple individuals working at network operators and offers a common core of service options that can be augmented according to the needs of individual network operators. It has also been suggested that there should be a single, base @@ -329,28 +341,28 @@ quite possible that a number of service parameters (such as the identity and postal address of a customer) will be common and it would be a mistake to define them multiple times, once in each customer service model. However, the distinction between a 'module' and a 'model' should be considered at this point: modules are how the data for models is logically broken out and documented especially for re-use in multiple models. 4. Service Models in an SDN Context - In an SDN system, the management of network resources and protocols - is performed by software systems that determine how best to utilize - the network. Figure 2 shows a sample architectural view of an SDN - system where network elements are programmed by a component called an - "SDN controller" (or "controller" for short), and where controllers - are instructed by an orchestrator that has a wider view of the whole - of, or part of, a network. The internal organization of an SDN - control plane is deployment-specific. + In a Software Defined Networking (SDN) system, the management of + network resources and protocols is performed by software systems that + determine how best to utilize the network. Figure 2 shows a sample + architectural view of an SDN system where network elements are + programmed by a component called an "SDN controller" (or "controller" + for short), and where controllers are instructed by an orchestrator + that has a wider view of the whole of, or part of, a network. The + internal organization of an SDN control plane is deployment-specific. ------------------ | | | Orchestrator | | | .------------------. . : . . : . ------------ ------------ ------------ | | | | | | @@ -360,27 +372,29 @@ : . . : : . . : : . . : --------- --------- --------- --------- | Network | | Network | | Network | | Network | | Element | | Element | | Element | | Element | --------- --------- --------- --------- Figure 2: A Sample SDN Architecture - But a customer's service request is (or should be) technology- - agnostic. That is, the technology that the network operator has - available to deliver the service should not influence the behavior - and functions that a customer requests. The orchestrator must map - the service request to its view, and this mapping may include a - choice of which networks and technologies to use depending on which - service features have been requested. + A customer's service request is (or should be) technology-agnostic. + That is, a customer is unware of the technology that the network + operator has available to deliver the service and so the customer + does not make requests specific to the underlying technology, but is + limited to making requests specific to the service that is to be + delivered. The orchestrator must map the service request to its + view, and this mapping may include a choice of which networks and + technologies to use depending on which service features have been + requested. One implementation option to achieve this mapping is to split the orchestration function between a "Service Orchestrator" and a "Network Orchestrator" as shown in Figure 3. Customer ------------------ Service ---------- | | Model | | | Service |<-------->| Customer | | Orchestrator | (a) | | @@ -413,22 +427,22 @@ : . . Model : : --------- --------- --------- --------- --------- | Network | | Network | | Network | | Network | | Network | | Element | | Element | | Element | | Element | | Element | --------- --------- --------- --------- --------- Figure 3: An Example SDN Architecture with a Service Orchestrator Figure 3 also shows where different data models might be applied within the architecture. The Device Confguration Models are used by - a Controller to seet parameters on an individual network element. - The Network Configuration Models are use by a Network Orchestrator to + a Controller to set parameters on an individual network element. The + Network Configuration Models are use by a Network Orchestrator to instruct Controllers (that may each be responsible for multiple network elements) how to configure parts of a network. The split between control components that exposes a "service interface" that is present in many figures showing extended SDN architectures: o Figure 1 of [RFC7426] shows a separation of the "Application Plane", the "Network Services Abstraction Layer (NSAL)", and the "Control Plane". It marks the "Service Interface" as situated @@ -464,55 +478,57 @@ network resources of the operator's network. This is a completely different thing to "Foo as a Service" (for example, Storage as a Service (SaaS)) where a service provider offers reachability to a value-added service that is provided at some location in the network using other resources (compute, storage, ...) that are not part of the network itself. The confusion arises not only because of the use of the word "service" in both cases, but also because network operators may offer both types of service to their customers. - o Network operation is completely out of scope in the discussion of + o Network operation is normally out of scope in the discussion of services between a network operator and a customer. That means that the customer service model does not reveal to the customer - anything about how the network operator delivers the service. The - model does not expose details of technology or network resources - used to provide the service. For example, in the simple case of - point-to-point virtual link connectivity provided by a network - tunnel (such as an MPLS pseudowire) the network operator does not - expose the path through the network that the tunnel follows. Of - course, this does not preclude the network operator from taking - guidance from the customer (such as to avoid routing traffic - through a particular country) or from disclosing specific details - (such as might be revealed by a route trace), but these are not - standard features of the service as described in the customer - service model. + anything about how the network operator delivers the service, nor + does the model expose details of technology or network resources + used to provide the service (all of these details could, in any + case, be considered seecurity vulnerabilities. For example, in + the simple case of point-to-point virtual link connectivity + provided by a network tunnel (such as an MPLS pseudowire) the + network operator does not expose the path through the network that + the tunnel follows. Of course, this does not preclude the network + operator from taking guidance from the customer (such as to avoid + routing traffic through a particular country) or from disclosing + specific details (such as might be revealed by a route trace), but + these are not standard features of the service as described in the + customer service model. o The network operator may use further data models (service delivery models) that help to describe how the service is realized in the network. These models might be used on the interface between the Service Orchestrator and the Network Orchestrator as shown in Figure 3 and might include many of the pieces of information from the customer service model alongside protocol parameters and device configuration information. [RFC8199] also terms these data models as "service models" and encode them as "Network Service YANG Modules" and a comparison is provided in Section 6.1. It is important that the Service Orchestrator should be able to map from a customer service model to these service delivery models, but they are not the same things. - o Commercial terms are generally not a good subject for - standardization. It is possible that some network operators will - enhance standard customer service models to include commercial - information, but the way this is done is likely to vary widely - between network operators. Thus, this feature is out of scope for - standardized customer service models. + o Commercial terms (such as cost per byte, per minute, scoped by + quality and type of service, and related to payment terms) are + generally not a good subject for standardization. It is possible + that some network operators will enhance standard customer service + models to include commercial information, but the way this is done + is likely to vary widely between network operators. Thus, this + feature is out of scope for standardized customer service models. o Service Level Agreements (SLAs) have a high degree of overlap with the definition of services present in customer service models. Requests for specific bandwidth, for example, might be present in a customer service model, and agreement to deliver a service is a commitment to the description of the service in the customer service model. However, SLAs typically include a number of fine- grained details about how services are allowed to vary, by how much, and how often. SLAs are also linked to commercial terms with penalties and so forth, and thus are also not good topics for @@ -695,24 +711,23 @@ 6.4. The MEF Architecture The MEF Forum has developed an architecture for network management and operation. It is documented as the Lifecycle Service Orchestration (LSO) Reference Architecture and illustrated in Figure 2 of [MEF-55]. The work of the MEF Forum embraces all aspects of Lifecycle Service Orchestration including billing, SLAs, order management, and life- cycle management. The IETF's work on service models is typically - smaller offering a simple, self-contained service YANG module. Thus, - it may be impractical to fit IETF service models into the MEF Forum - LSO architecture. This does not invalidate either approach: it only - observes that they are different approaches. + smaller offering a simple, self-contained service YANG module. This + does not invalidate either approach: it only observes that they are + different approaches. 7. Further Concepts This section introduces a few further, more advanced concepts 7.1. Technology Agnostic Service models should generally be technology agnostic. That is to say, the customer should not care how the service is provided so long as the service is delivered. @@ -856,21 +871,22 @@ Section 5. 10. IANA Considerations This document makes no requests for IANA action. 11. Acknowledgements Thanks to Daniel King, Xian Zhang, Michael Scharf, Med Boucadair, Luis Miguel Contreras Murillo, Joe Salowey, Benoit Claise, Robert - Sparks, and Tom Petch for useful review and comments. + Sparks, Tom Petch, David Sinicrope, and Deborah Brungard for useful + review and comments. Thanks to Dean Bogdanovic, Tianran Zhou, and Carl Moberg for their help coordinating with [RFC8199]. Many thanks to Jerry Bonner for spotting a tiny, one-word, but critical typo. 12. References 12.1. Normative References @@ -894,22 +910,22 @@ [I-D.ietf-bess-evpn-yang] Brissette, P., Sajassi, A., Shah, H., Li, Z., Tiruveedhula, K., Hussain, I., and J. Rabadan, "Yang Data Model for EVPN", draft-ietf-bess-evpn-yang-02 (work in progress), March 2017. [I-D.ietf-bess-l2vpn-yang] Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., and K. Tiruveedhula, "YANG Data Model for MPLS-based - L2VPN", draft-ietf-bess-l2vpn-yang-06 (work in progress), - June 2017. + L2VPN", draft-ietf-bess-l2vpn-yang-07 (work in progress), + October 2017. [I-D.ietf-l2sm-l2vpn-service-model] Wen, B., Fioccola, G., Xie, C., and L. Jalil, "A YANG Data Model for L2VPN Service Delivery", draft-ietf-l2sm-l2vpn- service-model-03 (work in progress), September 2017. [MEF-55] MEF Forum, "Service Operations Specification MEF 55 : Lifecycle Service Orchestration (LSO) Reference Architecture and Framework", March 2016.