Application Engineered Routing: Allowing Applications to Program the Network

Cisco Confidential© 2015 Cisco and/or its affiliates. All rights reserved. 1
Application Engineered
Routing: Allowing
Applications to Program the
Network
T-SP-32-I
Rob Piasecki
Solutions Architect, Services
May 19, 2016
rpiaseck@cisco.com

© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 2
Agenda
• AER: Industry Drivers & Overview
• AER: Architecture & Technical Concepts
 Segment Routing
 Intelligent SDN Controller
• Use Cases & Implementation
 Purpose Built Applications
 Demo
• Conclusion

Cisco Confidential 3© 2015 Cisco and/or its affiliates. All rights reserved.
AER: Industry Drivers &
Overview

The Problem
The Network is facing new challenges
EVOLVED PROGRAMMABLE NETWORK
IPv6
UHD
IoE
Cloud
Services
Mobility
Other
Dynamic and changing traffic patterns
Increasingly diverse applications with
application-specific transport requirements
End-to-End control required

IP NGN Era
Networks Need to be Rethought
Applications and Network interaction is key
Edge
Acce
ss/
Agg
IP
Core
Designed to support any kind of services
Automation (APIs, Controllers, …)
Designed to support a set of services
Static traffic patterns
Manual configuration (CLI)
EVOLVED PROGRAMMABLE NETWORK
IPv6
EVOLVED SERVICES PLATFORM
APPLICATIONS
Dynamic traffic patterns
App & Network InteractionApps Independent of Network

Specific Approaches to the Problem
A continuum of enhanced solutions
Policy-Based routing MPLS TE
 Scalable
 Stateless
 Programmable
 Ease of configuration &
troubleshooting
EPN EraIP NGN Era
Effective solutions with some caveats:
 Little or no application / network interaction
 Scalability
 Configuration & troubleshooting complexity
 States to be maintained in each network node
Evolution required
to address the
new paradigm
One device, single domain Many devices, single domain Many devices, across domains
DC CoreHosts Agg DC CoreHosts Agg DC CoreHosts Agg

Applications & Network Interaction
Implications for the Network Fabric
Limitations
 Limited to a single network
domain
 Scalability
 Configuration &
troubleshooting complexity
 States to be maintained in
each network nodeShortest path with QoS Traffic-engineered tunneling
 Impediment to service
creation
 Major scalability issues
 Operational challenges
Many applications with
dynamic and changing traffic patterns
IP Networks IP Networks & Traffic Engineering
IP Networks Evolution

Segment
Routing
(SW upgrade)
SDN
Controller
Applications
1
Applications express
requirements – bandwidth,
latency, interactive …
2
The controller collects data from the
network – topology, link states, link
utilization, …
3
Applications are mapped to a path defined
by a list of segments
Network maintains segments only
No application state
The Solution
Application Engineered Routing

IP/LDP
Evolve MPLS with Segment Routing
Seattle
New-York
Berlin
Mexico
Madrid
Toronto
London
TXL
1. A luggage tag is attached with the
final destination
2. Luggage identified and routed to the
next destination
No control over the path –
Luggage is routed over the shortest path
RESULT:
Mission – Route the luggage to Berlin
IP/LDP
Segment Routing
RSVP-TE

RSVP-TE
Seattle
New-York
Berlin
Mexico
Madrid
Toronto
London
20000
SEA MEX
20000
MEX MAD
20000
MAD TXL
1. At each stop, the luggage is
identified and routed to the next
hop
A list of all the paths has to be
maintained
2. A specific tag is assigned to each piece of
luggage,
i.e. Tunnel ID 20000, is created to identify the
path Seattle-Mexico-Madrid-Berlin
 Path can be controlled
 Complexity and scalability issues
RESULT:
via Mexico and Madrid
IP/LDP
Segment Routing
RSVP-TE

Segment Routing
Seattle
New-York
Berlin
Mexico
Madrid
Toronto
London
IP/LDP
Segment Routing
RSVP-TE
TXL
1. A unique and global luggage tag is
attached to the luggage with the list
of stops to the final destination
2. At each stop, the luggage is simply
routed to the next hop listed on the
luggage tag
 Path can be controlled
 Simple and scalable
RESULT:
via Mexico and Madrid
MEX
MAD
TXL
MAD
TXL

