Building an Agile Technology Agnostic end-to-end Service Orchestration Renato Fichmann, Solutions Architect BRKSPG 2530

Size: px
Start display at page:

Download "Building an Agile Technology Agnostic end-to-end Service Orchestration Renato Fichmann, Solutions Architect BRKSPG 2530"

Transcription

1

2 Building an Agile Technology Agnostic end-to-end Service Orchestration Renato Fichmann, Solutions Architect BRKSPG 2530

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

4 Chinese Proverb by Lao-Tzu

5 Agenda Introduction Agile and DevOps Definition of Service Orchestration Defining and Modeling a Service Use Cases QA

6 Traditional Service Creation Cycle Activities & Methodologies 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 Lifecycle Service Release Service Maintenance Service Reviews Service Improvements Service Retirement 6 to 24 months cycles

7 Operational Complexity Impacts Service Activation Traffic Feature Complexity Operational Complexity NEEDED Time Time Time Why? Manual and error-prone processes Multi-vendor networks with stove-pipe solutions Closed OSS solutions result in vendor lock-in

8 The pursue of cost reduction CapEx vs OpEx Capital Expenditure Investing in Agility or products that support cloud, SDN & NFV Operational Expenditure Agile product nature and Orchestration capabilities

9 Summary Waterfall Service Creation Process Operational Complexity Impacting Activation CapEx vs. OpEx Battle

10 Use case for today s Session: L2 VPN E-line To deliver L2VPN E-Line services between customer s locations Multi-Vendor/different chassis/os Versions in the network environment CE11 CE12 This example will be used throughout the rest of the today s presentation. CE21 PE11 PE12 CE31 PE21 PE31

11 Agenda Introduction Agile and DevOps Definitions Agile Business Architecture Definition of Service Orchestration Defining and Modeling a Service Use Cases Conclusion

12 Agile

13 One does not simply define DevOps but let s try!

14 DevOps Configuration Management Continuous Integration Team Work Automation Continuous Development Continuous Delivery

15 Agile + DevOps A new way of doing business Business Process ah ha! Ka ching! Business Development Operations Agile Development fixes this DevOps fixes this

16 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

17 Evolving your OSS Architecture Technology Evolution Through Recent Times Hardware/OS Software Northbound 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 Southbound API CLI, Telnet, SSH, SNMPv3 JSON,REST Console SNMP NetFlow Netconf Technology progressions of hardware, software and standardization of API s allows us to better design, deploy, integrate and maintain network services!

18 Agile Business 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 Principles based agile architecture

19 Agile Business Architecture Operational Modularity FROM: Complex, Inflexible, Inter-Dependent Processes TO: Loosely Coupled, Semi-Autonomous Production Units Service Suppliers Technology Domains Customer BU Service Orchestration Fulfillment Assurance Design & Plan Build

20 Agenda 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

21 Manual, Automated and Orchestrated Key Definitions Manual/ Mechanized Manually done by a human being e.g.: operator initiated action Automated Basic to intermediate level automatic execution of repetitive tasks e.g.: batch scripts, simple workflows Orchestrated A set of automated operations executed and monitored by a computer software, with capabilities including pre flight checks, automated rollback, failure prevention, notifications etc

22 Workflows Models

