Status of Work

Feb 2, 2015

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

Service APINetwork 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

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

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

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-00 / part of draft-adel-vpn-service-management-model-00

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 ConnectivityDC 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

SUPA DDC Use Case – Cont’• Use cases

Dynamic Link Configuration for DCSome 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 ConnectivitySome 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 updatesIncorporate use cases from operators, universities NOGs and vendors

Use Case for VPC

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.

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

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

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

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

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

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.

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.

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 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 NEA

F

B

DE

Actual network topology

KC

I

J

Actual or abstract topologies are provided to applications. Different applications may get different (abstract) topologies from the controller

abstraction

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]…

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

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

Conclusion• Next steps?

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