Segment Routing – Technical View
Path expressed in
the packet
Data
Dynamic path
Explicit path
Paths options
Dynamic
(STP computation)
Explicit
(expressed in the packet)
Control Plane
Routing protocols with
extensions
(IS-IS,OSPF, BGP)
SDN controller
Data Plane
MPLS
(segment labels)
IPv6
(+SR header)

Application Engineered Routing Journey
Adding value at your own pace
Enable Segment Routing on EPN Platforms (Software only)
Insert ESP components – Orchestration, SDN controller
Connect with Cisco’s and
third party VNFs
Network Simplification
Network Resiliency
End-User Experience
Network Optimization
Service Velocity
E2E Application Control
Benefits

Solution Components
EPN
ESP
Network
Applications
Segment Routing (SR) across Cisco platforms
ASR 9K ASR 1K
NEXUS
9000
WAE NSO VTS
3rd-party platforms
supporting SR
Bandwidth
calendaring
3rd-party applications
3rd-party
controller
Physical Virtual
Southbound
interfaces
Netconf/Yang BGP LS PCEP Configlets
Northbound
interfaces
RESTful APIs
Low-latency
path selection
Disjoint
recovery path
……NCS 6K …
VNF

Technology Innovation Driving Business Outcomes
Ease of
configuration
Ease of troubleshooting
Network resiliency
Automated 50ms
protection
Optimized CapEx
Reduced OpEx
Better End-User
experience
Programmability
Per application traffic
steering
Economic
Value
Increased Customer
Lifetime Value
SLAs Monetization
Higher link
utilization
Stateless
Scalability
Lower network resources
consumption

Why Cisco?
Comprehensive portfolio for delivering an end-to-end
Application Engineered Routing solution
Open solution to match diverse customer needs (IETF
standard, APIs)
Phased approach to Application Engineered Routing
solution (not a rip & replace solution)
1
2
3

Architecture & Technical
Concepts: Segment
Routing

Segment Routing
• Unified
• DC + WAN + Aggregation
• From server in the DC, through WAN and to the service edge
• Policy-aware
• DC: disjoint planes, flow-based congestion avoidance
• WAN: disjoint services, latency-sensitive traffic, scheduled bulk transfer
• Application programs the end-to-end policy
• The end-to-end policy is encoded by the application as an SR segment list in the packet header
• Balance between distributed and centralized intelligence
• Distributed: automated sub-30msec FRR link/node in any topology with optimum backup path
• Centralized: traffic optimization for better use of the installed capacity
• Applicable to MPLS and IPv6 data-planes
• Much simpler to operate than MPLS Classic

• Source Routing: the source chooses a path and encodes it in the packet
header as an ordered list of segments.
• Segment: an identifier for any type of instruction
• Service
• Context
• Locator
• IGP-based forwarding construct
• BGP-based forwarding construct
• Local value or Global Index
Segment Routing
Segment = Instructions such as
"go to node N using the shortest path"

• MPLS: an ordered list of segments is represented as a stack of labels
• SR re-uses MPLS data-plane without any change
• IPv6: an ordered list of segments is represented as a routing extension header, see
4.4 of RFC2460
• IGP-based segments require minor extension to the existing link-state routing
protocols (OSPF and IS-IS).
Segment Routing

• Simple extension to let IGP install segments in the MPLS dataplane
• Excellent Scale: a node installs N+A FIB entries
• N node segments and A adjacency segments
IGP Segments
A B C
M N O
Z
D
P
Node segment to C
Node segment to Z
Adj Segment
Node segment to C

Node Segment
• Z advertises a global node segment 16065 with its loopback
• Simple ISIS sub-TLV extension
• Default SRGB [16000, 23999] at all nodes is a request from all lead operators for operational
simplicity. The protocol and implementation allows for different SRGB at every node
• All remote nodes install in their FIB the node segment 16065 to Z
A B C
Z
D
16065
FEC Z
push 16065
swap 16065
to 16065
swap 16065
to 16065
pop 16065
A packet injected
anywhere with top
segment 16065 will
reach Z via
shortest-path
Packet to
Z
Packet to
Z
16065
Packet to
Z
16065
Packet to
Z
16065
Packet to
Z

Node Segment
• ECMP
• A node segment to 16078 distributes traffic across all ECMP paths to O
A B C
M N O
Z
D
P
16078

