--- 1/draft-ietf-opsawg-service-model-explained-01.txt 2017-08-24 14:13:12.247339388 -0700 +++ 2/draft-ietf-opsawg-service-model-explained-02.txt 2017-08-24 14:13:12.295340550 -0700 @@ -1,56 +1,55 @@ OPS Area Working Group Q. Wu Internet-Draft W. Liu Intended status: Informational Huawei Technologies -Expires: December 31, 2017 A. Farrel +Expires: February 25, 2018 A. Farrel Juniper Networks - June 29, 2017 + August 24, 2017 Service Models Explained - draft-ietf-opsawg-service-model-explained-01 + draft-ietf-opsawg-service-model-explained-02 Abstract - The IETF has produced a considerable number of data modules in the - YANG modelling language. The majority of these modules are used to - construct data models to model devices or monolithic functions and - they allow access for configuration and to read operational status. + The IETF has produced many data 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). - This document briefly sets out the scope of and purpose of an IETF - service model, and it also shows where a service model might fit into - a Software Defined Networking architecture. Note that service models - do not make any assumption of how a service is actually engineered - and delivered for a customer; details of how network protocols and - devices are engineered to deliver a service are captured in other - models that are not exposed through the Customer-Provider Interface. + This document describes service models as used within the IETF, and + also shows where a service model might fit into a Software Defined + Networking architecture. Note that service models do not make any + assumption of how a service is actually engineered and delivered for + a customer; details of how network protocols and devices are + engineered to deliver a service are captured in other models that are + not exposed through the Customer-Provider Interface. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 http://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 December 31, 2017. + This Internet-Draft will expire on February 25, 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -60,95 +59,99 @@ 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 . . . . . . . . . . . . . . . . . . . . . 3 3. Using Service Models . . . . . . . . . . . . . . . . . . . . 6 4. Service Models in an SDN Context . . . . . . . . . . . . . . 8 5. Possible Causes of Confusion . . . . . . . . . . . . . . . . 10 - 6. Comparison With Other Work . . . . . . . . . . . . . . . . . 11 + 6. Comparison With Other Work . . . . . . . . . . . . . . . . . 12 6.1. Comparison With Network Service Models . . . . . . . . . 12 - 6.2. Service Delivery and Network Element Model Work . . . . . 13 + 6.2. Service Delivery and Network Element Model Work . . . . . 14 6.3. Customer Service Model Work . . . . . . . . . . . . . . . 14 - 6.4. The MEF Architecture . . . . . . . . . . . . . . . . . . 15 - 7. Further Concepts . . . . . . . . . . . . . . . . . . . . . . 16 - 7.1. Technology Agnostic . . . . . . . . . . . . . . . . . . . 16 - 7.2. Relationship to Policy . . . . . . . . . . . . . . . . . 16 - 7.3. Operator-Specific Features . . . . . . . . . . . . . . . 17 - 7.4. Supporting Multiple Services . . . . . . . . . . . . . . 17 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 9. Manageability Considerations . . . . . . . . . . . . . . . . 18 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 - 12.2. Informative References . . . . . . . . . . . . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 + 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 1. Introduction In recent years the number of data modules written in the YANG - modelling language [RFC6020] for configuration and monitoring has + 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]). - Within the context of Software Defined Networking (SDN) [RFC7426] - YANG data models may be used on Southbound Interfaces (SBIs) between - a controller and network devices, and between network orchestrators - and controllers. There may also be a hierarchy of such components - with super-controllers, domain controllers, and device controllers - all exchanging information and instructions using YANG models. + Within the context of Software Defined Networking (SDN) [RFC7149] + [RFC7426] YANG data models may be used on the interface between a + controller and network devices, and between network orchestrators and + controllers. There may also be a hierarchy of such components with + super controllers, domain controllers, and device controllers all + exchanging information and instructions using YANG models. - Recently 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. + 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. 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 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 models that are not exposed through the Customer- Provider Interface. + 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 data models has been done in - [I-D.ietf-netmod-yang-model-classification]. That document provides - an important reference for this document, and also uses the term - "service model". Section 6.1 provides a comparison between these two - uses of the same terminology. + [RFC8199]. That document provides an important reference for this + document, and also uses the term "service model". Section 6.1 in + this document provides a comparison between these two uses of the + same terminology. 2. Terms and Concepts Readers should familiarize themselves with the description and - classification of YANG models provided in - [I-D.ietf-netmod-yang-model-classification]. + classification of YANG models provided in [RFC8199]. The following terms are used in this document: Network Operator: This term is used to refer to the company that owns and operates one or more networks that provide Internet - connectivity services and/or other services. The term is also - used to refer to an individual who performs operations and - management on those networks. + connectivity services and/or other services. Customer: This term refers to someone who purchases a service (including connectivity) from a network operator. In the context of this document, a customer is usually a company that runs their own network or computing platforms and wishes to connect to the Internet or between sites. Such a customer may operate an enterprise network or a data center. Sometimes this term may also be used to refer to the individual in such a company who contracts to buy services from a network operator. A customer as described here is a separate commercial operation from the network operator, @@ -170,32 +173,30 @@ Internet access), may be a tunnel (such as a virtual circuit), or may be a more complex connectivity model (such as a multi-site virtual private network). Services may be further enhanced by additional functions providing security, load-balancing, accounting, and so forth. Additionally, services usually include guarantees of quality, throughput, and fault reporting. This document makes a distinction between a service as delivered to a customer (that is, the service as discussed on the interface between a customer and the network operator) and the service as - realized within the network (as described in - [I-D.ietf-netmod-yang-model-classification]). This distinction is - discussed further in Section 6. + realized within the network (as described in [RFC8199]). This + distinction is discussed further in Section 6. Readers may also refer to [RFC7297] for an example of how an IP connectivity service may be characterized. Data Model: The concepts of information models and data models are described in [RFC3444]. That document defines a data model by - contrasting it with the definition of an information model, so it - may be helpful to quote some text to give context within this - document. + contrasting it with the definition of an information model as + follows: The main purpose of an information model is to model managed objects at a conceptual level, independent of any specific implementations or protocols used to transport the data. The degree of specificity (or detail) of the abstractions defined in the information model depends on the modeling needs of its designers. In order to make the overall design as clear as possible, an information model should hide all protocol and implementation details. Another important characteristic of an information model is that it defines relationships between @@ -233,57 +234,57 @@ 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 engineered in the network. It can be used by a human operator (such as via a management station) or by a software tool to instruct network components. Such models are sometimes - referred to as "network service models" - [I-D.ietf-netmod-yang-model-classification] and are consumed by - "external systems" such as Operations Support System (OSS). A - service delivery model 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 model. Service - delivery models include technology-specific modules. + referred to as "network service models" [RFC8199] and are + consumed by "external systems" such as Operations Support + System (OSS). A service delivery model 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 model. Service delivery models include technology-specific + modules. The distinction between a customer service model and a service delivery model needs to be repeatedly clarified. A customer service model is not a data model 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, a customer service model is not a data model that describes how a network operator realizes and delivers the service described by the model. 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 + 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] + 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 API, while systems with more direct human interactions - might use web pages or even paper forms. + might use an internal API, while systems with more direct human + interactions might use web pages or even paper forms. -------------- Customer ---------------------- | | Service Model | | | Customer | <-----------------> | Network Operator | | | | | -------------- ---------------------- Figure 1: The Customer Service Models used on the Interface between Customers and Network Operators @@ -298,27 +299,27 @@ 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. The practicality of customer service models has been repeatedly - debated. It has been suggested that network operators have such - radically different business modes and such diverse commercial - offerings that 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. + 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 customer service module, and that details of individual services should be offered as extensions or augmentations of this. It is 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 @@ -353,39 +354,38 @@ --------- --------- --------- --------- | 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, there should be an independence between the behavior and functions that a customer requests and the technology - that the network operator has available to deliver the service. This - means that the service request must be mapped to the orchestrator's - view, and this mapping may include a choice of which networks and - technologies to use depending on which service features have been - requested. + that the network operator has available to deliver the service. 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) | | | | ---------- ------------------ . . - . . ----------- + . . (b) ----------- . (b) . ......|Application| . . : | BSS/OSS | . . : ----------- . Service Delivery . : . Model . : ------------------ ------------------ | | | | | Network | | Network | | Orchestrator | | Orchestrator | | | | | @@ -412,29 +412,29 @@ Figure 3 also shows where different data models might be applied within the architecture. The split between control components that exposes a "service interface" 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 - between the NSAL and the Control Plane. + between the NSAL and the control plane. - o [RFC7491] describes an interface between an "Application Service - Coordinator" and an "Application-Based Network Operations + o Figure 1 of [RFC7491] shows an interface between an "Application + Service Coordinator" and an "Application-Based Network Operations Controller". - o Figure 1 of [I-D.ietf-netmod-yang-model-classification] shows an - interface from an OSS or a Business Support System (BSS) that is - expressed in "Network Service YANG Models". + o Figure 1 of [RFC8199] shows an interface from an OSS or a Business + Support System (BSS) that is expressed in "Network Service YANG + Models". This can all lead to some confusion around the definition of a "service interface" and a "service model". Some previous literature considers the interface northbound of the Network Orchestrator (labeled "(b)" in Figure 3) to be a "service interface" used by an application, but the service described at this interface is network- centric and is aware of many features such as topology, technology, and operator policy. Thus, we make a distinction between this type of service interface and the more abstract service interface (labeled "(a)" in Figure 3) where the service is described by a service model @@ -470,86 +470,98 @@ (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. - [I-D.ietf-netmod-yang-model-classification] also terms these data + device configuration information. [RFC8199] also terms these data models as "service models" or "Network Service YANG Models" 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. + 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 so are also not good topics for - standardization. + standardization. As with commercial terms, it is expected that + some network operators will enhance standard customer service + models to include SLA parameters either using their own work or + depending on material from standards bodies that specialize in + this topic, but this feature is out of scope for the IETF's + customer service models. If a network operator chooses to express an SLA using a data model, that model might be referenced as an extension or an augmentation of the customer service model. 6. Comparison With Other Work Other work has classified YANG models, produced parallel architectures, and developed a range of YANG models. This section briefly examines that other work and shows how it fits with the description of service models introduced in this document. 6.1. Comparison With Network Service Models - As previously noted, [I-D.ietf-netmod-yang-model-classification] - provides a classification of YANG data models. It introduces the - term "Network Service YANG Module" to identify the type of model used - to "describe the configuration, state data, operations and - notifications of abstract representations of services implemented on - one or multiple network elements." These are service delivery models - as described in this document, that is, they are the models used on - the interface between the Service Orchestrator or OSS/BSS and the - Network Orchestrator as shown in Figure 3. + As previously noted, [RFC8199] provides a classification of YANG data + models. It introduces the term "Network Service YANG Module" to + identify the type of model used to "describe the configuration, state + data, operations and notifications of abstract representations of + services implemented on one or multiple network elements." These are + service delivery models as described in this document, that is, they + are the models used on the interface between the Service Orchestrator + or OSS/BSS and the Network Orchestrator as shown in Figure 3. - Figure 1 of [I-D.ietf-netmod-yang-model-classification] can be - modified to make this more clear and to add an additional example of - a Network Service YANG model as shown in Figure 4. + Figure 1 of [RFC8199] can be modified to make this more clear and to + add an additional example of a Network Service YANG model as shown in + Figure 4. This figure illustrates a functional architecture and an + implementation might choose to make different distinctions and + separations between components so that the functional units and + interfaces illustrated might fall within a single implementation. +---------------+ | | | Customers | | | +---------------+ - - - - - - - - - - - - - - Customer Service YANG Modules - +--------------------------+ +--------------------------+ + +-------------------------------------------------------+ + | | + | +----------------------+ | | | | Operations and Business | - | Service Orchestrator | | Support Systems | + | | Service Orchestrator | Support Systems | | | | (OSS/BSS) | - +--------------------------+ +--------------------------+ + | +----------------------+ | + | | + | | + +-------------------------------------------------------+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Network Service YANG Modules +------------+ +-------------+ +-------------+ +-------------+ | | | | | | | | | - L2VPN | | - L2VPN | | EVPN | | L3VPN | | - VPWS | | - VPLS | | | | | | | | | | | | | +------------+ +-------------+ +-------------+ +-------------+ @@ -568,46 +580,45 @@ VPWS: Virtual Private Wire Service VPLS: Virtual Private LAN Service Figure 4: YANG Module Layers Showing Service Models 6.2. Service Delivery and Network Element Model Work A number of IETF working groups are developing YANG models related to services. These models focus on how the network operator configures the network through protocols and devices to deliver a service. Some - of these models are classed as service delivery models while others - have details that are related to specific element configuration and - so are classed as network element models. + of these models are classified as service delivery models while + others have details that are related to specific element + configuration and so are classed as network element models (also + called device models). A sample set of these models is listed here: o [I-D.dhjain-bess-bgp-l3vpn-yang] defines a YANG model that can be - used to configure and manage BGP Layer 3 VPNs. + used to configure and manage BGP L3VPNs. o [I-D.ietf-bess-l2vpn-yang] documents a YANG model that it is expected will be used by the management tools run by the network operators in order to manage and monitor the network resources that they use to deliver L2VPN services. o [I-D.ietf-bess-evpn-yang] defines YANG models for delivering an Ethernet VPN service. 6.3. Customer Service Model Work Several initiatives within the IETF are developing customer service - models. The most advanced presents the Layer Three Virtual Private - Network (L3VPN) service as described by a network operator to a - customer. This L3VPN service model (L3SM) is documented in [RFC8049] - where its usage is described as in Figure 5 which is reproduced from - that document. As can be seen, the L3SM is a customer service model - as described in this document. + models. The most advanced presents the L3VPN service as described by + a network operator to a customer. The L3SM is described as in + Figure 5 which is reproduced from [RFC8049]. As can be seen, the + L3SM is a customer service model as described in this document. L3VPN-SVC | MODEL | | +------------------+ +-----+ | Orchestration | < --- > | OSS | +------------------+ +-----+ | | +----------------+ | | Config manager | | @@ -709,36 +720,42 @@ The policies that express desired behavior of services on occurrence of specific events are close to SLA definitions: they should only be included in the base service model where they are common to all network operators' offerings. Policies that describe who at a customer may request or modify services (that is, authorization) are close to commercial terms: they, too, should only be included in the base service model where they are common to all network operators' offerings. + As with commercial terms and SLAs discussed in Section 5 it is + expected that some network operators will enhance standard customer + service models to include policy parameters either using their own + work or depending on specific policy models built in the IETF or + other standards bodies. + Nevertheless, policy is so important that all service models should be designed to be easily extensible to allow policy components to be added and associated with services as needed. 7.3. Operator-Specific Features - When work in the L3SM working group was started, there was some doubt - as to whether network operators would be able to agree on a common - description of the services that they offer to their customers - because, in a competitive environment, each markets the services in a - different way with different additional features. However, the - working group was able to agree on a core set of features that - multiple network operators were willing to consider as "common". - They also understood that should an individual network operator want - to describe additional features (operator-specific features) they - could do so by extending or augmenting the L3SM model. + When work on the L3SM was started, there was some doubt as to whether + network operators would be able to agree on a common description of + the services that they offer to their customers because, in a + competitive environment, each markets the services in a different way + with different additional features. However, the working group was + able to agree on a core set of features that multiple network + operators were willing to consider as "common". They also understood + that should an individual network operator want to describe + additional features (operator-specific features) they could do so by + extending or augmenting the L3SM model. Thus, when a basic description of a core service is agreed and documented in a service model, it is important that that model should be easily extended or augmented by each network operator so that the standardized model can be used in a common way and only the operator- specific features varied from one environment to another. 7.4. Supporting Multiple Services Network operators will, in general, offer many different services to @@ -771,145 +788,154 @@ Clearly, the ability to modify information exchanges between customer and network operator may result in bogus requests, unwarranted billing, and false expectations. Furthermore, in an automated system, modifications to service requests or the injection of bogus requests may lead to attacks on the network and delivery of customer traffic to the wrong place. Therefore it is important that the protocol interface used to exchange service request information between customer and network operator is subject to authorization, authentication, and encryption. - This document discusses modeling that information, not how it is + Equally, all external intefaces, such as any of those between the + functional components in Figure 3 needs to be correctly secured. + + This document discusses modeling the information, not how it is exchanged. 9. Manageability Considerations - This whole document discusses issues related to network management. + This whole document discusses issues related to network management + and control. It is important to observe that automated service provisioning resulting from use of a customer service model may result in rapid and significant changes in traffic load within a network and that that might have an effect on other services carried in a network. It is expected, therefore, that a Service Orchestration component has awareness of other service commitments, that the Network Orchestration component will not commit network resources to fulfill a service unless doing so is appropriate, and that a feedback loop will be provided to report on degradation of the network that will impact the service. The operational state of a service does not form part of a customer service model. However, it is likely that a network operator may want to report some state information about various components of the service, and that could be achieved through extensions to the core - service model. + service model just as SLA extensions could be made as described in + Section 5. 10. IANA Considerations This document makes no requests for IANA action 11. Acknowledgements - Thanks to Daniel King, Xian Zhang, and Michael Scharf for useful - review and comments. Med Boucadair gave thoughtful and detailed - comments on version -04 of this document. Thanks to Dean Bogdanovic - and Tianran Zhou for their help coordinating with [I-D.ietf-netmod- - yang-model-classification]. + Thanks to Daniel King, Xian Zhang, Michael Scharf, Med Boucadair, and + Luis Miguel Contreras Murillo for useful review and comments. + + Thanks to Dean Bogdanovic, Tianran Zhou, and Carl Moberg for their + help coordinating with [RFC8199]. Many thanksto Jerry Bonner for spotting a tiny, one-word, but critical typo. 12. References 12.1. Normative References - [I-D.ietf-netmod-yang-model-classification] - Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module - Classification", draft-ietf-netmod-yang-model- - classification-08 (work in progress), June 2017. - [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, - DOI 10.17487/RFC3444, January 2003, - . - - [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., - Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- - Defined Networking (SDN): Layers and Architecture - Terminology", RFC 7426, DOI 10.17487/RFC7426, January - 2015, . + DOI 10.17487/RFC3444, January 2003, . - [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data - Model for L3VPN Service Delivery", RFC 8049, - DOI 10.17487/RFC8049, February 2017, - . + [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module + Classification", RFC 8199, DOI 10.17487/RFC8199, July + 2017, . 12.2. Informative References [I-D.dhjain-bess-bgp-l3vpn-yang] Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model for BGP/MPLS L3 VPNs", draft-dhjain-bess-bgp-l3vpn-yang-02 (work in progress), August 2016. [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-05 (work in progress), - March 2017. + L2VPN", draft-ietf-bess-l2vpn-yang-06 (work in progress), + June 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-01 (work in progress), May 2017. + service-model-02 (work in progress), July 2017. [MEF-55] MEF Forum, "Service Operations Specification MEF 55 : Lifecycle Service Orchestration (LSO) Reference Architecture and Framework", March 2016. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, - DOI 10.17487/RFC6020, October 2010, - . + DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, - . + . + + [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined + Networking: A Perspective from within a Service Provider + Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, + . [RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, - . + . [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, - DOI 10.17487/RFC7297, July 2014, - . + DOI 10.17487/RFC7297, July 2014, . [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, - December 2014, . + December 2014, . + + [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., + Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- + Defined Networking (SDN): Layers and Architecture + Terminology", RFC 7426, DOI 10.17487/RFC7426, January + 2015, . [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for Application-Based Network Operations", RFC 7491, - DOI 10.17487/RFC7491, March 2015, - . + DOI 10.17487/RFC7491, March 2015, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, - . + . + + [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data + Model for L3VPN Service Delivery", RFC 8049, + DOI 10.17487/RFC8049, February 2017, . Authors' Addresses Qin Wu Huawei Technologies Email: bill.wu@huawei.com Will Liu Huawei Technologies