Cisco Live - Building Agile Agnostic end to end Service Orchestration Tail-F

Building an Agile Technology Agnostic

end-to-end Service Orchestration

Renato Fichmann, Solutions Architect BRKSPG – 2530

© 2015 Cisco and/or its affiliates. All rights reserved. Cisco Public BRKSPG – 2530

It’s all about Journey… and this has been mine so far

2006

2013

3


Chinese Proverb by Lao-Tzu

4


•  Introduction •  Agile and DevOps

•  Definition of Service Orchestration

•  Defining and Modeling a Service

•  Use Cases

•  QA

Agenda

5


Traditional Service Creation Cycle

•  Service Definition •  Requirements Capture •  Business Analysis •  Business Case •  Service Proposal

Standard service creation model

•  Service Development –  Kick-off –  Design –  Development –  Deployment –  Field Enablement –  Productization

•  Service Release –  Service Maintenance –  Service Reviews –  Service Improvements –  Service Retirement

Activities & Methodologies

Service Lifecycle

6 to 24 months cycles

6


Operational Complexity Impacts Service Activation

Why?

Traffic

Time

Operational Complexity

Feature Complexity

Time Time

NEEDED

•  Manual and error-prone processes

•  Multi-vendor networks with stove-pipe solutions

•  Closed OSS solutions result in vendor lock-in

7


The pursue of cost reduction CapEx vs OpEx

Capital Expenditure

Operational Expenditure

Investing in Agility or products that support

cloud, SDN & NFV

Agile product nature and Orchestration

capabilities

8


Summary

Waterfall Service Creation Process

Operational Complexity Impacting

Activation

CapEx vs. OpEx Battle

9


CE11

CE12

CE21

CE31

Use case for today’s Session: L2 VPN E-line

PE11 PE12

PE21 PE31

•  To deliver L2VPN “E-Line” services between customer’s locations

•  Multi-Vendor/different chassis/OS Versions in the network environment

•  This example will be used throughout the rest of the today’s presentation.

10


•  Introduction •  Agile and DevOps

•  Definitions •  Agile Business Architecture

•  Definition of Service Orchestration •  Defining and Modeling a Service •  Use Cases •  Conclusion

Agenda

11


Agile

12


One does not simply define DevOps… but let’s try!

13


Continuous Development

Continuous Delivery

Continuous Integration

Automation

Configuration Management

Team Work

DevOps

14


Agile + DevOps A new way of doing business

“ah ha!” Ka ching!

Business Development Operations

Agile Development fixes this

DevOps fixes this

Business Process

15


Roles in Agile Service Creation Who does what in the Service Orchestration People Chain

Service Owner Service Engineer Orchestrator Engineer

Defines the Service

Translates the Service into

Network Configurations

Automates and Orchestrates the

Network Configuration

16


Evolving your OSS Architecture Technology Evolution Through Recent Times

Technology progressions of hardware, software and standardization of API’s allows us to better design, deploy, integrate and maintain network services!

Hardware/OS

Software

Northbound API

Southbound API

Solaris Solaris Linux Hypervisor SPARC LDOMs x86 x86

Monolithic, Object Multithread, Elastic, Functional Oriented Parallel Cloud

TCP/UDP Proprietary, XML, SOAP, MTOSI,3GPP CORBA Java Netconf

CLI, Telnet, SSH, SNMPv3 JSON,REST Console SNMP NetFlow Netconf

17


Agile Business Architecture

Principles based agile architecture

•  Flexible and modular approach to supporting new services

•  Reduces interdependencies across systems and resources •  Supports new services on a technology agnostic basis

•  Reduces complexity of fulfilling and assuring new and existing services

18


Agile Business Architecture – Operational Modularity FROM: Complex, Inflexible, Inter-Dependent

Processes

Technology Domains Customer BU

Service Orchestration

Fulfillment

Assurance

Design & Plan

Build

TO: Loosely Coupled, Semi-Autonomous Production Units

Service Suppliers

19


•  Introduction •  Agile and DevOps •  Definition of Service Orchestration

•  Definitions on Manual, Automated, Orchestrated •  Workflows and Models •  Art of Abstracting •  Tail-F NCS Architecture for Service Orchestration