Adjacency Segment
• C allocates a local segment 29003 and maps it to the instruction “complete the
segment and forward along the interface CO”
• C advertises the adjacency segment in ISIS
• Simple sub-TLV extension
• C is the only node to install the adjacency segment in FIB
A B C
M N O
Z
D
P
Pop
29003
A packet injected at
node C with segment
29003 is forced
through datalink C-O

Explicit Path as Segment List
• ECMP
• Node segment
• Per-flow state only at head-end
• Not at mid-points
• Source Routing
• Path state is in the packet header
A B C
M N O
Z
D
P
16078
Packet to Z
16065
16078
Packet to Z
16065
Packet to Z
Packet to Z
16065
Packet to Z
16065
16078
16072
Packet to Z
16065
16078
16072
1607216072
16065
16065

• Guaranteed Link/Node FRR in any topology
• 50-msec protection
• Simplicity
• Entirely automated
• No directed LDP session
• No RSVP-TE tunnels
• Incremental deployment
• Applicable to LDP primary traffic
• Optimal backup path along post convergence path
• Prevents transient congestion and suboptimal routing
Automated 50-msec Protection for IGP Segments

SR-based MPLS Classic MPLS
Basic mpls transport IGP IGP + LDP
IGP/LDP synchronization N/A Problem to manage
50msec FRR IGP IGP + RSVP-TE
Extra TE states to support FRR No extra state Extra states to manage
Optimum backup path Yes (IP post-convergence) No (SDH-alike)
ECMP-capability for TE Yes No
TE state only at headend Yes No (n^2 problem at midpoint)
Seamless Interworking with classic MPLS and
incremental deployment
Yes N/A
Engineered for SDN Yes No

IP/MPLS architecture that seeks the right balance between distributed intelligence and centralized
optimization and programming.
• simplifies operation (lower opex)
• enables application-based service creation (new revenue)
• allows for better utilization of the installed infrastructure (lower capex)
An IP/MPLS architecture with wide application
• (SP, OTT/Web, GET) across (WAN, Metro/Agg, DC)
• MPLS and IPv6 dataplanes
• SDN controller
An architecture designed with SDN in mind
What is Segment Routing?

Architecture & Technical
Concepts: Intelligent SDN
Controller

WAN Limitations Impact Traffic Optimization
Service Providers
adopting new
approaches
Provider Constraints What’s Needed
Too Many
Manual Steps
Fragmented
View of the WAN
Lack of Visibility
for Troubleshooting
WAN Lacks
Real-Time Agility
Multivendor
Orchestration
Unified WAN
View for Scenario
Analysis
Network Visibility
Over Time: Past,
Present, and Future
Automation at Scale

WAN Automation Engine
Delivering Optimization and Automation
Modeling
What if/predictive analysis
Global optimization
Assess historical and
real-time data
Find and manage hot
spots
Network efficiency
analysis
Programmatic network
control
Extensible,
open data models
Real-time traffic balancing
Intelligent bandwidth
scheduling
Automated service
delivery
Predictive Model Time Series Visibility
Model-Based Control
and Configuration
Optimization and
Automation
+ + =
WAE
Cycle

SDN Strategy for SPs – High-Level View
Model driven, end-to-end service lifecycle and
customer experience focus
Seamless integration with existing and future
OSS/BSS environment
Loosely-coupled and modular architecture
using open APIs and standard protocols
Orchestration across multiple domains and
layers provides centralized policy and services
across the entire network
BSS
OSS (Fulfillment and Assurance)
Service-Intent API
SDN / APIs
Orchestration, Service, and Policy Implementation
Branch, CPE
Control
Multi-layer
WAN SDN
Data Center
and NFV
Control
EMS, NMS
Netconf,
YANG
CLI,
SNMP
BGP
Segment
Routing
PCEP Openflow
Openstack,
vCenter
Multi-Vendor End-to-End Management and Orchestration
(Physical and Virtual)
CPE Metro and Access WAN Data Centre
WAE

…
WAN Automation Software Suite
Collector DeployerNetwork Interface
Current Model New ModelNetwork Modeler
Service, Network, and
Analytics REST APIs
SNMP CLI NetFlow BGP-LS NMS/EMS NC/YANG OSC PCEP
Analytics CalendaringOptimization and Prediction
Segment
Routing
Optimizer
Bandwidth on
Demand
Bandwidth
Calendaring
Offline
Planning
IGP
Convergence
Analyzer
Failure
Analysis
InventoryWeather
Map
Coordinated
Maintenance
Application
Latency
Routing
Unified Application Framework

