Introducing Application Engineered Routing Powered by Segment Routing

Introducing Application Engineered Routing
Powered by Segment Routing
Clarence Filsfils
Cisco Fellow
cf@cisco.com
Deployment use-cases

2© 2014 Cisco and/or its affiliates. All rights reserved. Cisco Confidential
Velocity
• SR concept was proposed to operators
in November 2012
• Only two years have elapsed since
the first public SR presentation and demo
–  Here, March 2013
• A lot happened, let’s see!

Deployment
• In CY2015, SR will be deployed in all of these markets
WEB
SP Core/Edge
SP Agg/Metro
Large Entreprise

“Comcast’s Converged Network is the strategic platform for delivering our Internet,
Video, Voice, and Business products. As new advanced services are developed
leveraging technologies like; Cloud and NFV, our network needs to simplify, scale and
become extensible. We see IPv6 and Segment Routing as major elements in the
evolution of the network. The ability of the network to support, not impede the
innovation occurring in software and services, will be a major step forward.”
John Leddy, VP of Network Strategy, Comcast

Strong Operator Partnership and Demand
•  Fundamental to the velocity and success
•  Over 30 operators involved
•  Technology tailored to solve real requirements
–  Tactical: solve long-reported issues
–  Strategic: key architecture for long-term evolution

IETF
•  Strong commitment for standardization and
multi-vendor support
•  SPRING Working-Group
•  All key documents are WG-status
•  Over 25 drafts maintained by SR team
–  Over 50% are WG status
–  Over 75% have a Cisco implementation
•  Several interop reports are available
www.segment-routing.net
tools.ietf.org/wg/spring/

Segment Routing
• Source Routing
–  the source chooses a path and encodes it in the packet header as an
ordered list of segments
–  the rest of the network executes the encoded instructions without any
further per-flow state
• Segment: an identifier for any type of instruction
–  forwarding or service

IGP Prefix Segment
•  Shortest-path to the
IGP prefix
•  Global
•  16000 + Index
•  Signaled by ISIS/
OSPF
DC (BGP-SR)
10
11
12
13
14
2 4
6 5
7
WAN (IGP-SR)
3
1
PEER
16005

IGP Adjacency Segment
•  Forward on the IGP
adjacency
•  Local
•  1XY
–  X is the “from”
–  Y is the “to”
•  Signaled by ISIS/
OSPF
DC (BGP-SR)
10
11
12
13
14
2 4
6 5
7
WAN (IGP-SR)
3
1
PEER
124

BGP Prefix Segment
•  Shortest-path to the
BGP prefix
•  Global
•  16000 + Index
•  Signaled by BGP
DC (BGP-SR)
10
11
12
13
14
2 4
6 5
7
WAN (IGP-SR)
3
1
PEER
16001

BGP Peering Segment
•  Forward to the BGP
peer
•  Local
•  1XY
–  X is the “from”
–  Y is the “to”
•  Signaled by BGP-LS
(topology information)
to the controller
DC (BGP-SR)
10
11
12
13
14
2
6
7
WAN (IGP-SR)
3
1
PEER
Low Lat, Low BW
4
5
High Lat, High BW
147

WAN Automation Engine
•  WAE collects via
BGP-LS
–  IGP segments
–  BGP segments
–  Topology
DC (BGP-SR)
10
11
12
13
14
2 4
6 5
7
WAN (IGP-SR)
3
1
PEER
Low Lat, Low BW
BGP-LS
BGP-LS
BGP-LS

An end-to-end path as a list of segments
•  WAE computes that
the green path can be
encoded as
–  16001
–  16002
–  124
–  147
•  WAE programs a
single per-flow state
to create an
application-
engineered end-to-
end policy DC (BGP-SR)
10
11
12
13
14
2 4
6 5
7
WAN (IGP-SR)
3
1
PEER
Low Lat, Low BW
50
Default ISIS cost metric: 10
{16001,
16002,
124,
147}
PCEP, Netconf,
BGP