•  Defining and Modeling a Service •  Use Cases •  Conclusion

Agenda

20


Manual, Automated and Orchestrated Key Definitions

Manually done by a human being e.g.: operator initiated action

Manual/

Mechanized

Basic to intermediate level automatic execution of repetitive tasks e.g.: batch scripts, simple workflows

Automated

A set of automated operations executed and monitored by a computer software, with capabilities including pre flight checks, automated rollback, failure prevention, notifications etc

Orchestrated

21


Models

Workflows

22


Models

Workflows

module l2vpn{ namespace “http://com/example/l2mplsvpn”; prefix l2vpn; import { ... }augment /ncs:services {

list l2vpn { leaf intf-name { ... } leaf pw-id { ... } leaf customer { ... }

23


Industry is moving towards Models YANG RFCs and Links

•  RFC 6020 YANG Base Specification •  RFC 6087 Guidelines for YANG Authors and Reviewers •  RFC 6110 Mapping YANG and Validating NETCONF Content •  RFC 6244 NETCONF+Yang Architectural Overview •  RFC 6643 Translation of SMIv2 MIBs to YANG •  RFC 6991 Common Yang Data Types •  RFC 7223, 7224 YANG Modules for Interface Management •  RFC 7277 YANG Module for IP Management •  RFC 7317 YANG Module for System Management •  RFC 7407 YANG Module for SNMP Configuration

! https://datatracker.ietf.org/wg/netmod/charter/ ! https://www.ietf.org/iesg/directorate/yang-doctors.html ! http://www.yang-central.org/ 24


ab.strac.tion /ab’srakSH( )n/ noun

The process of considering something independently of its associations, attributes, or concrete accompaniments.

Origin: abstrahere abstractio

abstract

Latin

English

Latin

abstraction draw away

late Middle English

25


The Art of Abstracting OSS Abstraction Architecture – Next Generation Networks SDN & NFV

Network management systems

SDN controllers

NFV orchestrators

Service layer

OSS

APIs

Orc

hest

rato

rs VNF managers

SDN-enabled APIs

APIs

APIs

Element management systems

VNF managers

SDN-enabled

Network elements VNFs

SDN-enabled

APIs APIs

26


The Art of Abstracting OSS Abstraction Architecture – Next Generation Networks SDN & NFV

Network management systems

SDN controllers

NFV orchestrators

Service layer

OSS

APIs

Orc

hest

rato

rs

VNF managers

SDN-enabled APIs

APIs

APIs

Element management systems

VNF managers

SDN-enabled

Network elements VNFs

SDN-enabled

• Hides the complexity • Simplify and streamline service fulfilment and assurance

•  Increase service agility • Development focused on service fulfilment OSS functions

APIs APIs

27


cpe-01

r2

esc-01

br-outside-01

Gig0/1

cisco-isr eth4.100

eth1

eth4

compute-01

cisco-ucs esc

ovs-network

Topology: dt_mvp1_underlayTags: sjc_lab, underlay

cpe-01

router-01

cisco-isr

ipsec_vpn

Topology: dt_mvp1_overlayTags: overlay

ipsec_tunnel

cisco-csr1000v

cpe tunnel

cpe-01 tunnel-01 router-01

uni cpe csr nni

Virto: myvpnTags: sjc_lab

vFirewall

VRFovs-

network

vWSA

vBridge

cisco-asa100V

cisco-vwsa

vBridge

ovs-network

Virtual Routercpe

br-01

bridge

bridge inside outside

wsa

router firewall firewall gateway

wsa-01

firewall-01 br-02

br-01

externalnetwork

internet

br-internet-01

IVRF

firewall-01

wsa-01

eth0

eth1

eth2

Gig1 Gig2

Gig1 Gig2

eth0

Gig0/1 cpe-01.Gig0/1 router-01.Gig1Gig1 Gig2

Unmanaged IP Network

tp2

tp1

eth4.101

eth4

eth1

tp3

Underlay

Overlay

Service Chain

Business logic for the service, what type of service is requested

Topology Overlay, what elements are needed and how they planned

to be connected

Applying the configuration on all

elements in between to fulfill the service intent


Abstracting: Service, Operations and Device Models Multi-Vendor abstraction

Devices modeled and maintained by

trust entity

Device operations modeled according to

vendor specs

Services modeled independently from devices

29


Making easy for OSS/BSS/NMS consumption The Power of NBI – North Bound Interfaces

Managed Network

Adapters

NBI

OSS

NMS GUI

BSS NMS

User Portal Admin Portal

30



Managed Network

Adapters

NBI

OSS

NMS GUI

BSS NMS


APIs

Industry Standards

Model Driven, Auto

rendered

Create, Read,

Update, Delete

Secure

31



Managed Network

Adapters

NBI

OSS

NMS GUI

BSS NMS


APIs

Industry Standards

Model Driven, Auto

rendered

Create, Read,

Update, Delete

Secure

$ curl -u admin:admin -s http://localhost:8080/api <api xmlns="http://tail-f.com/ns/rest" xmlns:y="http://tail-f.com/ns/rest"> <version>0.5</version> <config/> <running/> <operational/> <operations/> <rollbacks/> </api>

32



Managed Network

Adapters

NBI

OSS

NMS GUI

BSS NMS


APIs

Industry Standards

Model Driven, Auto

rendered

Create, Read,

Update, Delete

Secure


$ curl -u admin:admin -s http://localhost:8080/api/config/devices/device-group/C <device-group xmlns="http://tail-f.com/ns/ncs" xmlns:y="http://tail-f.com/ns/rest" xmlns:ncs="http://tail-f.com/ns/ncs"> <name>C</name> <device-name>ce0</device-name> <device-name>ce1</device-name> <device-name>ce3</device-name> <device-name>ce4</device-name> <device-name>ce5</device-name> <device-name>ce6</device-name> <device-name>ce7</device-name> <device-name>ce8</device-name>

33



Managed Network

Adapters

NBI

OSS

NMS GUI

BSS NMS


APIs

Industry Standards

Model Driven, Auto

rendered

Create, Read,

Update, Delete

Secure


$ curl -u admin:admin -s http://localhost:8080/api/config/devices/device-group/C <device-group xmlns="http://tail-f.com/ns/ncs" xmlns:y="http://tail-f.com/ns/rest" xmlns:ncs="http://tail-f.com/ns/ncs"> <name>C</name> <device-name>ce0</device-name> <device-name>ce1</device-name> <device-name>ce3</device-name> <device-name>ce4</device-name> <device-name>ce5</device-name> <device-name>ce6</device-name> <device-name>ce7</device-name> <device-name>ce8</device-name>

$ curl -u admin:admin -s http://localhost:8080/api/operational/topology/connection/pe-link-4 <connection xmlns="http://com/example/l3vpn" xmlns:y="http://tail-f.com/ns/rest" xmlns:l3vpn="http://com/example/l3vpn"> <name>pe-link-4</name> <endpoint-1> <device>p2</device> <interface>TenGig0/0/2</interface> </endpoint-1> <endpoint-2> <device>pe3</device> <interface>GigabitEthernet0/0/0/10</interface> </endpoint-2> </connection>

34


Network Services Orchestrator, Enabled by Tail-f

Network Engineer

Management Applications

Network Service Orchestrator

•  Industry-Leading, Real-Time Network Service Orchestration

•  Multi-Vendor, Open Standards

•  Agile, Model-Driven Service Creation

•  Physical and/or Virtual Devices

35


Network Services Orchestrator, Enabled by Tail-f

Transaction Database

(CDB)

Service Manager

Device Manager

Network Element Drivers

x86 Physical Virtual

Service Intent Service Intent Service Intent

Transactional Database Allows full CRUD capabilities to Services.

Service Manager Interprets Service Intent with Service Instantiation Rules and derives configuration deltas.

Device Manager manages derived and validated configurations in a transaction manner towards derived infrastructure.

Network Element Drivers Abstract the interfaces to the devices allowing 3rd party infrastructure to participate in Service Instantiation

Service Models written in Yang Abstract Service from underlying physical devices

Domain Controller

Rest/NetConf/Yang

Cisco NSO

Web GUI CLI

36


Summary •  Technology evolving towards API standardization using Agile & Devops

•  Agile Business Architecture needed to cope with new service oriented technologies

•  Automation & Orchestration is a must have

•  Models become an evolution of traditional workflows

•  Abstracting everything (SOA, APIs, inter-dependency, etc)

•  Role of North Bound API into OSS, BSS and NMS

•  Cisco NSO Enabled by Tail-F as an option to be considered

38


•  Introduction •  Agile and DevOps •  Definition of Service Orchestration •  Defining and Modeling a Service

•  Service Intention •  Service Modeling •  Service Assurance

•  Use Cases •  Conclusion

Agenda

39


Framework used by Cisco Services Steps-by-step process

Step 1 •  Service Intention

Step 2 •  Model the What

Step 3 •  Model the Service

Step 4 •  Service Assurance

Multiple Iterations

40


Business Logic Example Model Driven Architectural Approach

Prem Access WAN Compute

CPE

L2NID Router x86

Metro VNF2

Service Chaining

DCI EDGE Others

Router Firewall Other VNFs

Service Intention

Service Instantiation

Infrastructure

X-Domain Orchestration

Service Definition Service Definition

Service Definition

Router VNF1

Others

3rd Party Assurance

41

© 2015 Cisco and/or its affiliates. All rights reserved. Cisco Public BRKSPG – 2530 Step 1 •  Service Intention

Step 2 • Model the What

Step 3 • Model the Service


42


Service Intention Definitions

Intent Should

Intend Model should have

Working with Intents require

be Portable be Abstracted

define the What not focus solely on

networking

Subjects Actions

Constraints Conditions

Data Based Interactions Configuration tree (desired) Operational tree (realized) Karaf CLI based console Status values (In process,

provisioned etc)

43


Service Intention – Defining the What

•  Provides isolated P2P IP communication between customer sites

Service Description

•  Access Interface: PE device and interface where the customer site is connected

•  Encapsulation: How data is encapsulated over pseudo wire

Service Parameters

44


CE31

Service Intention – Defining the What Informal Service Definition: Layer 2 P2P VPN

CE11

CE12

CE21

PE11 PE12

PE21 PE31

Each VPN Instance has 2 attachments

Bi-directional traffic between CE21 – CE11 Bi-directional traffic between CE21 – CE12 Bi-directional traffic between CE21 – CE31

45


Service Intention – Example of Subjects/Attributes

VPN Instance Name Unique Identifies describing an instance of a deployed P2P L2 MPLS VPN

Pseudo wire Identifier Used to provide a descriptive name of the service instance

2x Attachment Circuit

Unique number used to identiofy the pseudowire connection across MPLS between two PE routers

Device Each attachment circuit is connected to a device (PE Router) -  Cisco IOS -  Cisco IOS XR

Interface Each attachment circuit contains an interface or subinterface

Remote IP

Each attachment circuit is connected to a remote end identified by a loopback address of the other PE router All PE routers in the network have Loopback0 addresses in the 10.0.0.x/24 network





47


Each VPN instance can have

two links (P2P) •  Data Path in L2 VPN:

•  pw-id •  vpn-name (key) •  Customer (required) •  link/ •  link/device (required) •  link/intf-number •  link/remoteip

Modem the what – Example of data path

Intf-number remoteip RUdevice K

link L

customer pw-id RRname K

l2pvn L

There can be many VPN instances of the

service

Each VPN instance is

assigned to a customer

48





49


Service Blueprints Exposing Available Services from the Orchestrator

•  A Service Blueprint is an abstract representation of a service that can be ordered through the UI or NB API.

•  Every Service Blueprint should be associated with a Service Offering.

•  The orchestrator should be aware of all Service Models that may be requested and these are preloaded into the Orchestrator.

Service Models

Instantiation Logic

Device Models

Service Requests / BSS

Orchestrator

Device Drivers

Service API

Compiled

Infrastructure

50


Yang Module Contents

Header information Imports & Includes

Type definitions

Configuration & Operational data declarations

Action (RPC) & Notification declarations

51


Model the Service – Example of a Service Model module l2vpn{ namespace “http://com/example/l2mplsvpn”; prefix l2vpn; import ietf-inet-types { prefix inet; } import tailf-ncs { prefix ncs; } import tailf-common { prefix tailf; } augment /ncs:services {

list l2vpn { leaf intf-name { ... } leaf pw-id { ... } leaf customer { ... } list link { min-element 2; max-element 2; leafref device { ... } leaf intf-number { ... } leaf remoteip { ... } } } } }.

•  YANG statements representing the informal design: •  There can be many service instances •  Each instance has exactly 2 PE-CE

links

52


Model the Service – Example of a Device Model Cisco IOS: Interface GigabitEthernet0/9 description Link to CE11 xconnect 10.0.0.21 1001121 encapsulation mpls

Cisco IOS XR: l2vpn xconnect group ACME p2p CE11-to-CE21 interface GigabitEthernet0/0/0/9 neighbor 10.0.0.11 pw-id 1001121 ! !!interface GigabitEthernet0/0/0/9 description Link to CE21 l2transport!

•  The configuration is usually provided by a network engineer

•  Different devices have different configuration for the same service

53





54


node.4node.3 node.5

network topology modelnode.1

node.2

nodeslinks termination_points

link.1

link.2

link.3 link.4

tp.1

tp.2

tp.3

tp.4 tp.5 tp.6 tp.7 tp.8

•  Topology Comprises a set of Nodes and Links. •  Links are P2P and Unidirectional. •  Model is on-boarded to the Physical and Virtual Infrastructure.

Model Assurance for all Fundamental Constructs Nodes, Links, Termination Points

55


Service Assurance – Example Functional Architecture

Presentation/Dashboards & Reports SP/Ops

Dashboard Tenant

Dashboard

Service Assurance APIs Service

(Fault, Perf, Inventory) Resource/Device

(Fault, Perf, Inventory)

External OSS Systems (MoM, Ticketing, Tenant Portals, etc)

Provision Assurance

System

Provision Managed System

Ser

vice

Orc

hest

ratio

n S

olut

ion

A

ssur

ance

Pol

icy

& D

efin

ition

Assurance Data Analysis Service Impact

Analysis Fault & Cause

Analysis Real time Service & Resource Inventory

Performance Analysis

Log Analysis

Assurance Data collection & aggregation Events/Alarms Logs Metric

Open Big Data Distribution & Persistence

Inventory Details Synthetic Tests

Optimization &

Remediation

Physical Devices

DC Infrastructure (Compute, Network,

Storage)

Virtual Services

Controllers

Man

aged

S

yste

ms

Managed System Instrumentation

Virtual Devices

56


Key Pillars: Assurance & Orchestration Integration Enabling Closed Loop System

•  Service Assurance Definition Part of the Service Model

•  Orchestration provisions Assurance

•  Assurance monitors Orchestration

•  Orchestration provides models to assurance to aid with analysis

•  Outputs of assurance analysis provides to orchestration recommendation for remediation and optimization

•  Assurance & Orchestration Presented in Common Portals

Ser

vice

Orc

hest

ratio

n

Ser

vice

A

ssur

ance

D

efin

ition

In

stru

men

tatio

n R

emed

iatio

n O

ptim

izat

ion

Service A

ssurance

Ser

vice

&

Topl

ogy

Mod

els

Tenant & Operator Dashboards

Instrumentation

Data C

ollection A

nalysis

2

3

4

5

6

Provision Assurance

Monitor Orchestration

Aid Analysis

Aid Remediation Aid Optimization

Common Presentation

1

1

23

4

5

6

57


Service Intention

Service Instantiation

Infrastructure

•  Service Intent done through Modeling Languages that Abstract out the “How” and “Where”

•  Service to be looked at summarily across the implementation domains.

•  Orchestrator to have both Service and Device component. Each independent of the other. Answers the “How”.

•  Orchestrator to be able to Instantiate a Service Across the derived Topology (Infrastructure). Answer the “Where”.

•  Impact model follows the service model

Summary

Assurance


•  Introduction •  Agile and DevOps •  Definition of Service Orchestration •  Defining and Modeling a Service •  Use Cases •  Conclusion

Agenda

59


New Service – Security-as-a-Service Business Drivers: Use Case:

•  Value-added security services to enterprise customers

•  More agile and dynamic service provisioning

•  Managed services for enterprise customers

•  Dynamic L3-L7 service chaining using service-oriented network API

Case Study

Cisco NSO

HW

SW

HW

HW HW

SW

OpenFlow

Self Service Portal

SW SW

Branches (thousands) Datacenters (dozens)


US Service Provider – VPN provisioning Business Drivers: Use Case:

•  Speed, innovative services, OPEX Fast delivery of various types (e.g., L3 MPLS) of end-to-end VPNs

•  Provision complex VPNs spanning multiple vendors using network-wide, transactions

•  Juniper MX series core routers •  Cisco for PE •  Overture, Adtran and ADVA for CE •  Support for provisioning, updating and

removing VPNs using minimal sets of diffs •  API integration with customer self-service

portal, OSS, and analytics systems

Case Study

61


Network Automation Business Drivers: Use Case:

Scaling operations Unified Network API

Case Study

Network Engineers Config file

backup

Multi-Vendor Devices

Perl Scripts

Networking Applications

Network Engineer

Multi-Vendor Devices

Cisco NSO

62


European Service Provider NG Network Business Drivers: Use Case:

• Radical simplification of both network and OSS to reduce OPEX

• Faster deployment of services

•  Foundation for real-time OSS •  Real-time transactional control •  Provide service-oriented API for app. Services Customer requests vendor support NETCONF

“ We believe carriers can no longer afford to hard-code services into the OSS if they want to get to market quickly with new services. The Tail-f NCS solution, with both services and the network modeled in a standardized high-level language, shortens time to market, increases vendor independence and dramatically improves the cost structure. This SDN solution is a key component in our next generation network architecture.”

- Axel Clauberg, Vice President, Customer

Case Study

Wholesale OTT Apps Business- Services BSS Engineer

CLI

Realtime OSS

Service Modeling (e.g., Yang)

Network Modeling (Yang)

Cisco NSO

Customer’s Cloud Enabled SDN Architecture.


Service Chaining Case Study

Traffic Shaper IPS/IDS Content

Filtering WAN

acceleration Firewall

Network Element Drivers

OpenFlow Controller Cluster

Device Manager

Service Manager

Tail-f Network Control System Flowlet Models

Device Models

Network-wide CLI, WebUI

Flowlets

Flowlets

Flowlets

NETCONF, REST, Java

Network Engineer

Management Applications

Device Models

A

B

A

B 64


Conclusion •  Adopt Agile/DevOps whenever applicable

•  Abstract, Automate, Orchestrate across your environment

•  Embrace Agility, Open Standard, Multi Vendor end to end capable orchestration products

•  Service Activation and Provisioning needs to be efficient, cheap and error-prone

•  Consider Cisco NSO product and Cisco Advanced Services offerings when implementing an Agile, Technology Agnostic, end-to-end Service Orchestration solution.

65


Questions?

66


Complete Your Online Session Evaluation

Don’t forget: Cisco Live sessions will be available for viewing on-demand after the event at CiscoLive.com/Online

•  Give us your feedback to be entered into a Daily Survey Drawing. A daily winner will receive a $750 Amazon gift card.

•  Complete your session surveys though the Cisco Live mobile app or your computer on Cisco Live Connect.

67


References •  http://www.tailf.com

•  http://www.netconfcentral.org/

•  http://www.yang-central.org/

•  https://datatracker.ietf.org/wg/netmod/charter/

•  https://www.ietf.org/iesg/directorate/yang-doctors.html

•  http://www.yang-central.org/

69


Cisco NSO, Enabled by Tail-f - Architecture

70


Open Standard and Multi-Vendor Capabilities

Technology converging towards open standards,

interoperability, community-driven, collaboration,

openness

Infrastructure evolution cycles, technology refresh, swift in vendor preference,

pricing x feature constraints, flexibility required to provide

dynamic device support

Isolation between business rules, service models from

device drivers becomes essential architecture

principle to ensure multi-vendor capabilities

71


From Complexity to Simplicity and Automation

FROM MONTHS TO MINUTES

Automated Self-Service On-Demand

Architect It Design It Where Can We Put It?

Procure It Install It Configure It Secure It Is It Ready?

Manual

Service-Oriented Self-Service: Automated Provisioning

Elasticity (Capacity-on-Demand)

72

Cisco Live - Building Agile Agnostic end to end Service Orchestration Tail-F

Software

Transcript of Cisco Live - Building Agile Agnostic end to end Service Orchestration Tail-F