1. Status of Work Feb 2, 2015

2. What and how fits? (option 1) Network Manager Network Elements (routers, switches, etc) RESTCONF / NETCONF Service Management SUPA Network Elements (routers, switches, etc) Service Data Model Policy Data Model Topology Data Model Network Manager Topology Data Model : SUPA scope

3. Service API Network Resource API What and how fits? (option 2) Network Manager/Controller Network Elements (routers, switches, etc) RESTCONF / NETCONF Service Management Network Elements (routers, switches, etc) Service Management Data Model (Service Agent View) Policy Data Model Service Management Data Model : SUPA scope Network Resource Data Model Network Manager/Controller Service Management Data Model (Service Agent View) Network Resource Data Model

4. Where Related WGs Focus Network Manager Network Elements (routers, switches, etc) RESTCONF / NETCONF Service Management SUPA focuses on: service management and network resource view Network Elements (routers, switches, etc) Other WGs (e.g. I2RS, BGP, PCE, etc.) focus on: network element centric view Network Manager

5. I-Ds Use Cases for Distributed Data Center Applications in SUPA draft-cheng-supa-ddc-use-cases-02 Problem Statement for Shared Unified Policy Automation (SUPA) draft-karagiannis-supa-problem-statement-04 Charter The Framework of Shared Unified Policy Automation (SUPA) draft-zhou-supa-framework-00 SUPA Configuration and Policy Mapping draft-pentikousis-supa-mapping-02 A YANG Data Model for Network Topologies draft-contreras-supa-yang-network-topo-02 VPN Service Management Data Model draft-zaalouk-supa-vpn-service-management-model-00 Yang Policy Data Model draft-wang-netmod-yang-policy-dm-00draft-wang-netmod-yang-policy-dm-00 / part of draft-adel-vpn-service-management-model-00draft-adel-vpn-service-management-model-00

6. SUPA DDC Use Case Abstract This draft analyzes some use cases in Distributed Data Centers (DDC), and the applicability of SUPA data models and platform which can be used for better resource usage and easy service/network configuration. Use cases  Inter DC Connectivity There are lots of links between DCs; data models can be used to automate the configuration  vDC Connectivity DC tenant’s resources may be distributed in multiple DCs; DC operator provide links for these resources and make it look like one seamless virtual DC (vDC) for the tenant. SUPA helps to automate service deployment. Use Case for vDC

7. SUPA DDC Use Case – Cont’ Use cases  Dynamic Link Configuration for DC Some services like VM migration and large amount data transfer do not happen frequently; static bandwidth provision is not good enough; dynamic link creation or configuration change (e.g. increase bandwidth for a while) is necessary.  VPC to DC Connectivity Some organization (e.g. a university) use VMs in cloud as computer desktop, which need access to internal services in DCs. Lots of VPN configuration is necessary Comments and updates Incorporate use cases from operators, universities NOGs and vendors Use Case for VPC

8. Problem Statement Abstract  Describes the problem that needs to be addressed in order to equip service providers with the means to quickly and dynamically create/query/scale/update/delete the network services they want to offer. The problem  Rapid increase of traffic makes it more challenging to manage networks and to deploy new services.  Is the root cause of one of the major challenges network operators are facing today.  Combining the two mechanisms provides additional and significant benefits in design and deployment agility: (1) the use of software abstractions to simplify management and (2) the increase in programmatic control over the configuration and operation of such networks.

9. Problem Statement – Cont’ Status and comments  Updated to version 4 on Jan 23 according to the comments received on and off the list.  New version was discussed during the online meeting Jan 26.  Comments: 1. Positive feedback on the use cases recently collected from CT, Harvard, Tsinghua; 2. Need to focus on the problem and why the current technology does not fulfill requirements; 3. Some elements don't belong in there - such as architecture;  to be updated to version 5 to address the above comments this week

10. Rapid growth in the amounts and types of traffic flowing over increasingly complex network architectures makes it significantly more challenging for operations and management applications to manage networks and to deploy new services than in previous times. Two complementary mechanisms for dealing with this growing complexity are (1) the use of software abstractions to simplify management and (2) the increase in programmatic control over the configuration and operation of such networks. The first mechanism enables simplified views of the network to be constructed, which hides complex configuration detail and provides a smaller number of standard control points to configure common functions. The second mechanism uses the abstractions and control points to more quickly define and manage network services. Moreover, combining these two mechanisms provides additional and significant benefits in design and deployment agility. Charter 1/4

11. This working group introduces the concepts of multi-level (multiple levels of abstraction) and multi-technology (e.g., IP, VPNs, MPLS) network abstractions to address the current separation between development and deployment operations. Multiple levels of abstraction enable common concepts present in different technologies and implementations to be represented in a common manner. This facilitates using diverse components and technologies to implement a network service. Charter 2/4

12. The purpose of the SUPA (Shared Unified Policy Automation) working group is to develop a methodology by which management of network services can be done using standardized policy rules. Three types of YANG data models are envisioned: 1) model of the physical and virtual network topology including the resources (e.g., data rate or latency of links) and operational parameters needed to support service deployment over the network topology 2) model of the network service (e.g., VPNs) and the network resources required by the network service to be correctly deployed and executed on the physical and/or virtual topology 3) model of policy rules for managing the network service and mapping services dynamically to the network topology and network resources Using the above three models, the network is first defined as a topology. A service is then defined as a service topology layered above the network topology. A set of policy rules is then defined to manage the service. In this approach, service specific policy data models will be derived from a generic policy model, ensuring that policies have a common structure and can be easily reused as managed objects. Charter 3/4

