1. Software and Networking
We live in a connected world and the foundation for these connections is the network.
Broadband Internet traffic is doubling each and every year (according to IDC) [or] Internet traffic worldwide will grow three-fold by the year (Internet Trends, Mary Meeker (KCPB)
Today we have 2.5 billion Internet users in the world – roughly one-third of the Earth’s population. In the next decade, the number of Internet users will double to 5 billion (Mary Meeker, KPCB)
That means that two-thirds of the world will be connected by 2023.
When you add in the big trends of cloud, mobility, video and security, the combined rate of acceleration is placing unprecedented demands on the network.
[Optional stats/factoids]
100 hours of video uploaded every single minute to YouTube (YouTube)
Mobile video traffic exceeded 50 percent for the first time in (Cisco VNI)
Mobile network connection speeds more than doubled in (Cisco VNI)
In 2012, a fourth-generation (4G) connection generated 19 times more traffic on average than a non-4G connection. Although 4G connections represent only 0.9 percent of mobile connections today, they already account for 14 percent of mobile data traffic. (Cisco VNI)
[NOTE: Consider finding alternate source for above stats to avoid siting Cisco]
As you just described (refer to pain points from previous slide), you are living in this world and feeling the pressure every day.
Pradeep Sindhu founded Juniper 17 years ago on the belief that we should solve technology problems that matter most to our customers and that make a difference in the world. He recognized the importance of the network and the impact it would have on our world.
Our mission is simple, but powerful; to connect everything and empower everyone.
In today’s connected world, this mission is more relevant than ever.
Here at Juniper we are focused on helping alleviate those pain points through our portfolio of high performance networking products.
[T] And we do this by listening to our customers and helping them address their challenges and capitalize on their opportunities.
Software and Networking
<Audience Name>
<Your Name Here> <How to follow you on social media>

2. USE THE BEST HARDWARE AND SOFTWARE
This slide should be our product in review. When presenting double-click on the hard to define “SDN Ready”, and give it a marketing spin. Follow up with Juniper has been automated since the Junos Operating System’s inception. Did you know that Junos was developed without a CLI? Isn’t it hard to believe that (in my opinion) the best CLI in the computer networking industry was an afterthought. In fact, the Junos CLI was about 200 lines of code written after the fact from a customer enhancement request. Junos was meant to be automated from the XML-RPC which we will cover at a high level later.
Consistent Hardware Architecture
Consistent Software
SDN Ready

3. Security Router/Gateway
Key Juniper Solutions
SRX
Security Router/Gateway
Talk about key product platforms and how we have a consistent user interface. Discuss what this means in context to a human learning our platform. This is also a great place to talk about the perceived learning curve of Junos and how this is typically an overestimated. Once you “get it” you “get it” on all devices.
EX & QFX
Switching/DC Fabric
MX & ACX
Universal Routers

4. Integration More than Networking Juniper Heritage Application Delivery
Zero Downtime
Mission Critical Services
Security
Juniper Heritage
Started in the Service Provider Space
Junos was always meant to be automated
Complete Cross Portfolio Solutions
Talk about how it is about more than about networking (as much as I would like it to be just about networking). Draw a parallel to how Juniper comes from a Service Provider heritage solving the difficult problem of service delivery. The reason Juniper is important and unique in the enterprise space today is because your users, your customers expect the same level of service provided by the service provider. Remember, you are delivering an application something that defines your business, and you have to do it efficiently. Service providers have been automating for years to keep up with the explosive demand for bandwidth and uptime.

5. “Any sufficiently advanced technology is indistinguishable from magic” – Arthur C. Clark
Automation should just happen. When you push a button and everything happens like it should and you have spent no to very little time accomplishing what used to take you hours or days, that is when it’s magic and becomes worthwhile.

6. Sometimes it’s too Easy
This is a quote from one of our PLMs discussing the downsides of creating “magic” and making things look really easy. This demonstrates that we have the technology today, and we have the ability to automate our networks but…
‘The downside of “Easy Button” is that it usually doesn’t get considered “Automation” because you don’t have to do anything… go figure!’ – Anonymous Juniper Engineer

7. Talk about the evolution of the cellphone and how it has gone from a device that we make phone calls on to something we use for a multitude of tasks. Think about how this has made life simpler. From managing your day, to tracking your fitness to letting you order coffee in one click.
Does anyone here join conference calls? How many have tried to dial these from the road, in particular when you are driving. Come on, raise your hands it’s OK. First you have to dial the 8xx number, then you have to enter the 300-character bridge identifier, then if you are lucky you get to enter a PIN. Not fun driving. Applications like MobileDay have solved this problem for us by just letting us dial that bridge with the click of a button. This is old hat to everyone now, but this is automation.

8. What does SDN mean to you?
But the idea of software and network, “SDN” if you will is confusing. Breaking down our business processes that have been built for the last 20 years and breaking them into workflows and tasks is a complex undertaking. This is why everyone has a bit of a different perspective into what “SDN” means to them.

9. Gartner
SDN
a new approach to designing, building and operating networks that focuses on delivering business agility while lowering capital and operational costs. It is far more than just a new set of APIs designed to replace command line interfaces for managing individual devices.
a shift from (per box) element-based control to network-based control.
Optional slide. I keep away from the cost savings here and double-click on the “element-based” to “network-based” control. You can reference the DOS 5.0 CLI which everyone used and was familiar with back in the late 90’s but we have evolved to being more productive through the use of automation, programming and applications.
Source: Gartner, Ending the Confusion About Software-Defined Networking: A Taxonomy. .

10. So why Automate networks anyway
So why Automate networks anyway? Aside from the fact that we, networking, should be, need to be keeping up with our server counterparts, the pivot is hard? Why would I automate?

11. Juniper Partner Juniper Partner 2500 Switch Deployment
This is an example of where a partner asked Disti to upgrade their 2500 switches to a certain version of JUNOS the customer wants to standardize on. Disti to do this process wants $15 per box. Easy math, easy savings.
Juniper Partner
2500 Switch Deployment
Standardized on Junos Version
$15 Per box to Upgrade
Juniper ZTP
Potential Savings > $30,000

12. Retail Deployment 7000 National Locations 3 Network Techs
PCI Environment
Deployed by Store Managers

13. Restaurant Chain 2500 Global Locations 3 Devices Per Store
This is an example of where an restaurant change increase their ability to roll out new stores from 3 per night to 50 creating efficiency for their business. They could have hired 50 more people, but automation had a significant cost bennifit.
2500 Global Locations
3 Devices Per Store
Manual rollout = 3 Per night
Automated Roll out = 50 + Per Night

14. Juniper Automation Heritage
Consistent feature development
One Junos
Network OS
Junos SDK Control Plane
Junos Space
Junos V
App Engine
Chef
Discuss how automation is something that is in our DNA. Do not hit each milestone on this slide. Highlight Junos, one operating system. Netconf, which is the IETF standard based on JUNOSScript. Highlight how as the industry begins to adapt network automation the slide to the right gets more dense, but remind the audience that we didn’t get into automation because the industry decided to start using software and networking in the same sentences, but we have been doing this since day one. Let’s double click.
From early on we have developed strong automation features in the very heart of our platforms, e.g.
1996
2005
2007
2008
2010
2011
2012
2013
2014
2015
2006
Puppet
XML-RPC / Netconf / DMI
Junos Scripting with Op, Event and Commit Scripts
NETCONF
JunosEZ Framework
Space with Network Director and Security Director for network level abstractions
Integration with Configuration and Cloud Management Platforms, to enable end-to- end automation
Junos Script Automation
Junos SDK Service Plane
SDN Protocols Support
Ansible
JunosEZ Framework for off box and on box scripting and integration into existing customer solutions
… our heritage in forward thinking decisions has allowed us to innovate and automate across our entire portfolio

15. Range of Automation Tools and Building Blocks
USER SOLUTIONS
We, Juniper have a vast range of Automation tools (more than the rest of the industry), and building blocks that fit the needs of a range of users and administrators. From shrink wrapped “user solutions” such as Space (top of slide), and it’s many management applications to integration with existing “DevOps” tools (Puppet/Chef/Ansible/Salt). And for the really advanced, our XML-API and other low-level tools that allow for any interaction with the device that is possible with the CLI and even down to the chip level, allowing for full integration into your customers software stack.
NETWORK
OPERATORS
Using Tools to build solutions to solve Day to Day needs
TOOLS
Building tools on top of libraries and APIs to help Network Operators achieve their goals
LIBRARIES
TOOL MAKERS
API
VENDORS
Building compelling products, and programmable abstractions
Platform

16. The Path to SDN – Stages Build
ZTP
Ansible
OpenClos
Deployment is currently the most costly and easiest to operationalize
Discuss the Path to SDN and how the low hanging fruit is deployment as it is the most expensive of all the things we do today. Think of why they invented NFV. Next integration into the software stack by incorporating adds/moves/changes/monitor into your existing business practices. And then of course Orchestration or SDN.
Deploy
Maintain
Orchestrate
Orchestration
Contrail
OpenFlow
VMWare
OpenStack
Add/Moves
Chef
Puppet
Ansible
PythonEZ
Verify/Monitor
Service Now
J-Vision
SNMP/Events
Netconf / DMI
The Orchestrate Phase moves further into integrating into the software stack
Maintain addresses day to day operations and ensuring compliance and uptime

17. X $ X $ ROI Zero Touch Provisioning Simplify Deployments 1
DHCP request/offer – specify base configuration and software version 1
Technician must only unbox, connect to network, and power up device
Simplest place to start and best place to demonstrate ROI. This also demonstrates the process and how Juniper is different. Most, or some, vendors leave off at the yellow line. But with our automation stack we can go beyond the simple, we can add logic into the process allowing us to intelligently provision devices. Remember the Autoparts example?
Base Config
Junos 2
Retrieve base configuration file and software image
Upgrade software and apply base configuration
Server w/ DHCP & FTP 3a
Send SNMP Trap to Network Director, push templates, the end. X $ 3b 3b
Determine location in network via detected variables
Determine location in network via detected variables
Manually
Request location and device specific configuration
Request location and device specific configuration
Specific Config
Minus 4
Retrieve and apply location specific configuration X $
Automation 5
Self-register with Network Director/MGMT Platform
ROI
Junos Space
Network Director

18. What is ZTP? (It’s Not Magic)
The Preboot eXecution Environment (PXE) is a standardized client- server environment to boot clients from a network. Only a PXE capable Network Interface Card and small set of protocols such as DHCP and TFTP are required.
Again, this is not magic, this (ZTP) has been around for some time, but now we are able to apply it to networking to create more efficient processes.

19. 75% Consistency Matters Regular Audits for Consistent Passwords
Analyst and Academic research suggests That
70-80% of Networks are
Vulnerable Due to Configuration Errors.
Discuss the residual effect of automation, that you create consistency in your network. Less room for human error. This “75%” comes from a marketing survey for higher education in the Northeast. While, due to the transient nature of Higher Educations IT staff this may be a high number, this is true everywhere. Think about if I get “root” on one of your routers and tunnel back to my network.
Regular Audits for
Consistent Passwords
Non Blank SNMP Community strings
VLAN Consistency
Etc.
75%

20. The Junos Automation Stack
Tool built into Junos that enable automation
Let’s discuss the Junos automation stack, in brief. We wont spend a lot of time on this, and if you want more detail on this check with your account team.
Top to Bottom:
Separation of control and forwarding – Remember that whole SDN thing, Junos was built on this concept (Chassis, Data Plane, Junos).
XML-RPC – This is what everything interacts with. When you look at this stack these components all work, or can work together from Top to Bottom
Note the CLI sits on top of the XML-RPC which is that 200 lines of code that was written after the OS
Netconf – is how we can configure off box and multiple boxes and is the IETF standard that was build on Junosscript, not to be confused with Junos scripting.
Frameworks and Libraries have been build for modern (cool) programming languages like Ruby and Python, but we are pretty much working to language agnostic which is why you see Thrift there as well. For those of you not familiar with Apache Thrift this give a user the ability to program in the language of their choice and still be able to take full advantage of Junos Automation.
The top layer demonstrates all the tools that have been and are being built to automate networks via Junos Automation, this by no means covers all of them, in fact we would need a bigger slide.
Let’s discuss a couple of high level tools.
The Junos OS has had automation features consistently added over the past 15 years.
This heritage of feature innovation has allowed Juniper to deliver new features by building on top of the abstraction layer below.
Three (3) key features form the basis for almost all automation aspects at the platform layer
Data Plane (PFE)
Chassis
XML-RPC
NETCONF
Junoscript
SNMP RO
Junos Platform Automation Stack
Ansible
Python Scripts
Salt*
Puppet
Ruby Scripts
Chef
Python / SLAX
CLIRA*
JSNAP
THRIFT
REST
CLI
jVision Sensor
PyEZ Framework
RubyEZ Library
JET API
XML-RPC in the core of Junos and Netconf to provide network based access to the system
Junos Script for automating Operational, Configuration and Event based tasks
Junos EZ Framework implementing Python and Ruby based object models for interacting with Junos using modern programming languages

21. Scripting
Commit Script
Run every time a user commits the configuration, can help with automation and consistency
Let’s review where most people have stated with Junos Automation and talk about On Box Automation. On Box automation has been around since almost the beginning. There are three types of on box scripts. Commit Scripts, Operations or OPs scripts, and Event Scripts. The most simple example is a commit script. You are aware of the Junos Commit model. When you type commit for a candidate configuration there is error checking and syntactical checking that occurs in the background to ensure, from a Junos perspective, that your configuration will run on the box. With commit scripts you can install business logic, such as enforcing a policy that requires and interface description, on the platform as well. The value to the customer is, “what if I could prevent you from making the same configuration mistake twice”.
Next you have Operational Scripts. These are designed to allow you to combine commands in sort of a macro format that allows you to ease the configuration or troubleshooting of a Junos device. These can also help in monitoring.
Lastly, you have Event scripts. These are scripts that are triggered by any event that can be recorded by the Junos device. These can react to events by gathering logs or they can perform an action that perhaps a routing protocol would not normally perform by evoking Ops and Commit scripts. All these scripts can work together. This in fact, at a base level, is how Service Now functions.
The scripting language we employ for this is SLAX or Stylesheet Language Alternative Syntax which is a language for writing Junos OS commit scripts, op scripts, and event scripts. It is an alternative to Extensible Stylesheet Language Transformations (XSLT). SLAX has a distinct syntax similar to that of C and Perl, but the same semantics as XSLT. As discussed earlier, Python On Box Scripting will be available in the near future. There current benefit to SLAX is that There are a lot of SLAX scripts out in the open source. We anticipate that this library will only continue to grow as we introduce Python Scripting.
Op Script
Initiated by an operator, help in troubleshooting, configuration, monitoring
Event Script
Initiated by an event policy and allow automation and troubleshooting

22. So, Why is it called “PyEz”?
Frameworks and libraries. Why PyEz? What’s Ez about it?
Here is a quick example of why we call it PyEz. Say you want to gather some information off of a device. This is commonly known as “get facts”. Get facts is where you, very much as a human would do, learn things about a device. Think about when you get a device, what do you do? Remove it from the box, figure out what it is, how many ports it has, what OS is on it, etc.
To do this in raw Python this would take 48 lines.

23. So, Why is it called “PyEz”?
With ncclient it is much shorter an you really only need to define the basic info (host, user, password), create the connection using that info and then send the ‘show version’ command. This is somewhat of a poor example because it isn’t using the rpc, but rather cli commands. Not a good idea in a programmatic sense. Either way, once you retrieve the command, you can then print it out. This is also a bad example because the script never closes the connection either, which is certainly best practices. Either way you get the point, we are down to 18 lines.
Raw Python – 48 lines

24. So, Why is it called “PyEz”?
Raw Python – 48 lines
ncclient – 19 lines

25. So, Why is it called “PyEz”?
With PyEZ this takes 7 lines well, 5 really. You define the device you want to talk to, open the connection and it automatically gets not only the show version info (via rpc) but also hardware and serial number information as well. Also PyEz formats the output into JSON from the XML it receives. All in 5 lines. It does a LOT more also with operational and configuration data. This is just an example of how PyEz makes it simpler to get started with scripting. It’s not just a device connection utility, it also has configuration, operational, command, OS upgrade utilities, and more are being developed in Juniper as well as in the Open Source, as PyEz lives on GitHub.
PyEZ – 7 lines (and gathers more info)
Raw Python – 48 lines
ncclient – 19 lines
All 3 scripts gather ‘show version’ info from the same device

26. Puppet
With the support from modern programing languages like Python and Ruby, DevOps tools have begun to integrate with Junos. Puppet for instance.
Puppet is server/client model, in which the Puppet Master is the central control point, responsible for all the clients configuration deployment and modification. There are Junos Clients that work with the traditional model that support various Juniper switching platforms. Junos switches are equipped with a NETCONF API that enables programmatic configuration changes and operational management via a secure XML RPC. To be able to support Junos switch on the server side, We have created the "netdev“ module stored on the Puppet master. The switch running the Puppet agent downloads this code via SSL.
One additional point on the “netconf” API… Even though the current Juniper Puppet solution only covers basic vlan, lag, trunk, Layer2 functions, the “netconf” based solution technically is able to support all features/functions delivered by the normal CLI.

27. Ansible
Another example is Ansible, and what was used in our restaurant example. Ansible is a radically simple IT automation platform that makes deploying Junos devices pretty simple. You can avoid writing scripts or custom code to deploy and update the devices and you can automate in a language that approaches plain English (YAML), with no agents to install on the devices. This is a distinct difference from Chef and Puppet where you are limited to the functions available.
Juniper has supported modules for push types of scenarios only. Ansible isn’t very good for pulling data and manipulating it.
With the Juniper supported modules you can:
Upgrade Junos
Push configuration changes (either as curly brace, XML or set commands)
Get facts about the device (model, OS version, serial numbers, etc.)
And remotely shutdown the device.

28. The Junos Automation Stack
The Junos Automation Stack is extremely powerful and is packed with features that allow for practically everything on a Junos device to be automated.
But remember, as you get further away from the direct OS interaction, there are abstractions that happen that could remove some flexibility of command choice and/or OS manipulation. For most, IT frameworks and basic scripts will be enough to push configuration and get basic status. But when more and more information is needed from the network, you must delve deeper into the stack and use things like JET apps and YANG models to truly unleash the power of an automated Junos platform and make the idea of an “SDN” become a reality.
Data Plane (PFE)
Chassis
XML-RPC
NETCONF
Junoscript
SNMP RO
Junos Platform Automation Stack
Ansible
Python Scripts
Salt*
Puppet
Ruby Scripts
Chef
Python / SLAX
CLIRA*
JSNAP
THRIFT
REST
CLI
jVision Sensor
PyEZ Framework
RubyEZ Library
JET API
Simplicity
Flexibility

29. Automation – The Hard Part
Not a technical problem, it is cultural
Automation is business driven
Intellectually difficult
An engineer’s value is not how much they type at the keyboard
Networks are already highly automated, if you think about it
Nothing good is easy, nothing easy is good
The problem of Network Automation is not a technical problem, it’s a cultural problem.
For instance Networks are already automated – Dynamic routing is a good example. If you were to ask someone to implement a semi-large network using static routes only, they would look at you like you are crazy. “What would we do when a link goes down?” Indeed. We already allow dynamic routing protocols make changes, to the local device based on local information, based on a fault. Performance issues are a type of fault (though not catastrophic at the time) and faults in other parts of the network should be able to affect other devices in a positive way. FECN, bECN and 802.1au are all examples of trying to implement a protocol that does this based on local device information and trying to share it with others.
DDoS attacks already have automated identification and traffic re-route (to a black hole or impersonation site) implemented a no one sees that as out of the ordinary. What if we could prevent performance/congestion/efficiency/utilization issues before they happened?
In reference to Technical vs. Cultural – We have a lot of different technologies that can solve a lot of consistency and real-time performance problems already (python, IT frameworks – chef, puppet, etc., SNMP fault management, etc.). The problem lies in the fact that automation is something of an abstract concept to most people. They believe it is similar to manufacturing processes (and ultimately the loss of jobs) and that eventually automation will take over and there will be nothing for humans to do. This is a very narrow view and assumes that either A) the engineer is so focused on a few things that they can actually be replaced or B) there is no dynamic aspect to a network and things are done the same way every time they are changed. Anyone who has ever worked on a network of more than 2 end systems knows for a fact that B, in the previous statement, is all out false.
Remember all this is Business driven - Automation should be looked at as part of a higher level business process model, adding value to your products (in our case) or making your business more agile and efficient (in the case of the customer).
And some times it an Intellectual challenge - Getting your head wrapped around a single IT process takes some effort.  Getting your head wrapped around dozens — or hundreds — of processes can be mind-melting.  Understanding those processes at a deep enough level that common patterns and architectures emerge as a basis for re-engineering -- well, that takes serious intellectual horsepower.
Nothing good is easy and nothing easy is good. If you don’t spend the time to develop the process, the process will likely not be perfect. Case in point if you automate an inefficient or broken process, Automation will help you fail faster and highlight your inefficiencies.