WAE Includes Cisco’s Version of ODL
Cisco® Open SDN Controller
Segment
Routing
Optimizer
Bandwidth on
Demand
Bandwidth
Calendaring
Offline
Planning
IGP
Convergence
Analyzer
Failure
Analysis
InventoryWeather
Map
Coordinated
Maintenance
Application
Latency
Routing
Unified Application Framework

WAN Automation Applications
Offline Planning, Design, and
Analysis
Online Visualization, Analytics, and
Business Intelligence
Managed Resource Inventory,
Security, and Maintenance
Optimized Bandwidth Placement Extensible Application Integration
Automated Tunnel Creation and
Traffic Load Management
Inventory Maintenance
Window
Scheduler
Network
ACL
Manager
Offline
Planning
IGP
Convergence
Analyzer
Failure
Analysis
Weather MapBGP Route
Visualizer
Business
Intelligence
Bandwidth
Calendaring
Bandwidth on
Demand
Tunnel
Splitter
Tunnel
Builder
Tunnel
Balancer
Application
Latency Routing
Segment Routing
Optimizer

WAE Strategic Initiatives
Segment Routing
NSO (Tail-F) WAE Integration Unified Multilayer
WAE Applications
Coordinated maintenance, bandwidth calendaring
Built for SDN | Foundation for application-engineered routing
applications that will have the ability to direct network behavior
Data Centre A
Traffic-aware intelligent programmability of multi-vendor networks
Global network view | Optimization across layers
Future: Add OTN to activation, planning, and optimization
Data Centre B

Use Cases &
Implementation: Purpose
Built Applications

• Guaranteed Link/Node FRR in any topology
• 50-msec protection
• Simplicity
• Entirely automated
• No directed LDP session
• No RSVP-TE tunnels
• Incremental deployment
• Applicable to LDP primary traffic
• Optimal backup path along postconvergence path
• Prevents transient congestion and suboptimal routing
TI-LFA: Automated 50-msec Protection for IGP Segments

WAE Design – TILFA Simulation
• How many segments in backup chain
• Capacity analysis during FRR transient state

IPv4 MPLS Transport with FRR
• IPv4 over MPLS: the obvious way it should have been done
• Just the IGP to operate
• Sub-50-msec FRR integrated and automated
• Seamless migration
• SR/LDP interworking
A B
M N
PE2PE1
All VPN services ride on the prefix segment to PE2
Any service resolving
on IGP IPv4 Prefix SID
 Internet
 VPNv4
 6PE
 PW

IPv6 MPLS Transport with FRR
• IPv6: the opportunity to do it right from the start
• Just the IGP to operate
• Sub-50-msec FRR integrated and automated
A B
M N
PE2PE1
Internet/v6 rides on the Prefix segment to PE2
Any service resolving
on IGP IPv6 Prefix SID
 Internet v6
 VPNv6

MPLS Data-Plane Monitoring
B C
N O
A
9101
9105
9107
9104
9101
9105
9107
9108
9104
9105
Nanog57, Feb 2013
9108 9105
9108
9102
9108
9102
draft-geib-spring-oam-usecase-02
OAM

Disjoint TE Service
• A to Z any plane
• IGP shortest-path
• Prefix SID of Z (65)
• A to Z via blue plane
• SRTE policy pushes one additional
segment “Blue Anycast” (111)
• Benefits
• ECMP
• No hop-by-hop signaling load and delay
• No midpoint state
16065
pkt
16065
pkt
16111

Latency TE Service
• Data from Tokyo to Brussels
• IGP shortest-path via US, higher and cheaper capacity
• Prefix SID of Brussels
• Voice from Tokyo to Brussels
• SRTE policy pushes one additional segment “Russia Anycast”
• Low-latency path
• Benefits
• ECMP
• Availability of the anycast segment against node failure
• No hop-by-hop signaling load and delay
• No mid-point state
Node segment to Brussels
Node segment to Russia
Brussels
pkt
Data
Brussels
pkt
Russia
Voice