PCEP-reply
(OK, BSID: 200)
Binding Segment
•  WAE instructs edge to install an SRTE policy
–  For this traffic, push this list of segments
•  WAE defines the SRTE policy
–  Explicit: it provides an explicit list of segments
–  Dynamic: it provides optimization objective and constraints to
the edge router. The edge router computes the list of
segments to match these objectives.
•  The edge router assigns a binding segment to the
SRTE policy and installs it in dataplane
–  Pop and Push the related list of segments
–  Binding segment is local
•  Controller collects binding segments and
characteristics of the SRTE policies (e.g. PCEP)
2 4
6 5
Default Latency metric: 10
WAN
3
1
PCEP-request
(SR Policy,
low-latency,
to 4)
200: pop
and push
{16002,
124}
50

An end-to-end path with binding segment
•  WAE computes that
the green path can be
encoded as
–  16001
–  200
–  147
•  WAE programs a
single per-flow state
to create an
application-
engineered end-to-
end policy
DC (or AGG)
10
11
12
13
14
2 4
6 5
7
50
WAN
3
1
PEER
Low Lat, Low BW
Low-Latency to 7
for application …
Push
{16001,
200, 147}

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

•  Applications program the
network on a per-flow
basis
•  End-to-End policy
–  DC, WAN, AGG, PEER
•  Millions of flows
–  No per-flow midpoint state
–  No reclassification at
boundaries
•  Simple
–  BGP and ISIS/OSPF
DC (or AGG)
10
11
12
13
14
2 4
6 5
7
50
WAN
3
1
PEER
Low Lat, Low BW
High-BW to 7
for application …
Push
{16001,
16005}
High Lat, High BW

•  Automated 50msec FRR
DC (or AGG)
10
11
12
13
14
2 4
6 5
7
50
WAN
3
1
PEER
Low Lat, Low BW
High-BW to 7
for application …
Push
{16001,
16005}
High Lat, High BW

•  Any policy can be
programmed by the
application
•  The network scaling and
simplicity is preserved
DC (or AGG)
10
11
12
13
14
2 4
6 5
7
50
WAN
8
8
PEER
Low Lat, Low BW
High-BW to 7
Load-share across DCedges
for application …
Push
{16008,
16005}
High Lat, High BW

programmed by the
application
DC (or AGG)
10
11
12
13
14
2 4
6 5
7
50
WAN
3
1
PEER
Low Lat, Low BW
Low-Latency to 7,
DC Plane 0 only
for application …
Push
{16010,
16001,
200,
147}
High Lat, High BW

programmed by the
application
DC (or AGG)
10
11
12
13
14
2 4
6 5
7
50
WAN
3
1
PEER
Low Lat, Low BW
High-BW to 7,
1st VNF at 14
2nd VNF at 6
for application …
Push
{16014,
301,
16003,
16006,
302,
16005}
High Lat, High BW

Application Engineered Routing Journey
Adding value at your own pace
Enable Segment Routing on the network (Software only)
Insert 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

Incremental Deployment
Use-Cases

Demonstrating these use-cases
• This section illustrates various use-cases that can be
deployed incrementally
• Kris Michielsen and Roberta Maglione are available at the
Cisco booth to demonstrate these use-cases
• Also leverage dcloud.cisco.com where you can test these
use-cases by yourself

Planning your Deployments
• Mate Design
–  TILFA FRR
–  Centralized BW Optimization
–  Traffic Engineering
> Latency vs Cost
> Exclusion/Inclusion ip address, srlg, affinity
> Disjointness

IPv4 VPN/Service transport
• IGP only
–  No LDP, no RSVP-TE
• ECMP
1
2 3
4
6 5
7
Site1 Site2
pkt
16007
vpn
pkt
16007
vpn
pkt
pkt
vpn
pkt