23 Workflows Models module l2vpn{ namespace ; prefix l2vpn; import {... } augment /ncs:services { list l2vpn { leaf intf-name {... } leaf pw-id {... } leaf customer {... }

24 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

25 ab.strac.tion /ab sraksh( )n/ noun The process of considering something independently of its associations, attributes, or concrete accompaniments. Origin: Latin abstrahere draw away Latin abstractio English abstract abstraction late Middle English

26 Orchestrators The Art of Abstracting OSS Abstraction Architecture Next Generation Networks SDN & NFV Service layer APIs OSS APIs APIs SDN controllers NFV orchestrators APIs APIs VNF managers SDN-enabled Network management systems APIs VNF managers SDN-enabled Element management systems VNFs SDN-enabled Network elements

27 Orchestrators The Art of Abstracting OSS Abstraction Architecture Next Generation Networks SDN & NFV Hides the complexity Service layer APIs Simplify and streamline service fulfilment and assurance Increase service agility Development focused on service fulfilment OSS functions APIs SDN controllers VNF managers SDN-enabled VNF managers SDN-enabled APIs OSS NFV orchestrators APIs Network management systems Element management systems APIs APIs VNFs SDN-enabled Network elements

28 Service Chain Business logic for the service, what type of service is requested Overlay 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 Underlay

29 Abstracting: Service, Operations and Device Models Multi-Vendor abstraction Services modeled independently from devices Devices modeled and maintained by trust entity Device operations modeled according to vendor specs

30 Making easy for OSS/BSS/NMS consumption The Power of NBI North Bound Interfaces Admin Portal OSS NMS GUI NMS User Portal BSS NBI Adapters Managed Network

31 Making easy for OSS/BSS/NMS consumption The Power of NBI North Bound Interfaces Admin Portal OSS NMS GUI NMS User Portal BSS Industry Standards NBI Secure APIs Model Driven, Auto rendered Adapters Managed Network Create, Read, Update, Delete

32 Making easy for OSS/BSS/NMS consumption The Power of NBI North Bound Interfaces $ curl -u admin:admin -s <api xmlns=" xmlns:y=" <version>0.5</version> Admin Portal NMS GUI User Portal <config/> OSS <running/> NMS BSS <operational/> <operations/> <rollbacks/> NBI </api> Adapters Secure Industry Standards APIs Model Driven, Auto rendered Managed Network Create, Read, Update, Delete

33 Making easy for OSS/BSS/NMS consumption The Power of NBI North Bound Interfaces $ curl -u admin:admin -s <api xmlns=" xmlns:y=" Industry <version>0.5</version> Admin Portal NMS GUI User Portal Standards <config/> $ curl -u admin:admin -s OSS NMS BSS <running/> <operational/> <device-group xmlns=" xmlns:y=" <operations/> xmlns:ncs=" <rollbacks/> <name>c</name> NBI </api> <device-name>ce0</device-name> APIs <device-name>ce1</device-name> Secure <device-name>ce3</device-name> <device-name>ce4</device-name> <device-name>ce5</device-name> Adapters <device-name>ce6</device-name> <device-name>ce7</device-name> <device-name>ce8</device-name> Create, Read, Managed Network Update, Delete Model Driven, Auto rendered

34 Making easy for OSS/BSS/NMS consumption The Power of NBI North Bound Interfaces $ curl -u admin:admin -s <api xmlns=" xmlns:y=" Industry <version>0.5</version> Admin Portal NMS GUI User Portal Standards <config/> $ curl -u admin:admin -s OSS NMS BSS <running/> <operational/> <device-group xmlns=" xmlns:y=" <operations/> xmlns:ncs=" $ curl -u admin:admin -s <rollbacks/> <name>c</name> NBI </api> <device-name>ce0</device-name> Model <device-name>ce1</device-name> xmlns:l3vpn=" Driven, Secure <device-name>ce3</device-name> <name>pe-link-4</name> Auto rendered <device-name>ce4</device-name> <endpoint-1> <device-name>ce5</device-name> Adapters <device>p2</device> <device-name>ce6</device-name> <interface>tengig0/0/2</interface> <device-name>ce7</device-name> </endpoint-1> <device-name>ce8</device-name> <endpoint-2> <device>pe3</device> Create, Read, Managed Network <interface>gigabitethernet0/0/0/10</interface> Update, Delete <connection xmlns=" xmlns:y=" APIs </endpoint-2> </connection>

35 Network Services Orchestrator, Enabled by Tail-f Management Applications Network Service Orchestrator Network Engineer Industry-Leading, Real-Time Network Service Orchestration Multi-Vendor, Open Standards Agile, Model-Driven Service Creation Physical and/or Virtual Devices

36 Network Services Orchestrator, Enabled by Tail-f Web GUI Rest/NetConf/Yang Service Intent Service Intent Service Intent Cisco NSO Service Manager Device Manager Network Element Drivers CLI Transaction Database (CDB) Service Models written in Yang Abstract Service from underlying physical devices Service Manager Interprets Service Intent with Service Instantiation Rules and derives configuration deltas. Transactional Database Allows full CRUD capabilities to Services. Device Manager manages derived and validated configurations in a transaction manner towards derived infrastructure. Physical x86 Virtual Domain Controller Network Element Drivers Abstract the interfaces to the devices allowing 3 rd party infrastructure to participate in Service Instantiation

37

38 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

39 Agenda Introduction Agile and DevOps Definition of Service Orchestration Defining and Modeling a Service Service Intention Service Modeling Service Assurance Use Cases Conclusion

40 Framework used by Cisco Services Steps-by-step process Step 1 Service Intention Step 4 Service Assurance Multiple Iterations Step 2 Model the What Step 3 Model the Service

41 Business Logic Example Model Driven Architectural Approach Service Definition Service Definition Service Definition Service Intention X-Domain Orchestration Prem Access WAN Compute Service Instantiation CPE Metro Router Service Chaining VNF1 VNF2 Infrastructure L2NID Router x86 Others 3 rd Party DCI EDGE Others Router Firewall Other VNFs Assurance

42 Step 1 Step 2 Step 3 Step 4 Service Intention Model the What Model the Service Service Assurance

43 Service Intention Definitions Intent Should be Portable be Abstracted define the What not focus solely on networking Intend Model should have Subjects Actions Constraints Conditions Working with Intents require Data Based Interactions Configuration tree (desired) Operational tree (realized) Karaf CLI based console Status values (In process, provisioned etc)

44 Service Intention Defining the What Service Description Provides isolated P2P IP communication between customer sites Service Parameters Access Interface: PE device and interface where the customer site is connected Encapsulation: How data is encapsulated over pseudo wire

45 Service Intention Defining the What Informal Service Definition: Layer 2 P2P VPN Bi-directional traffic between CE21 CE11 Bi-directional traffic between CE21 CE12 Bi-directional traffic between CE21 CE31 CE11 CE12 Each VPN Instance has 2 attachments PE11 PE12 CE21 CE31 PE21 PE31

46 Service Intention Example of Subjects/Attributes VPN Instance Name Pseudo wire Identifier 2x Attachment Circuit Device Interface Remote IP Unique Identifies describing an instance of a deployed P2P L2 MPLS VPN Used to provide a descriptive name of the service instance Unique number used to identiofy the pseudowire connection across MPLS between two PE routers Each attachment circuit is connected to a device (PE Router) - Cisco IOS - Cisco IOS XR Each attachment circuit contains an interface or subinterface 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 x/24 network

47 Step 1 Step 2 Step 3 Step 4 Service Intention Model the What Model the Service Service Assurance

48 Modem the what Example of data path Data Path in L2 VPN: pw-id There can be many VPN instances of the service Each VPN instance can have two links (P2P) vpn-name (key) Customer (required) link/ L l2pvn Each VPN instance is assigned to a customer link/device (required) K name R customer R pw-id link/intf-number link/remoteip L link K device U Intf-number R remoteip

49 Step 1 Step 2 Step 3 Step 4 Service Intention Model the What Model the Service Service Assurance

50 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 Requests / BSS Service API Compiled Orchestrator Service Models Instantiation Logic Device Models Device Drivers Infrastructure

51 Yang Module Contents Header information Imports & Includes Type definitions Configuration & Operational data declarations Action (RPC) & Notification declarations

52 Model the Service Example of a Service Model module l2vpn{ namespace ; 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 {... } YANG statements representing the informal design: There can be many service instances Each instance has exactly 2 PE-CE links. } list link { min-element 2; max-element 2; leafref device {... } leaf intf-number {... } leaf remoteip {... } } } }

53 Model the Service Example of a Device Model Cisco IOS: Interface GigabitEthernet0/9 description Link to CE11 xconnect encapsulation mpls Cisco IOS XR: l2vpn xconnect group ACME p2p CE11-to-CE21 interface GigabitEthernet0/0/0/9 neighbor pw-id !!! 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

54 Step 1 Step 2 Step 3 Step 4 Service Intention Model the What Model the Service Service Assurance

55 Model Assurance for all Fundamental Constructs Nodes, Links, Termination Points node.1 node.2 tp.1 tp.2 link.1 link.2 links tp.3 tp.4 network topology model node.3 link.3 nodes node.4 link.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. node.5 termination_points

56 Service Orchestration Solution Service Assurance Example Functional Architecture Assurance Policy & Definition Managed Systems Provision Assurance System Optimization & Remediation Presentation/Dashboards & Reports SP/Ops Dashboard Real time Service & Resource Inventory External OSS Systems (MoM, Ticketing, Tenant Portals, etc) Tenant Dashboard Service Assurance APIs Resource/Device (Fault, Perf, Inventory) Assurance Data Analysis Service Impact Analysis Fault & Cause Analysis Log Analysis Open Big Data Distribution & Persistence Service (Fault, Perf, Inventory) Performance Analysis Inventory Details Assurance Data collection & aggregation Events/Alarms Synthetic Tests Logs Metric Managed System Instrumentation Controllers Provision Managed System Virtual Services Physical Devices Virtual Devices DC Infrastructure (Compute, Network, Storage)

57 Service Assurance Definition Service Orchestration Instrumentation Service & Toplogy Models Remediation Optimization Key Pillars: Assurance & Orchestration Integration Enabling Closed Loop System 6 Tenant & Operator Dashboards 1 Common Presentation 2 5 Aid Remediation Aid Optimization 4 Aid Analysis 3 Monitor Orchestration Provision Assurance Analysis Data Collection Instrumentation Service Assurance 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

58 Summary 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 Service Intention Service Instantiation Infrastructure Assurance

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

60 Case Study New Service Security-as-a-Service Business Drivers: Value-added security services to enterprise customers More agile and dynamic service provisioning Use Case: Managed services for enterprise customers Dynamic L3-L7 service chaining using service-oriented network API Self Service Portal SW SW SW SW HW HW HW HW OpenFlow Cisco NSO Datacenters (dozens) Branches (thousands)

61 Case Study

62 Case Study US Service Provider VPN provisioning Business Drivers: Speed, innovative services, OPEX Fast delivery of various types (e.g., L3 MPLS) of end-to-end VPNs Use Case: 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

63 Case Study Network Automation Business Drivers: Use Case: Perl Scripts Scaling operations Network Engineers Config file backup Networking Applications Unified Network API Network Engineer Cisco NSO Multi-Vendor Devices Multi-Vendor Devices

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

66 Complete Your Online Session Evaluation 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. Don t forget: Cisco Live sessions will be available for viewing on-demand after the event at CiscoLive.com/Online

67

68 References