AS1
AS2
AS3
Content Producer Engineers its WAN Traffic to Egress Peers
AS4
B
C
D
E
Payload
9.9.9.9/32
Payload
PeeringSID(E)
PrefixSID (C)
Engineered Path
TE Policy
installed by
Controller
Payload
PrefixSID(B) Payload
Best BGP
and IGP
Path
Payload
PeeringSID(E)
Engineered Path
ISIS/SR-based WAN
A

SR-Based MSDC
• MPLS data-plane
• BGP control-plane
• No LDP, No RSVP-TE
• Integrated/Automated FRR
• No hop-by-hop manual configuration of static routes and their FRR behaviors
• Global label for easier operation
• Same SRGB at each switch
• SR-TE WAN Optimization Controller applicable to DC fabric

AS1
AS2
AS3
Distributed DC for Content Engineering to Local Peers
AS4
B
C
D
E
Payload
9.9.9.9/32
Payload
PeeringSID(E)
PrefixSID (C)
Engineered Path
TE Policy
installed by
Controller
Payload
PrefixSID(B) Payload
Best BGP
Path
Payload
PeeringSID(E)
Engineered Path
BGP/SR-based DC Fabric

End-to-End Policy from DC, through WAN to Peer
vPEF
App
App
ToR Leaf Spine DCE BRLSR
BR
BR
Classify
flow and
push SR
segment
list
SR DC SR WAN
Top Segment
provides ECMP-
path to selected
DCI
Next segments
implement
WAN Policy:
Cost vs Latency
Disjointness
Select egress BR
Last segment
selects egress
peer

ToR Leaf Spine DCE BRLSR
BR
BR
SR DC SR WAN
Illustrated end-to-end policy implemented by the
application:
• Two service hops in the DC
• Low-latency path in the WAN
• Engineered peering exit to Internet consumer

ToR BRLSR
BR
BR
Classify
flow and
encode ACI
policy
ACI DC SR WAN
ACI fabric
swicthes to
selected border
switch
ACI policy is mapped into
segment list to implement
the flow-based WAN policy:
Cost vs latency
Disjointness
DCE

Large-Scale Aggregation
• Only IGP/SR (no BGP)
• Automated FRR including ASBR failure
• SRGB (k) << # access nodes (100k)
• SDN Controller programs the segment list together with service creation
CoreAcces1 Acces2
A
70
B
72
ASBR2A
1002
ASBR2B
1002
C
72
ASBR SID’s are anycast
ASBR SID’s are unique
across the entire domain
ASBR anycast prefixes and
SID are redistributed within
each access region
Access Nodes are provided a
SID which is unique with
respect to its attached
ASBR’s but not necessarily
unique across the whole
domain
{72} leads to B within Access1
{72} leads to C within Access2
{1001, 72} leads to B from anywhere
{1002, 72} leads to C from anywhere
ASBR1A
1001
ASBR1B
1001

Use Cases &
Implementation: Purpose
Built Applications for WAE

 Network element
 ID circuits traversing
node
 Impact to global network
 Network capacity to reroute
LSPs
 Time changes prior to outage
 Time normalization
Coordinated Maintenance
Select Evaluate Schedule

Coordinated Maintenance
WAN Automation Application

Bandwidth Calendaring
 Source, destination
 Time
 Bandwidth
 SLA
 Impact and feasibility to global
network for the calendared
event
 Confirm calendared event
 Connect with billing system
 Generate quote
Select Evaluate Schedule
Data Center #1
Data Center #2
PCEP
WAN
R1 R2

Application-Engineered Routing
Segment Routing: WAE Calculates Shortest Path and Programs Router A
Apps REST APls
App requests 2 Gbps from
A to Z
Step 1
Shortest path ABCDZ is congested between
C and D. Path ABCOPZ is fine. WAE
verifies BW availability; steers the
traffic on this path.
Step 2
WAE instantiates
the PCEP tunnel on
A {16066, 16068,16065}
Step 3
D
M N P
Z
16065
16068
16066
Full
O
A B C
PCEP

Application-Engineered Routing
Segment Routing: WAE Calculates Two Disjoint Paths and Programs Router A
Apps REST APls
App requests disjoint paths
between A and Z
Step 1
WAE dynamically computes
two disjoint paths to steer
the traffic
Step 2
D
A Z
B
C
E
M ON
Two tunnels avoiding the
optical shared-fate links
WAE programs
two PCEP tunnels
Step 3
PCEP