30. RIPPED FROM A NET.ENG BLOG
Why is it taking so long for the network to adapt automation.
Kurt Bales, Senior Network Engineer

31. Zero Touch Provisioning
Juniper Partner
Simple Tools. In the case of our partner we just used ZTP, which consists of a DHCP server and some type of file server, TFTP for example.
Zero Touch Provisioning
Juniper Partner
2500 Switch Deployment
Standardized on Junos Version
$15 Per box to Upgrade
Juniper ZTP
Potential Savings > $30,000

32. Zero Touch Provisioning
Restaurant Chain
Ansible
NetConf
In our restaurant change example we used ZTP, Python (remember Ansible modules can be written in Python), Netconf so we could talk to the box and Ansible for creating and deploying templates.
Python/PyEz
Zero Touch Provisioning
2500 Global Locations
3 Devices Per Store
Manual rollout 3 Per night
Automated Roll out 50 + Per Night

33. Retail Deployment 7000 Locations 3 Network Techs PCI Environment
Juise/Advanced ZTP Server
cURL
In the retail environment we used ZTP, on box scripting, or SLAX. An Event script (SLAX) that made a remote call using cURL (or a web call) to a server that would build and ultimately push a configuration.
SLAX Scripts
Zero Touch Provisioning
7000 Locations
3 Network Techs
PCI Environment
Deployed by Store Managers

34. Physical Network (no changes)
SDN Point of View
Discuss how this leads to SDN (Network automation is at the bottom half).
Accepts and converts orchestrator requests for VM creation, translates requests, and assigns network
Collector
OPENCONTRAIL CONTROLLER
Control
Configuration
Real-time analytics engine collects, stores and analyzes network elements
Interacts with network elements for VM network provisioning and ensures uptime
Physical Host
with Hypervisor
vRouter VM
Physical Host
with Hypervisor
vRouter VM
Physical Network (no changes)
vRouter: Virtualized routing element handles localized control plane and forwarding plane work on the compute node
WAN, Internet
Gateway
Gateway: MX Series (or other router) or EX9200 serve as gateway eliminating need for SW gateway & improving scale & performance

35. Thank You!