--- 1/draft-ietf-opsawg-service-model-explained-02.txt 2017-09-05 08:14:00.711783714 -0700 +++ 2/draft-ietf-opsawg-service-model-explained-03.txt 2017-09-05 08:14:00.759784855 -0700 @@ -1,20 +1,20 @@ OPS Area Working Group Q. Wu Internet-Draft W. Liu Intended status: Informational Huawei Technologies -Expires: February 25, 2018 A. Farrel +Expires: March 9, 2018 A. Farrel Juniper Networks - August 24, 2017 + September 5, 2017 Service Models Explained - draft-ietf-opsawg-service-model-explained-02 + draft-ietf-opsawg-service-model-explained-03 Abstract 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). @@ -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 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 February 25, 2018. + This Internet-Draft will expire on March 9, 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 @@ -87,21 +87,21 @@ 1. Introduction In recent years the number of data 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]). Within the context of Software Defined Networking (SDN) [RFC7149] - [RFC7426] YANG data models may be used on the interface between a + [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. 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 @@ -158,23 +158,23 @@ but some companies may operate with internal customers so that, for example, an IP/MPLS packet network may be the customer of an optical transport network. Service: A network operator delivers one or more services to a customer. A service in the context of this document (sometimes called a Network Service) is some form of connectivity between customer sites and the Internet, or between customer sites across the network operator's network and across the Internet. However, a distinction should be drawn between the parameters that describe - a service as included in a customer service model (q.v.) and a - Service Level Agreement (SLA) as discussed in Section 5 and - Section 7.2. + a service as included in a customer service model (see the + definition of this term, below) and a Service Level Agreement + (SLA) as discussed in Section 5 and Section 7.2. A service may be limited to simple connectivity (such as IP-based 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 @@ -223,21 +223,21 @@ network operators: additional features that are specific to the offerings of individual network operators would be defined in extensions or augmentations of the model. 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 - are when they describe the behavior or interactions on the + 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 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 @@ -245,22 +245,22 @@ 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, + delivery model needs to be 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 @@ -352,26 +352,26 @@ : . . : : . . : --------- --------- --------- --------- | 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. 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. + 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. 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) | | @@ -492,21 +492,21 @@ 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 + with penalties and so forth, and thus are also not good topics for 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. @@ -518,27 +518,27 @@ 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, [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 + 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 [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 + 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 | | | +---------------+ @@ -580,45 +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 classified as service delivery models while + 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 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 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. + models. The L3SM presents the L3VPN service as described by a + network operator to a customer. Figure 5, which is reproduced from + [RFC8049], shows that the L3SM is a customer service model as + described in this document. L3VPN-SVC | MODEL | | +------------------+ +-----+ | Orchestration | < --- > | OSS | +------------------+ +-----+ | | +----------------+ | | Config manager | | @@ -672,22 +672,22 @@ 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, but only - observes that they are different. + LSO architecture. 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. @@ -720,60 +720,59 @@ 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 + 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 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 + 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 their customers. Each would normally be the subject of a separate service model. - It is an implementation and deployment choice whether all service - models are processed by a single Service Orchestrator that can - coordinate between the different services, or whether each service - model is handled by a specialized Service Orchestrator able to - provide tuned behavior for a specific service. + Whether each service model is handled by a specialized Service + Orchestrator able to provide tuned behavior for a specific service or + whether all service models are handled by a single Service + Orchestrator is an implementation and deployment choice. It is expected that, over time, certain elements of the service models will be seen to repeat in each model. An example of such an element is the postal address of the customer. It is anticipated that, while access to such information from each service model is important, the data will be described in its own module and may form part of the service model either by inclusion or by index. @@ -788,21 +787,21 @@ 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. - Equally, all external intefaces, such as any of those between the + Equally, all external interfaces, 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 and control. @@ -820,41 +819,41 @@ 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 just as SLA extensions could be made as described in Section 5. 10. IANA Considerations - This document makes no requests for IANA action + This document makes no requests for IANA action. 11. Acknowledgements 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 thanks to Jerry Bonner for spotting a tiny, one-word, but critical typo. 12. References 12.1. Normative References [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, - DOI 10.17487/RFC3444, January 2003, . + DOI 10.17487/RFC3444, January 2003, + . [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 @@ -877,65 +876,65 @@ Wen, B., Fioccola, G., Xie, C., and L. Jalil, "A YANG Data Model for L2VPN Service Delivery", draft-ietf-l2sm-l2vpn- 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, . [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, . + DOI 10.17487/RFC8049, February 2017, + . Authors' Addresses Qin Wu Huawei Technologies Email: bill.wu@huawei.com Will Liu Huawei Technologies