1. John Malzahn – Host, Senior Manager, Cloud and Virtualization Solutions Marketing, Cisco Systems
Boštjan Šuštar, Senior IT Architect, NIL
Carl Moberg – Technical Director, Cisco Systems
May 3, 2017
Orchestration & Automation: Is Your
Network Ready for 10 Billion
Connections?
2. Today’s Presenters
John Malzahn
Senior Manager, Cloud
and Virtualization
Solutions Marketing,
Cisco Systems
Boštjan Šuštar
Senior IT Architect
NIL, Ltd
Carl Moberg
Technology Director,
Cloud and
Virtualization Group,
Cisco Systems
3. Agenda
Orchestration and Scaling
Challenges Facing Service
Providers
1
Cisco’s NSO Solution and
Value Proposition
2
NSO’s Layered Services
Architecture Innovation and
Demo
3
4. Cisco NSO – Our Industry
Leading Automation &
Orchestration Platform
5. Key Market Trend Observations
Execution at the speed
of software
• Agility, DevOps, NFV, SDN,
new services platforms
Rapidly changing
business models
• Cloud services, virtualization,
programmable networks
• New ecosystems and
value chains
• OTT Co-opetition
Changing customer
behavior and new
expectations
• Everything on demand
• New services with a press
of a button
All of this requires successful, flexible automation.
But complexity has destroyed many automation initiatives.
6. Barriers to Successful Automation
High fallout ratios and broken configurations result in
higher costs and slower service activation.
Growing Complexity
• Proliferating devices
and service types
• Heterogeneous environments
• Legacy IT and automation
can’t keep up
Current Automation
Complex, Rigid, Fragile
• Hard-coded logic flows
and CLI templates
• Fragile, programmatic adapters
• One-off solutions—not
repeatable or reusable
Data quality issues
No transactional control
Complex rollbacks and
remediation
Lack of Visibility and
Granular Control
Requirement for even more
complex and dynamic services
New technologies,
elasticity, virtualization
Future Challenges
7. What If You Could…
Break the complexity barrier to enable agility?
• Full lifecycle automation (create, update, delete)
• Model-driven to reduce code and expand features
Support real-world multivendor environments?
• Any use case on any device
• Hybrid and Brownfield environments
• Full stack—beyond Layer 2 and Layer 3
Reconfigure services with high quality and minimal impact?
• Non-disruptive updates of service and device models
• Surgical precision and atomic transaction control
Decouple services from infrastructure?
• Physical and virtual networks and service platforms
• Minimal dependencies on networking technologies
• Minimal dependencies on OSS environments
8. Infrastructure
Cisco Orchestration Architecture
High Level View
• Model-driven end-to-end service
lifecycle and customer experience
in focus
• Seamless integration with existing
and future OSS/BSS environment
• Loosely-coupled and modular
architecture leveraging open APIs
and standard protocols
• Orchestration across multi-domain
and multi-layer for centralized
policy and services across entire
network
RFS
DC & NFV Controller
Multi-layer
WAN SDN
CFS
Order Managers
OSS
Metro and Access WAN Data Center
CPE
Configuration-based
Provisioning
Network Service Orchestrator (NSO)
9. NSO Main Feature
#1 Model-based Architecture
Network Equipment Drivers (NEDs)
Service Manager
Device Manager
Service
Model
Device
Model
Software
REST, NETCONF, Java, Python, Erlang, CLI, Web UI
NETCONF, REST, SNMP, CLI, etc
Engineers
• No hard-coded assumptions
about:
• Network services
• Network architecture
• Network devices
• Instead:
• Data models written in
YANG (RFC 6020)
Metro and Access WAN Data Center
CPE
10. NSO Main Feature
#1 Model-based Architecture (continued)
Network Equipment Drivers (NEDs)
Service Manager
Device Manager
Service
Model
Device
Model
Software
REST, NETCONF, Java, Python, Erlang, CLI, Web UI
NETCONF, REST, SNMP, CLI, etc
Engineers
• No hard-coded assumptions
about:
• Network services
• Network architecture
• Network devices
• Instead:
• Data models written in
YANG (RFC 6020)
Metro and Access WAN Data Center
CPE
Customer owns lifecycle of
formal service definition
• Product management defines
the services
• Infrastructure team deploys
and manages
• Order Management team
consumes the services
11. NSO Main Features
#2 FastMap
Network Equipment Drivers (NEDs)
Service Manager
Device Manager
Service
Model
Device
Model
Create
Update
Delete
Redeploy
NETCONF, REST, SNMP, CLI, etc
• FastMap:
• Only the CREATE
operation needs to be
specified
• UPDATE, DELETE and
REDEPLOY automatic
• Benefits:
• Reduces service
implementation code by
two orders of magnitude
• Supports modifications
of services at runtime
Metro and Access WAN Data Center
CPE
12. Why Layered Service Architecture (LSA)?
First customers approaching 100k devices
under management
Lots of time spent in querying third party
systems, and waiting for network devices to
finish
Platforms need to provide significant
abstractions in complex environments
Each order of magnitude brings new
challenges
Networks are brownfield, and so are OSS
Software developers are lazy
13. Why Layered Service Architecture (LSA)?
First customers approaching 100k devices
under management
Lots of time spent in querying third party
systems, and waiting for network devices to
finish
Platforms need to provide significant
abstractions in complex environments
Each order of magnitude brings new
challenges
Networks are brownfield, and so are OSS
Software developers are lazy
14. Why Layered Service Architecture (LSA)?
First customers approaching 100k devices
under management
Lots of time spent in querying third party
systems, and waiting for network devices to
finish
Platforms need to provide significant
abstractions in complex environments
Each order of magnitude brings new
challenges
Networks are brownfield, and so are OSS
Software developers are lazy
15. What You Gain with Cisco Automation
• Agility throughout service lifecycle
• Full automation
• Robust and proven in tier-1 deployments
• Industry’s broadest multivendor support
• Most scalable service orchestration
• ETSI MANO compliant NFVO, VNFM
• Relevant in today’s and tomorrow’s networks
19. Optimize Code
Service Instance
Parameters
Config Mapping
Config Delivery
XPath: avoid large and convoluted absolute XPath
expressions if possible (e.g. use must statement)
Java/Python: avoid all-encompassing loops
XML XPath: careful with foreach and when attributes
AAA: command authorization on devices can slow down
transactions
20. Optimize Code: Example
must "count((/l3vpn:l3vpn[name!=current()/../../../name]/l3vpn:link[pe=current()/../../pe]/l3vpn:ios/l3vpn:GigabitEthernet=current())" +
" and (/l3vpn:l3vpn[name!=current()/../../../name]/l3vpn:link[pe=current()/../../pe]/l3vpn:pe=../../pe))=0";
for (NavuContainer device : managedDevices) {
if (device.list("capability").isEmpty()) {
String mess = "Device %1$s has no known capabilities, " +
"has sync-from been performed?";
String key = device.getKey().elementAt(0).toString();
throw new DpCallbackException(String.format(mess, key));
}
}
unique "device ios/GigabitEthernet";
XPath
Java
Scans the entire L3 VPN
service instance database
Loops through all devices
21. • NSO is a powerful framework:
• You can code anything with Java or Python … but
• You can do many things with XPath … but
• You can do most things with standard YANG statements
• Design and development guidelines:
• Use standard YANG statements as much as possible
• Only use XPath expressions when standard YANG statements are
insufficient
• Only use Java or Python code where YANG/XPath are insufficient
Service Implementation Guidelines
22. • Increase capacity: reached the hard limits
• Optimize code: ran out of options
• Change NSO behavior: nothing more to be done
Addressing Performance Limitations Using Vertical Scaling
Summary
There is only so much you can do!
23. Design for Scalability and Performance
20k devices
20k devices
Service
Model
Device
Model
Device
Model
Service
Model
VPNs
NFV
Device Node
20k devices
Device Node
20k devices
Static Device
Mapping
Service
Model
Device
Model
Device
Model
Device
Model
Service
Node
Service
Node
Device Node
20k devices
Device Node
20k devices
Dispatching
Top
Model
RFS
Model
Device
Model
Device
Model
RFS
Model
RFS
NED
NSO LSA
NSO Cluster
Per-App NSO
24. • Splitting the load based on
application
• May not be possible:
• For end-to-end services touching
multiple domains
• Different NSOs may touch the same
devices
• Individual applications may still reach
performance limits
Horizontal Scaling
Per Application NSO Instances
20k devices 20k devices
Service
Model
Device
Model
Device
Model
Service
Model
VPNs NFV
25. • Device mappings need to be
maintained
• Performance can be severely
impacted by cluster functionality:
• Every call to device data on service node
results in a NETCONF RPC
• Cluster caching should be enabled to
improve performance but it will increase
memory utilization
Horizontal Scaling
NSO Cluster
Device Node
20k devices
Device Node
20k devices
Static Device Mapping
Service
Model
Device
Model
Device
Model
Device
Model
Service
Node
26. • Top node only sees a small number
of devices (RFS nodes)
• Total number of devices has no
impact on performance of the top
node
Horizontal Scaling
NSO with Layered Service Architecture (LSA)
Top
Node
RFS Node
20k devices
RFS Node
20k devices
Dispatching
Top
Model
RFS
Model
Device
Model
Device
Model
RFS
Model
RFS
NED
27. • Use LSA for virtually limitless scalability
• Make your top-level service model agnostic to device, platform,
interface, and technology
• Devise the simplest dispatch method possible or at least one easy to
maintain
• Implement integration with external systems at the top layer
• Implement resource allocation at the appropriate layer
• Use LSA-ready design today even if you run just one node
LSA Design Guidelines
28. Demo: Deploy L3 VPN to Six Sites
Top NSO
RFSN-AMER RFSN-EMEA RFSN-APAC
PE Routers
CPE Routers
• Deploy an L3 VPN
service instance
across multiple RFS
nodes
• Monitor LSA
behavior
41365 devices 29165 devices 37580 devices
3 devices
29. Demo: Deploy L3 VPN to Six Sites
Top Service Configuration
Top NSO
RFSN-AMER RFSN-EMEA RFSN-APAC
PE Routers
CPE Routers
l3vpn ACME
link 1
pe PE-US-NY-BE-0085
!
link 2
pe PE-US-SF-QR-0068
!
link 3
pe PE-FR-PA-DA-0050
!
link 4
pe PE-SA-JH-YA-0033
!
link 5
pe PE-CN-BJ-DO-0077
!
link 6
pe PE-AU-SY-AS-0048
!
One transaction
30. Demo: Deploy L3 VPN to Six Sites
RFS Service Configurations
Top NSO
RFSN-AMER
RFSN-EMEA
RFSN-APAC
PE Routers
CPE Routers
l3vpn ACME
link 1
pe PE-US-NY-BE-0085
!
link 2
pe PE-US-SF-QR-0068
!
l3vpn ACME
link 3
pe PE-FR-PA-DA-0050
!
link 4
pe PE-SA-JH-YA-0033
!
l3vpn ACME
link 5
pe PE-CN-BJ-DO-0077
!
link 6
pe PE-AU-SY-AS-0048
!
Dispatching based on geographic ID
used in the device naming convention
31. Demo: Deploy L3 VPN to Six Sites
Device Configurations
Top NSO
RFSN-AMER RFSN-EMEA RFSN-APAC
PE Routers
CPE Routers
inte
rfa
ce Gig
abi
tEt
her
net
3/5
vrf fo
rwa
rdi
ng ACM
E
ip add
res
s 1
92.
168
.22
3.5 25
5.2
55.
255
.25
2
!
rout
er bgp 65
000
add
res
s-f
ami
ly ipv
4 v
rf ACM
E
ne
igh
bor 19
2.1
68.
223
.6 rem
ote
-as 65
001
!
inte
rfa
ce Gig
abi
tEt
her
net
3/5
vrf fo
rwa
rdi
ng ACM
E
ip add
res
s 1
92.
168
.22
3.5 25
5.2
55.
255
.25
2
!
rout
er bgp 65
000
add
res
s-f
ami
ly ipv
4 v
rf ACM
E
ne
igh
bor 19
2.1
68.
223
.6 rem
ote
-as 65
001
!
inte
rfa
ce Gig
abi
tEt
her
net
3/5
vrf fo
rwa
rdi
ng ACM
E
ip add
res
s 1
92.
168
.22
3.5 25
5.2
55.
255
.25
2
!
rout
er bgp 65
000
add
res
s-f
ami
ly ipv
4 v
rf ACM
E
ne
igh
bor 19
2.1
68.
223
.6 rem
ote
-as 65
001
!
inte
rfa
ce Gig
abi
tEt
her
net
3/5
vrf fo
rwa
rdi
ng ACM
E
ip add
res
s 1
92.
168
.22
3.5 25
5.2
55.
255
.25
2
!
rout
er bgp 65
000
add
res
s-f
ami
ly ipv
4 v
rf ACM
E
ne
igh
bor 19
2.1
68.
223
.6 rem
ote
-as 65
001
!
inte
rfa
ce Gig
abi
tEt
her
net
3/5
vrf fo
rwa
rdi
ng ACM
E
ip add
res
s 1
92.
168
.22
3.5 25
5.2
55.
255
.25
2
!
rout
er bgp 65
000
add
res
s-f
ami
ly ipv
4 v
rf ACM
E
ne
igh
bor 19
2.1
68.
223
.6 rem
ote
-as 65
001
!
inte
rfa
ce Gig
abi
tEt
her
net
3/5
vrf fo
rwa
rdi
ng ACM
E
ip add
res
s 1
92.
168
.22
3.5 25
5.2
55.
255
.25
2
!
rout
er bgp 65
000
add
res
s-f
ami
ly ipv
4 v
rf ACM
E
ne
igh
bor 19
2.1
68.
223
.6 rem
ote
-as 65
001
!
RFS NSOs process
transaction in parallel
35. Optimize Network Security Design
Cisco NSO
Router
1 transaction 50 commands
TACACS+ Server
1 x Authentication
50 x Authorization
Waiting until
finished
36. • Top layer node requires:
• RFS node reference
• RFS nodes require:
• Device references
• Physical interface references
• VLAN numbers
LSA Example: Adding a New L3 VPN Site
PE
CPE
Allocate VLAN on
trunk
Allocate physical
interface
37. cfsn
rfsn-amer rfsn-emea rfsn-apac
NETCONF
• Service models can be practically
identical
• Mapping can be based on:
• Static mapping of CPEs to RFS
node
• Dynamic mapping based on some
information that can indicate the
appropriate RFS node (e.g. “US” in
the PE name in the example)
• Resources provided by
northbound system (i.e. devices,
interfaces, VLANs)
LSA Example 1: Adding a New L3 VPN Site
l3vpn
site ACME-1234
cpe ACME-1234-SN332123
pe PE-US-NY-0218
intf GE2/5
…
l3vpn
site ACME-1234
cpe ACME-1234-SN332123
pe PE-US-NY-0218
intf GE2/5
…
Device Model
Not treated as
devices, only used
for the dispatching
logic
Actual devices
defined in CDB at
/devices/device
Upper node
RFS node
38. rfsn-amer rfsn-emea rfsn-apac
NETCONF
• Mapping can be based on:
• Static mapping of devices to RFS
nodes
• Dynamic mapping based on some
information that can indicate the
appropriate RFS node
• Resources allocated at RFS
node:
• VLAN assigned from a pool (i.e.
resource manager)
• Related PE devices and interfaces
defined at time of CPE creation in
CDB (e.g. after PnP)
LSA Example 2: Adding a New L3 VPN Site
l3vpn
site ACME-1234
cpe ACME-1234-SN332123
location US-NY
…
l3vpn
site ACME-1234
cpe ACME-1234-SN332123
location US-NY
…
Device Model
Upper node
RFS node
Upper Node
39. Configuring LSA: Top Node
Define RFS Nodes as NETCONF Devices
devices device rfsn-amer
address 10.1.100.101
port 2022
authgroup default
device-type netconf ned-id lsa-netconf
state admin-state unlocked
!
devices device rfsn-emea
address 10.2.100.101
port 2022
authgroup default
device-type netconf ned-id lsa-netconf
state admin-state unlocked
!
devices device rfsn-apac
address 10.3.100.101
port 2022
authgroup default
device-type netconf ned-id lsa-netconf
state admin-state unlocked
!
rfsn-amer rfsn-emea rfsn-apac
NETCONF
Upper Node
40. Configuring LSA: Top Node
Dispatch Method – YANG Model
list dispatch-map {
key region;
leaf region {
type string;
}
leaf rfs-node {
type leafref {
path "/ncs:devices/ncs:device/ncs:name";
}
}
}
rfsn-amer rfsn-emea rfsn-apac
NETCONF
Upper Node
41. Upper Node
rfsn-amer rfsn-emea rfsn-apac
NETCONF
Configuring LSA: Top Node
Dispatch Method – Dispatch Data
admin@cfsn# show running-config dispatch-map
dispatch-map AR rfsn-amer
dispatch-map BR rfsn-amer
dispatch-map CA rfsn-amer
dispatch-map FR rfsn-emea
dispatch-map GE rfsn-emea
...
dispatch-map UK rfsn-emea
dispatch-map US rfsn-amer
admin@cfsn#
l3vpn
site ACME-1234
cpe ACME-1234-SN332123
pe PE-US-NY-0218
…
rfsn-amer
One of many
possibilities – region
encoded in hostname
42. vars.add('REGION', root.dispatch_map[link.pe[3:5]].rfs_node)
rfsn-amer rfsn-emea rfsn-apac
NETCONF
Configuring LSA: Top
Node Dispatch Method Example – Mapping Template
<config-template xmlns="http://tail-f.com/ns/config/1.0" servicepoint="l3vpn">
<devices xmlns="http://tail-f.com/ns/ncs">
<device foreach="{link}">
<name>{$REGION}</name>
<config>
<l3vpn xmlns="http://com/example/l3vpn">
...
Python code is used to map
hostname to region.
l3vpn
site ACME-1234
cpe ACME-1234-SN332123
pe PE-US-NY-0218
…
Upper Node
43. Dispatch Options
Dispatch Method Comment
Device provided by
northbound system
Static mapping of each device Mapping needs to be maintained or a
mechanism devised to automatically
update the dispatch map
Device provided by
northbound system
Static mapping based on a subset of
hostname (e.g. encoded region)
Simple maintenance as long as the
naming convention is reliable
Location provided by
northbound system
Static mapping of locations to NSO
nodes
Advanced device selection required on
RFS nodes (e.g. based on CPE device
data derived from PnP or manually
entered)
… … Other methods can be devised based
on the environment and the availability
of useful information
Editor's Notes
Let’s set the stage by talking about the business challenges that operators tell us they’re facing today.
First, we’re seeing changing customer behavior and expectations.
More than ever, customers expect speed. They want to be able to capitalize on new opportunities and enter new markets much faster, responding to changes and competition in real time. All of that comes down to agility, and they’re counting on service providers to help give it to them.
When a customer has a need, they can’t wait weeks or months anymore for an operator to design and deploy a new service for them. They need everything on demand, and the ability to implement new network services with the press of a button.
Along these lines, operators are dealing with rapidly changing business models.
New technology innovations like virtualization, programmable networks, and cloud services are changing the way customers do business, as well as their expectations about how they interact with the companies providing services.
New ecosystems and value chains have evolved in the last few years, and if operators are going to support their customers, they need to be able to participate in them.
In this dynamic environment, you may be competing against some of these “over-the-top” (OTT) service and content providers one day while partnering with them the next.
So on the one hand, you need to develop some of the same kinds of capabilities that OTT providers can deliver. On the other hand, you need an infrastructure that’s open and flexible enough to integrate these capabilities into your customers’ evolving business models.
All of this supports a central requirement: the ability to execute at the speed of software.
A good example is the emerging DevOps model that many businesses are adopting, where developers and network operations teams work closely together across the service lifecycle to take ideas from conception to activation in a few weeks --- or even a few days.
That’s the kind of agility customers want, and they’re looking to a range of new technology innovations—network programmability, NFV, SDN, and others—to achieve it.
But as you know, programmability and NFV—not to mention new DevOps models—are very different from the way network service delivery has happened in the past.
It all comes down to automation.
Ideally, you should be able to use programmable networks and virtualized resources to deliver much faster, on-demand services.
But to do that, everything has to be automated—you can’t rely on lengthy, error-prone manual processes and custom OSS coding efforts to set up, change, and tear down network services.
Automation is not a new goal. But the incredible complexity of today’s environments presents a major roadblock to achieving it.
If you look through the stories of operators and enterprises that have tried to automate and not gotten the results they were hoping for, complexity is the biggest reason.
Let’s dig a little deeper into the specific barriers operators are facing when it comes to automating and orchestrating network services.
First is the growing complexity of the environment.
The number of services you’re offering is likely growing as you work to meet customer demands for different kinds of connectivity across different levels and segments of the network. As you add more devices to support more services, your environment becomes much more complex.
Service instances are also getting more complicated, as operators often need to chain multiple vendors’ network elements and activate them together.
There are many attempts in the industry to automate these processes. But in most cases, they’re too complex, rigid, and fragile.
In most orchestration solutions, the logic flows used to instantiate services are still typically hardcoded.
To automate device functions, they depend on hardcoded CLI (command line interface) templates and scripts, which are inflexible and require a lot of manual labor.
They typically require the use of fragile programmatic adapters that limit you to a subset of predefined operations for a physical or virtual device—which in turn limits the ways you can differentiate your network service offerings.
And they often require lengthy—and expensive—professional services engagements to automate a specific network service.
Even after you’ve automated something, you have rigid automation for that one thing—not a flexible, repeatable platform that you can easily update and expand as your needs change.
From an operational perspective, you usually don’t have the network visibility or granular control you need to broadly automate.
For example, the quality of the data the orchestration system is using may be suspect, because the latest network changes aren’t reflected.
When you’re launching an automated service, you don’t have transactional control or the ability to make sure that if every single part of the new or updated service doesn’t works, and the rollback process is often a problem in its own too.
The result is that you’re much more likely to push out changes that break things. Fixing those problems gets extremely messy.
Ultimately, you end up with broken configurations in platforms and networks.
That, in turn, leads to a high ratio of orders and activations that are not fulfilled.
So when everything works exactly as expected, you may be able to automate some services. But the moment anything happens outside the norm, or you need to change or update something, you need to manual coding to handle it. Which means higher costs and slower activations.
That’s just what’s happening today. If you look to the future, things get even more challenging.
We know that operators are moving quickly to embrace new technologies for elasticity and virtualization and new ways of working to be able to execute at the speed of software.
All of that will add even more complexity that legacy approaches to IT and automation can’t accommodate.
Clearly, a different approach is needed if operators are going to achieve the speed and agility they need. What would the key success factors for that be?
First, we need to break the complexity barrier.
You need to achieve full automation throughout the service lifecycle. That means automating everything—service creation, updates, and de-activation.
A successful solution will take a model-driven approach to automation. You should be able to easily ingest any standards-based service model and programmatically configure it as a service instance in your environment.
Because when you automate with standardized models instead of hardcoded CLI templates or scripts for every device, you can radically reduce the code required to build, implement, test, and manage automation logic and flows.
So you get much more flexible and repeatable automation, instead of expensive one-off projects.
A successful automation solution will let you reconfigure services without bringing everything to a halt.
You should be able to update services, device models, and networks on the fly, without disrupting all the other services running in the environment.
I like to think of the movie The Matrix, where you can upload a new ability in real time, and now all of a sudden you know Kung Fu. Your services environment should be the same way—press a button, and now you speak the language of a third-party vendor’s device or VNF, and can integrate it into your service flows, even while you’re in live production.
To do this, the solution needs to provide surgical precision and transaction control when you’re making changes in these environments, so they don’t break.
You’re also going to need to be able to do this across a multivendor landscape, because that’s what operators are using in the real world.
You should be able to model and automate any use case and any device.
You should be able to extend automation across new and legacy or brownfield environments. Because you can’t operate your services in silos, that’s only going to increase complexity.
And you should be able to automate multivendor devices and services across the full stack—not just Layer-2 and Layer-3 services. You shouldn’t be limited to automating just a few basic services, you should be able to configure everything—firewalls, WAN accelerators, every network service your customers want.
Finally, a successful solution will decouple services from the underlying infrastructure.
That’s critical to your ability to be fast and to make changes without breaking things.
That infrastructure-agnosticism should apply to both physical and virtual networks and platforms.
You should be able to build automated solutions that have minimal dependencies on the underlying network hardware and OSS environments, so they are clean and flexible.
Intro:
Market in flux, ETSI still not normative, many customers exploring options going forward
We have a significant number of engagements, realize that future is being defined in labs, not in standards or by vendors
Cisco understand that MANO stack is not off-the-shelf, but wants to avoid SI-heavy engagements
First row
Current situation in market is exploratory, some customers arriving at similar architectures, others still diverging
Vendors need to be flexible, but provide off-the shelf value, i.e. based on, but not locked into ETSI
Cisco NFVO provides a roust and developer-oriented software solution. Based on ETSI semantics and open interfaces technologies for rapid and incremental development cycles to fit purpose
Second row
Multi-vendor is as fundamental in virtual domain as it is in physical domain, adding greater potential impact from open source
Current main challenge is with onboarding and runtime environments as basic networking functions move off of hardware to VMs, containers later/aspirational
Vendor agnostic tooling and runtime technologies are key, so is patience with vendors, specifications
Balance effort to shoehorn unfit VNFs in MANO, and pushback on vendors
Third row
Basic computer science and the ETSI specification provides fundamental lifecycle componentes: onboard/import, create, update delete - goes across many concepts: descriptors, resources, etc
Declarative approach such as the one taken by ETSI allows for separation of model (descriptor schema), state (descriptor, resource) and logic (NFVO semantics) – system provides state and model, logic, end-user provides state for services, NFs
Summary:
Cisco provides an “API first” and bottom-up solution designed for developers/devops that want to leverage open technologies, emerging standards, adjusted to local needs
Rich abstractions that are comfortable to consume, and straightforward to integrate in surrounding systems
Intro:
Market in flux, ETSI still not normative, many customers exploring options going forward
We have a significant number of engagements, realize that future is being defined in labs, not in standards or by vendors
Cisco understand that MANO stack is not off-the-shelf, but wants to avoid SI-heavy engagements
First row
Current situation in market is exploratory, some customers arriving at similar architectures, others still diverging
Vendors need to be flexible, but provide off-the shelf value, i.e. based on, but not locked into ETSI
Cisco NFVO provides a roust and developer-oriented software solution. Based on ETSI semantics and open interfaces technologies for rapid and incremental development cycles to fit purpose
Second row
Multi-vendor is as fundamental in virtual domain as it is in physical domain, adding greater potential impact from open source
Current main challenge is with onboarding and runtime environments as basic networking functions move off of hardware to VMs, containers later/aspirational
Vendor agnostic tooling and runtime technologies are key, so is patience with vendors, specifications
Balance effort to shoehorn unfit VNFs in MANO, and pushback on vendors
Third row
Basic computer science and the ETSI specification provides fundamental lifecycle componentes: onboard/import, create, update delete - goes across many concepts: descriptors, resources, etc
Declarative approach such as the one taken by ETSI allows for separation of model (descriptor schema), state (descriptor, resource) and logic (NFVO semantics) – system provides state and model, logic, end-user provides state for services, NFs
Summary:
Cisco provides an “API first” and bottom-up solution designed for developers/devops that want to leverage open technologies, emerging standards, adjusted to local needs
Rich abstractions that are comfortable to consume, and straightforward to integrate in surrounding systems
Intro:
Market in flux, ETSI still not normative, many customers exploring options going forward
We have a significant number of engagements, realize that future is being defined in labs, not in standards or by vendors
Cisco understand that MANO stack is not off-the-shelf, but wants to avoid SI-heavy engagements
First row
Current situation in market is exploratory, some customers arriving at similar architectures, others still diverging
Vendors need to be flexible, but provide off-the shelf value, i.e. based on, but not locked into ETSI
Cisco NFVO provides a roust and developer-oriented software solution. Based on ETSI semantics and open interfaces technologies for rapid and incremental development cycles to fit purpose
Second row
Multi-vendor is as fundamental in virtual domain as it is in physical domain, adding greater potential impact from open source
Current main challenge is with onboarding and runtime environments as basic networking functions move off of hardware to VMs, containers later/aspirational
Vendor agnostic tooling and runtime technologies are key, so is patience with vendors, specifications
Balance effort to shoehorn unfit VNFs in MANO, and pushback on vendors
Third row
Basic computer science and the ETSI specification provides fundamental lifecycle componentes: onboard/import, create, update delete - goes across many concepts: descriptors, resources, etc
Declarative approach such as the one taken by ETSI allows for separation of model (descriptor schema), state (descriptor, resource) and logic (NFVO semantics) – system provides state and model, logic, end-user provides state for services, NFs
Summary:
Cisco provides an “API first” and bottom-up solution designed for developers/devops that want to leverage open technologies, emerging standards, adjusted to local needs
Rich abstractions that are comfortable to consume, and straightforward to integrate in surrounding systems
Let’s review what you gain with Cisco NSO enabled by Tail-f.
First, I hope I’ve demonstrated the kind of agility you can achieve with this solution. That agility extends across the service lifecycle—not just when you implement a service, but when you refine it over its lifetime as well.
We do this through our model-driven approach, with strict YANG-YANG service-to-device mapping, which allows you to model and automate just about any device or service you can imagine.
This is something you’re not going to get with other orchestration solutions, which are based on much less flexible CLI templates that limit what you can model and create a lot of complexity.
Our patented FASTMAP technology enables NSO to render business logic for all of the devices and services in your environment automatically. Which translates to greatly increased speed, and 90% less code that you have to manage.
And our minimum diff engine makes re-deploying and updating service and device models effortless, with no service interruption.
We can support new ways of working, and provide an ideal platform for DevOps environments.
From the perspective of your network operations teams, we give them access to all of the advanced features and functions in their multivendor network devices.
Unlike today, where it’s common to invest in a new physical or virtual device, only to find that you can’t implement all the features you want because your management and orchestration systems are hard-coded and inflexible.
And this has a direct effect on your ability to differentiate, because it means you can offer the most advanced capabilities, as well as create unique bundles with value-added services that your competitors relying on less advanced orchestration can’t support.
We’ve talked about how we can deliver true end-to-end automation, even in complex environments and for complex services.
This is what allows you to give your customers self-service network provisioning on demand.
And it’s what brings your cycle times down from weeks or months to days or minutes.
We discussed how NSO is a robust, proven solution that’s running today in large, Tier-1 operator environments around the world.
And I showed you how we provide the broadest multivendor support in industry, which is so crucial to your ability to automate network services in real-world networks.
Last but not least, NSO is equally relevant in today’s operator environments as well as tomorrow’s.
We can automate the programmable networks of today, and deliver significant improvements in speed, efficiency, and agility.
But we can bring the same benefits to the virtualized and elastic environments of the future as well.
This is so important, because the last thing you want to do is build a silo of new equipment and OSSs on top of an isolated legacy environment.
NSO can help you dramatically improve your agility with your legacy environment right now, and integrate newer NFV and SDN technologies whenever you choose.
YANG Guidelines for Performance:
Use specific constraint mechanisms (e.g. unique, mandatory) instead of must if possible
Use relative XPath instead of absolute XPath
Use deref() instead of absolute XPath with filters
…
Thank you for spending time with us today. We look forward to working with you in this fast growing market.
To learn more visit the Cisco and Microsoft sites below or contact your Microsoft and Cisco Account representatives
