Internet Working Group K. Pentikousis, Ed. Internet Draft EICT Intended status: Informational D. Zhang Expires: August 3, 2015 Alibaba January 30, 2015 Shared Unified Policy Automation (SUPA): Configuration and Policy Mapping draft-pentikousis-supa-mapping-02 Abstract Nowadays, the underlying network infrastructure grows in scale and complexity, which make it challenging for network operators to manage and configure the network. Deploying policy or configuration based on an abstract view of the underlying network is much better than manipulating each individual network element, however, in this case, the policy and configuration cannot be recognized by the network elements. This document describes guidelines for mapping said abstract configuration and policy into device-level configuration and the way in which such models will be processed by software to produce configuration details for actual devices. The Shared Unified Policy Automation (SUPA) framework overview and primary procedures of mapping are described. Moreover, an exemplary mapping scenario is provided to illustrate the defined mechanism. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." Pentikousis, et al. Expires August 3, 2015 [Page 1] Internet-Draft SUPA Configuration and Policy Mapping January 2015 The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on July 30, 2014. Copyright Notice Copyright (c) 2015 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 carefully, as they describe your rights and restrictions with respect 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. Terminology .............................................. 3 3. Configuration and Policy Mapping.......................... 4 3.1. Overview .............................................. 4 3.2. Mapping Procedure...................................... 5 3.3. SUPA Mapping Example................................... 6 4. Security Considerations.................................. 11 5. IANA Considerations...................................... 11 6. References .............................................. 11 6.1. Normative References.................................. 11 6.2. Informative References................................ 11 7. Acknowledgments ......................................... 12 1. Introduction As the underlying network infrastructure grows, new services are introduced, and traffic volumes increase rapidly, it becomes significantly more challenging and complicated to maintain the Pentikousis, et al. Expires August 3, 2015 [Page 2] Internet-Draft SUPA Configuration and Policy Mapping January 2015 network and deploy new services than in the past. Configuration automation can provide significant benefits in deployment agility. Shared Unified Policy Automation (SUPA) [I-D.zhou-supa-framework] aims to improve configuration automation by introducing multi-level abstractions. In SUPA, the definition of a standardized model for a network topology graph, which could be used to describe topologies at any functional layer, and information models of various network services and network service development policies allow network operators to manipulate their infrastructure as a whole rather than individual devices. Well-designed abstractions are able to provide a wide range of granularity for various applications needs, from the lower-level physical network to high-level network services. However, these information models cannot be directly utilized by network elements, thus a mapping mechanism is necessary to bridge the gap between these information models and network element-recognized configuration. SUPA employs Management Agent (MA) blocks. MAs represent one or more entities that are able to control the operation and management of a network infrastructure and mediate between the Operation and Management Application (OAMA) and the network elements to provide, maintain and deploy network services and policies. Each MA supports the SUPA interface/protocol and is a software repository, which stores the information associated with each network element. The mapping mechanism could be part of the MA implementation in order to map the SUPA model(s) into specified configuration models (or so- called southbound interfaces), which can be recognized by the network element(s). 2. Terminology This document uses the following terms: Management Agent (MA): represents one or more entities that are able to control the operation and management of a network infrastructure. Network element (NE): a physical or virtual entity that can be locally managed and operated. Operation and Management Application (OAMA): represents one or more network entities that are running and controlling network services. SUPA: Shared Unified Policy Automation. Pentikousis, et al. Expires August 3, 2015 [Page 3] Internet-Draft SUPA Configuration and Policy Mapping January 2015 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Configuration and Policy Mapping This section introduces a framework for mapping configuration and policy in the context of a network with several network elements and one or more operation and management applications (OAMAs). 3.1. Overview The SUPA framework for mapping network-level configuration into specific network management and controlling policies is illustrated in Figure 1. It consists of i) OAMA, ii) MA and iii) NEs. +---------------+ ------------------------- | | | | OAMA | | | | | +-------+-------+ | | NetConf/RestConf | | Network +-----------------v--------------+ Level | +------------+ +-------------+| | | | Topology | | Service/ || | | +------------+ | Policy || | | +-------------+| | | | | | MA ------------------------- | +-----------------+ | | | |protocol-specific| | | | | configuration | | | | +-----------------+ | | +-----------------^--------------+ Device | Level +-----------------+--------------------+ | CLI/I2RS | | CLI/I2RS | | | | | | | +---------------+ +---------------+ | | | | | | | NE | ... | NE | | | | | | | +---------------+ +---------------+---------- Pentikousis, et al. Expires August 3, 2015 [Page 4] Internet-Draft SUPA Configuration and Policy Mapping January 2015 Figure 1: SUPA configuration and policy mapping overview OAMA manages and programs the underlying network elements indirectly based on the abstract view of the network infrastructure. In practice, this means that OAMA can, among others, configure the underlying network as a whole rather than as a set of individual network elements. As a result, the diversity of the actual network elements in active operation is abstracted, which allows OAMA to manage and program the network in a simpler, more maintainable and efficient manner. On the other end of the spectrum, the NEs can continue their regular operation without having to become cognizant of the fact that configuration is applied at the network level. In order to bridge the gap between configuration set by OAMA and that required by the NEs, the MA has to provide a mapping mechanism which translates the configuration settings from the network level to the device level. This document considers three modules in the MA to support such a mapping mechanism, as follows. First, a topology module maintains the topology of the network infrastructure and provides topology information in the specific network layer as the network service expects. It also provides the necessary information of each network element when mapping configuration from the network-level to device-level. Second, the service/policy configuration module receives the network-level configuration and acts as the primary input of the mapping mechanism. Third, the protocol-specific configuration produces the output of the mapping mechanism and is responsible for distributing the device- level configuration to the corresponding network elements. In this framework, one would expect the introduction and use of algorithms/strategies for specific network services which can automatically generate device-level configuration based on the OAMA policies/configurations. Note, however, that said algorithms and strategies are out of the scope of this document. 3.2. Mapping Procedure From the view point of OAMA: Firstly, OAMA needs some context of the underlying network, especially the infrastructure (physical or logical) of the network, before it deploys a policy/service to the network. For example, if OAMA attempts to steer traffic from one path to another, it should have the information of the existing paths first. OAMA requests this context information from MA, and the information is provided with the Pentikousis, et al. Expires August 3, 2015 [Page 5] Internet-Draft SUPA Configuration and Policy Mapping January 2015 topology model. This procedure does not have to be processed every time OAMA deploys a policy/service. Secondly, OAMA can obtain the current status of a policy/service for reference before it deploys a new one. In such cases, OAMA sends a "GET" request to the MA, and the MA encapsulates this information with the models specified by SUPA network service models or policy models. Thirdly, OAMA deploys a policy/service by sending a "POST" request to the MA with the policy/service information formatted with SUPA models. From the view point of MA: Firstly, the MA is responsible for maintaining the infrastructure information, and it provides information to OAMAs with the topology information model. Secondly, once the MA receives policy/service models from OAMAs, it maps these models to protocol-specific models. The intelligence/algorithms of how to do the mapping is implementation- specific and out of the scope of this specification, as are the protocol-specific models. Thirdly, with the protocol-specific models, the device-level configurations for heterogeneous devices can be generated and conveyed by the MA using, for example, [RFC6020], [RESTCONF], [I-D.ietf-i2rs-architecture] and CLI, to the corresponding NEs. 3.3. SUPA Mapping Example Figure 2 illustrates a simple example in which interoperability between OAMA and MA in an inter-data center (inter-DC) environment is considered. For the purposes of this example, let us focus on the dynamic configuration of the IP path between the seven illustrated DCs, labeled A, B, C, D, E, F and G, based on the policies. First of all, we would like the IP path to be created based on certain constraints. Secondly, we would like to map it to the device-level connections. In this scenario, there are two paths from DC A to DC B. Typical IP shortest-path routing would choose path A(1.1.1.1)-C(3.3.3.3) > B(2.2.2.2). However, under certain conditions, such as, for instance, when the bandwidth between A and B is not suitable, the OAMA can Pentikousis, et al. Expires August 3, 2015 [Page 6] Internet-Draft SUPA Configuration and Policy Mapping January 2015 decide that is better to steer traffic from path (A, C, B) to a new path which goes through a specific node. Figure 2 depicts the layer 3 topology of the underlying network. +-----------------------+ | +------+ | | |Policy| | | +------+ | | OAMA | +----------^------------+ | | NETCONF/RESTCONF | +--------------v---------------+ | | | M A | | | +--------------^---- ----------+ | CLI/I2RS/NETCONF | +----------------v--------------------+ | | 1.1.1.1 2.2.2.2 +------+ +------+ +------+ | A +----------+ C +------------+ B +-----+ +-+--+-+ +------+ +---+--+ | | | 3.3.3.3 | | ++ | | | | | | +---+--+ | | | | G | +---+--+| | +---+--+ | F || | | +------+| +--+---+ +---+--+ | +-------+ D +-----------------+ E +-----+ +------+ +------+ 4.4.4.4 5.5.5.5 Figure 2: Bandwidth use optimization for DC Interconnection Pentikousis, et al. Expires August 3, 2015 [Page 7] Internet-Draft SUPA Configuration and Policy Mapping January 2015 First, OAMA needs some information about A, B, C, D and the links between them. This information can be obtained from MA, and it is listed in the fragment below. This information is derived from the Topology YANG model described in [draft-contreras-supa-yang-network- topo-02]. 1111111100000000 mapping_topo ip 1.1.1.1 A physical adminUp up 1111111100000000 2.2.2.2 B physical adminUp up 1111111100000000 ... skip ... 3.3.3.3 C physical adminUp up 1111111100000000 1 A2C telink bidrectional Pentikousis, et al. Expires August 3, 2015 [Page 8] Internet-Draft SUPA Configuration and Policy Mapping January 2015 adminUp up 1.1.1.1 3.3.3.3 1111111100000000 2000 ... skip ... 2 C2B telink bidrectional adminUp up 3.3.3.3 2.2.2.2 1111111100000000 50000 Secondly, OAMA sends the steering information to MA using a protocol such as NETCONF or RESTCONF. Figure 3 presents the requirements for traffic steering: the traffic (supaflow) with destination IP address 11.11.11.11/24 needs to be steered to DC B, the new path must go through DC D. This configuration is derived from the YANG model described in [I-D.zaalouk-supa-configuration-model]. Pentikousis, et al. Expires August 3, 2015 [Page 9] Internet-Draft SUPA Configuration and Policy Mapping January 2015 supa_vpn L3VPN supa_flow 4.4.4.4 Figure 3: Example traffic steering requirements Based on this configuration, the MA generates a path which meets the requirements: in this example, the computed path is (A, D, E, B). MA also has to configure each device on the new path, not only the devices specified by the configuration such as node D, but also the devices in the underlying network which must be reconfigured, such as node E. The topology information is also necessary when MA decides which device ought to be configured. With the assistance of other information in MA, such as topology information, service/policy configuration can be translated into protocol-specific yang models (or southbound interface) first. Taking node D as an example, the configuration expressed in the YANG model defined in [I-D.ietf-netmod-routing-cfg] could be as follows: rtr0 Router D rt:static st0 Static routing is used for the internal network. 11.11.11.11/24 5.5.5.5 Pentikousis, et al. Expires August 3, 2015 [Page 10] Internet-Draft SUPA Configuration and Policy Mapping January 2015 The configuration of other nodes is similar. Based on this vendor- neutral device-level configuration and the features of each NE, the NE-specific configuration can be generated. Once nodes A, C, D and E have received their respective NE-specific configurations, the device-level configuration could be deployed and then, the traffic is steered as OAMA specified. 4. Security Considerations Security considerations will be discussed in an upcoming revision of this document. 5. IANA Considerations TBD 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [I-D.zaalouk-supa-configuration-model] Zaalouk, A., Pentikousis, K., and W. Liu, "A YANG Data Model for Configuration of Shared Unified Policy Automation (SUPA)", draft-zaalouk-supa-configuration-model (work in progress), October 2014. [I-D. contreras-supa-yang-network-topo] Contreras, L. and Andrew Qu, "A YANG Data Model for Network Topologies", draft-contreras-supa- yang-network-topo-02 (work in progress), January 2015. Pentikousis, et al. Expires August 3, 2015 [Page 11] Internet-Draft SUPA Configuration and Policy Mapping January 2015 [I-D.zhou-supa-framework] C. Zhou, L. M. Contreras, Q. Sun, and Q. Sun "The Framework of Shared Unified Policy Automation (SUPA)", draft-zhou-supa-architecture-00, (work in progress), January 2015. [I-D.ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the RoutingSystem", draft-ietf-i2rs-architecture-08 (work in progress), January 2015. [I-D.ietf-netmod-routing-cfg] Lhotka, L., "A YANG Data Model for Routing Management", draft-ietf-netmod-routing-cfg-16 (work in progress), October 2014. [RESTCONF] Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, "RESTCONF Protocol", draft-ietf-netconf-restconf-03 (work in progress), October 2014. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. 7. Acknowledgments This document has benefited comments, suggestions, and proposed text provided by Cathy Zhou and Will Liu (listed in alphabetical order). Junru Lin and Zhayiyong contributed to an earlier version of this draft. Pentikousis, et al. Expires August 3, 2015 [Page 12] Internet-Draft SUPA Configuration and Policy Mapping January 2015 Authors' Addresses Kostas Pentikousis (editor) EICT GmbH Torgauer Strasse 12-15 Berlin 10829 Germany Email: k.pentikousis@eict.de Dacheng Zhang Alibaba Chaoyang Dist Beijing 100000 P.R. China Email: Dacheng.zdc@alibaba-inc.com Pentikousis, et al. Expires August 3, 2015 [Page 13]