IPv6 VPN/Service transport over v4
segments
• IGP only
• ECMP
1
2 3
4
6 5
7
Site1 Site2
pkt
16007
6PE
pkt
16007
6PE
pkt
pkt
6PE
pkt

IPv6 Internet transport over v6 segments
• IGP only
• ECMP
1
2 3
4
6 5
7
V6 Internet V6 Internet
pkt
16007
pkt
16007
pkt
pkt
pkt

Seamless interworking with LDP
• Seamless deployment
1
2 3
4
6 5
7
Site1 Site2
pkt
pkt
vpn
pkt
pkt
16007
vpn
pkt
16007
vpn
pkt
vpn
LDP(7)

FRR Classic (ATM-alike)
•  Midpoint backup circuit states
•  Non-Optimum
–  Back to next-hop and then forward
•  Extra Signalling Protocol over IGP
–  RSVP-TE
•  Not ECMP
1
2 3
4
6 5
7
pkt
16007
circuit
pkt
16007
pkt
16007

TILFA FRR
•  50msec FRR in any topology
•  IGP Automated
•  Optimum
–  Post-convergence path
•  No midpoint backup state
•  Detailed operator report
–  S. Litkowski, B. Decraene, Orange
•  Mate Design
–  How many backup segments
–  Capacity analysis
1
2 3
4
6 5
7
pkt
16007
16005
pkt
16007
pkt
16007

OAM
• A centralized application can
engineer its OAM probes
along any selected path
• Correlation between different
probes allows to localize
problems
draft-geib-spring-oam-usecase-02
1
2 3
5 4
pkt
154
135
123
112
125
132
143
151

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
Evolve Carrier Ethernet Architecture with SDN and Segment Routing

Traffic Engineering with SR
•  No midpoint state (n^2 scale In RSVP-TE)
•  No extra protocol (RSVP-TE)
•  Native ECMP
•  Few segments are required
–  Apply Mate Design on your data
•  Distributed computation or Centralized
–  Optimize on Cost, Latency or BW
–  Include/exclude Address, Affinity, SRLG
–  Disjointness
•  Integration with IP/Optical optimization

Latency example
• Dynamic path-option
computed by the head-end
1
2
4
6 5
7
Default ISIS (cost) metric: 10
Default latency metric: 10
ISIS: 50
pkt
16007
Low Cost to 7
pkt
16002
124
16007
Low Latency to 7

0 20 40 60 80 100
ICDF (%)
0
10
20
30
40
50
60
70
Overheadcomparedtominimaldelaypath(ms)
IGP path
1 segment
2 segments
Latency path

Avoidance example
• Dynamic path-option
computed by
centralized PCE
1
2
4
6 5
7
pkt
16007
Low Cost to 7
pkt
16005
16007
Low Cost to 7 & avoid blue
PCEP
request
PCEP reply

Centralized Traffic Engineering
0 20 40 60 80 100 120
050100150
X1 [links] − SR TE Results (failures)
Failure #
Max.Utilization(%)
●●●●●●●●●●●●●●●●●
●●
●●
●
●●●●●●●●●●●●●●●●●●
●●●●●●●●●●●●●●●●●●●●●
●●●●●
●●●●●●●●●●●●●●●
●●●●●●●●●●●●●●
●
●●●●●●●●●●●●●●●●●●●●●●●●●●●
●
IGP util
SRTE util
# SRTE tunnels
0 50 100 150
050100150200250
X1 [srlgs] − SR TE Results (failures)
Failure #
Max.Utilization(%)
●
●●●●●●●●●●
●
●●●●●
●
●●●●●
●
●●●●●●●●●●●●●●●
●
●●●●●●●●●●●●●●●
●
●●●●●●●●●●●
●
●●●●●●●
●
●
●
●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●
●
●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●
●
IGP util
SRTE util
# SRTE tunnels