Use-Case: Bandwidth Scheduling (On Demand)
Provider’s customer has an on-demand need for a data
center backup
Problem
After determining a best path, WAE programs an LSP
using PCEP
Result
Network conditions, content site
reachability fed to collector
1
RESTful APIs
Customer requests DC #1 – DC #2
bandwidth ASAP
2
Demand admission request:
<R1-R3, B/W, NOW>
3
WAE returns option and customer
confirms
4
3
4
If needed (insufficient bandwidth),
R1-R3 LSP tunnel programmed using
PCEP
5
Data Center #1
Data Center #2
PCEP
WAN
R1
R2
Congested!!
R3
2
5
1

Use-Case: Bandwidth Calendaring
Enterprise customer uses self-service portal to request
bandwidth between data centers
Problem
At the predetermined time, WAE places the demand on
the network (using either IGP or MPLS TE)
Solution
Network conditions reported to collector
consistently
1
RESTful APIs
Customer requests DC #1 – DC #2
bandwidth at a future date
2
Demand admission request:
<R1-R3, B/W, future date>
3
WAE returns booking
confirmation as the future date nears
4
3
4
On the future date, WAE places
customer demand on IGP or explicit path
(TE tunnel)
5
Data Center #1
Data Center #2
WAN
R1
R2
R3
2
5
1
PCEP

Use-Case: Tunnel Load Balancing
A service provider needs to efficiently use expensive
resources (high-cost links, perhaps transoceanic)
Problem
The most expensive network resources are fully
optimized by WAE, assigning best load share metrics
using PCEP
Solution
Network conditions reported
to collector, accessible to app
1
RESTful APIs
App determines LSP imbalance and
requests WAE to recalculate LSP load-
share metrics
2
WAE computes new
load share metrics
3
WAE programs new load-share metrics
for LSPs using PCEP
4
2
TE Tunnel Builder
App
WAN
R1
1
AS Foo
PCEP
4
3

Use Case: Policy-Based Path Planning
A service provider needs to provision disjoint LSPs from
an access to aggregation router, even across failures
Problem
WAE creates LSPs and ensures paths remain
disjoint
Result
Network conditions reported
to collector, accessible to app
1RESTful APIs
App requests disjoint LSPs from access
to aggregation router
2
WAE computes new LSPs based on
current topology
3
WAE programs tunnels using PCEP4
2
TE Manager
App
The app and WAE work together to
automatically keep these paths disjoint,
despite failures or topology changes
5
1
PCEP
4
5 WAN
Access Node Aggregation
Node
3

P1
PE1
P2
PE2
CE1
CE2
Demo Topology
Lo0
SID 16041
Lo0
SID 16141
Lo0
SID 16142
Lo0
SID 16042
10
100
10
10
10
10
10
10
5
100
5
30
5
20
Under normal conditions MPLS labels propagated via SR ISIS extensions,
traffic CE1-CE2 travels over LSP following IGP best path
IGP metric = RED
TE metric = BLUE
16042
IP
IP
IP
IP
POP (PHP)

Conclusion

Segment
Routing
(SW upgrade)
SDN
Controller
Applications
1
Applications express
requirements – bandwidth,
latency, interactive …
2
The controller collects data from the
network – topology, link states, link
utilization, …
3
Applications are mapped to a path defined
by a list of segments
Network maintains segments only
No application state
The Solution

Additional References & Information
• Cisco.com Page for Application Engineered Routing
• http://www.cisco.com/c/en/us/solutions/service-provider/application-engineered-routing/index.html
• Segment Routing Page
• http://www.segment-routing.net/
• Cisco.com Page for WAE Products and Associated Services
• http://www.cisco.com/go/networkmodeling
• WAE on DevNet
• https://developer.cisco.com/site/wae/
• Cisco WAN Segment Routing Demo – Realizing your WAN/MAN Orchestration Dreams
• https://www.sdxcentral.com/resources/sdn-demofriday/segment-routing-cisco-demofriday/
• Cisco Advanced Services Capabilities and Offers
• Just Ask!

Application Engineered Routing: Allowing Applications to Program the Network

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Application Engineered Routing: Allowing Applications to Program the Network

Similar to Application Engineered Routing: Allowing Applications to Program the Network (20)

More from Cisco Canada

More from Cisco Canada (20)

Recently uploaded

Recently uploaded (20)

Application Engineered Routing: Allowing Applications to Program the Network