13. The first use case that the working group will focus on will be VPN inter-datacenter traffic management, including the automated provisioning of site-to-site virtual private networks (VPNs) of various types (for example IPsec, tunnels, MPLS L2 and L3). The working group will communicate with other SDOs (MEF, ETSI) working on related issues. Work items for this working group include: 1) A Yang data model that represents a generic form of the physical and virtual topology and the resources of a network within a single administrative domain. 2) A Yang data model that describes network services, their resource requirements as well as service specific parameters. 3) A Yang data model that specifies policy rules controlling a network service. These policy rules are generic and cover operational and management aspects of the service and map the service to a network topology. The rules ideally are generic can be applied to any type of service model. Charter 4/4

14. SUPA Framework Service Management  Network service deployment, monitoring and management Network Manager  create, receive and maintain data models, map them into detail network device configurations. Network Elements  Can be managed via CLI, SNMP, or NETCONF. SUPA Data Models  Including topology, service and policy data models Comments and Progress  At this stage, a lot of issues are left open, maybe we should not call this draft as “architecture”  rename to “framework”  Reference to PCE architecture is removed because the scope change.  No more focus on 3 Apps (L2VPN, L3VPN, Inter DC Link) because of charter update  A lot more other comments, including updates according to charter updates.

15. How SUPA models processed Overview and Mapping Procedure  The overview of SUPA framework and entities involved during mapping  Primary procedure: when and how SUPA models be utilized Mapping Example  A example of traffic steering in an inter-DC environment Comments and Progress  Intentions should be clear to make easier understood (Brian)  Models should not be mapped into specific vendor’s command (Joan)  About acronyms and terminologies, and the yang model instances  The way models defined in SUPA will be processed is added  A vendor-neutral Yang model in south bound interface from other IETF workgroup is introduced Purpose  Guideline for mapping abstract configuration and policy into device-level configuration  Method of SUPA models being processed by software to produce configuration details for devices.

16. Topology Data Model An unified topology model at multiple levels Information model  Hierarchy of the topology information  Different topology types Data model  Topology at different level Current status:  [link] Updated on 21th Jan with new [link] framework diagram and modifications Comments on mailing list:  It will be good to also include non-IP scenario and be more specific on datalink topology  How and who to use the topology model to mapping service (updated in new version, mapping draft)  What is the relation of topology model to the service Yang model and configuration Yang model? Network Manager Service Management NE A F B D E Actual network topology K C I J Actual or abstract topologies are provided to applications. Different applications may get different (abstract) topologies from the controller abstraction

17. VPN Service Management Data Model Abstract  Defines a VPN service management yang data model and gives an example for DDC use case. Main content  Information model for L3VPN VPN instance name, type, address type/info,.etc.  SUPA VPN management model designed for DDC services DDC service initiation, VPN-based connectivity initiation, etc. Status  Updated on 2015 Jan according the latest charter Comments received  The name format of VPN model need to be checked  Some descriptions are not detailed enough module: SUPA-netl3vpn +--rw netl3vpnInstance* [instanceName] +--rw instanceName string +--rw servicType? enumeration +--rw afType? enumeration +--rw acIfs +--rw acIf* [vncAcIfId] +--rw acIfId string … module : ietf-supa-ddc +--rw ddc-operation +--rw create-ddc-Services | +--rw ddc-service* [tenant-name] | +--rw tenant-name string | +--rw dc-name* string | +--rw tenant-network-id* string | +--rw connection-type-between-dc? enumeration +--rw create-vpn-instances-for-ddc | +--rw vpn-instance* [vpn-name] …

18. Network Policy Data Model (option 1) Abstract This document describes a common core YANG data model for network policies, and additional YANG modules defining data models for policy related protocols and functions (such as Constraint based Routing, Network QoS, Traffic engineering, network management etc) Definitions  Policy Set  Policy Group  Policy Rule Usage Examples  Routing Policy  QoS Policy Policy set, policy rule and policy group

19. Network Policy Data Model (option 2) Abstract  This part describes an example for traffic optimization of DC case and corresponding YANG modules Content  Optimize traffic based on bandwidth  Specify nodes to pass/bypass based on requirement Status  Now this part is written in VPN Service Management Data Model draft.  Will be derived to a standalone one if more attention and contribution are attracted. Comments received  Should be designed more extendable.  May need to merge similar policies to make more simple and general +--rw optimize-traffic-Services | +--rw optimize-traffic-service* [vpn- name] | +--rw vpn-name string | +--rw bandWidth? uint32 | +--rw latency? uint32 +--rw specify-flow-paths +--rw specify-flow-path* [vpn-name] +--rw vpn-name string +--rw vpn-type? enumeration +--rw flow-name? string +--rw threshold? uint32 +--rw pass-node* string +--rw bypass-node* string

20. Conclusion Next steps?

21. Backup 1: How SUPA models processed(details) Network resource data is “GET” by Service Management for reference Based on the network resource data, Service Management generate policy data or service management data Service Management “POST” the policy data or service management data to Network Manager Network Manager translates the policy data or service management data into device-level configurations basing on its own logic Network Manager Network Elements (routers, switches, etc) RESTCONF / NETCONF Service Management SUPA Data Models Network Elements (routers, switches, etc) Service Data Model Policy Data Model Topology Data Model Network Manager Topology Data Model