Classic Content Delivery
•  Default content from 4 to 7
–  Via shortest IGP path
to best BGP nhop
•  Alternate connectivity is not
leveraged although potentially
offering
–  lower congestion / latency
–  better business policies
1 2
6
4 3
AS1
5
7
AS6AS5
AS7
pkt
16001

Optimized Content Delivery
• On a per-content, per-user basis,
the content delivery application can
engineer
–  the path within the AS
–  the selected border router
–  the selected peer
• Also applicable for engineering
egress traffic from DC to peer
–  BGP Prefix and Peering Segments
1 2
6
4 3
AS1
5
7
AS6AS5
AS7
pkt
16003
16002
126

Binding Segment
•  Any router who is the headend
of an SRTE policy installs in
dataplane a binding segment
•  A binding segment is local
•  Dataplane behavior
–  Pop and push the list of segments
associated with the SRTE policy
•  Controller collects binding
segments and characteristics of
the SRTE policies (e.g. PCEP)
2 4
6 5
ISIS: 35
WAN
3
1
PCEP-request
(SR Policy,
low-latency,
to 4)
200: pop
and push
{16002,
16004}
PCEP-reply
(OK, BSID: 200)

•  Per-application
flow engineering
•  End-to-End
–  No signaling
–  No midpoint state
boundaries
DC (or AGG)
10
11
12
13
14
Push
{16001,
200, 147}
Low-Latency to 7
for application A12
2 4
6 5
7
ISIS: 35
WAN
3
1
BSID: 200
200: pop
and push
{16002,
16004}
PEER
Low Lat, Low BW
Low-Lat to 4
PeerSID: 147, Low Lat, Low BW
PeerSID: 147, High Lat, High BW

•  Per-application
flow engineering
•  End-to-End
–  No signaling
–  No midpoint state
boundaries
DC (or AGG)
10
11
12
13
14
Push
{16010,
16001,
200, 147}
Low-Latency to 7,
DC Plane 0 only,
for application A12
2 4
6 5
7
ISIS: 35
WAN
3
1
BSID: 200
200: pop
and push
{16002,
16004}
PEER
Low Lat, Low BW
Low-Lat to 4
PeerSID: 147, Low Lat, Low BW
PeerSID: 147, High Lat, High BW

Application-Engineered Routing
•  Application programs the Segment Routing network to deliver
end-to-end per-flow policy from DC through WAN to end-user
•  Adding value at your own pace
–  Leveraging the existing MPLS dataplane without any change. SW upgrade only.
–  Simplification, Automated 50msec FRR, per-domain and then end-to-end policies
•  Economic gains
–  Improved service richness and velocity
–  Optimized CAPEX and OPEX thanks to the simplicity of the SR architecture
•  Segment Routing deployments in CY15 in all the markets
–  WEB, SP, Entreprise
•  Strong partnership with lead operator group
•  Commitment to standardization and multi-vendor support

•  http://www.segment-routing.net/
•  ask-segment-routing@cisco.com
Stay Informed

Thank you

The circuit alternative
•  Maintaining
per-flow circuit state at
each hop,
with complex
reclassification at
domain boundaries,
does not support the
application needs for
end-to-end
programmed
policy at scale
DC (or AGG)
10
11
12
13
14
2 4
6 5
7
ISIS: 35
WAN
3
1
PEER
Low Lat, Low BW

Circuit
State
WAE
WAE
WAE
Orch
Classif
State
Per-Flow
SR State
Per-Flow
SR State
{16001,
124
NSO
Classif.
State
APP

Introducing Application Engineered Routing Powered by Segment Routing

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Introducing Application Engineered Routing Powered by Segment Routing

Similar to Introducing Application Engineered Routing Powered by Segment Routing (20)

More from Cisco Service Provider

More from Cisco Service Provider (20)

Recently uploaded

Recently uploaded (20)

Introducing Application Engineered Routing Powered by Segment Routing