introducing application engineered routing powered by segment routing

Introducing Application Engineered Routing Powered by Segment Routing

Clarence Filsfils Cisco Fellow [email protected]

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 ISIS cost metric: 10 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


Application Engineered Routing

•  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





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





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 – No LDP, no RSVP-TE

• 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 – No LDP, no RSVP-TE

• 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 –  No LDP, no RSVP-TE

•  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

Core Acces1 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

Over

hea

dco

mp

are

dto

min

imal

del

ay

path

(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

050

100

150

X1 [links] − SR TE Results (failures)

Failure #

Max

. Util

izat

ion

(%)

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●●●●●●●●●●●●●●●●●●●

●●●●●●●●●●●

●●●●●●●●●●●●●●●●●●●●●●●

●●●●●●●●●●●●●●●●

●●●●●●●●●●●●

●

IGP utilSRTE util# SRTE tunnels

0 50 100 150

050

100

150

200

250

X1 [srlgs] − SR TE Results (failures)

Failure #

Max

. Util

izat

ion

(%)

●

●●●●●●●●●●

●

●●●●●

●

●●●●●

●

●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●

●

●●●●●●●●●●●

●

●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

IGP utilSRTE 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

AS6 AS5

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

AS6 AS5

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 –  DC, WAN, AGG, PEER

•  Millions of flows –  No signaling –  No midpoint state


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 –  DC, WAN, AGG, PEER

•  Millions of flows –  No signaling –  No midpoint state


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

Conclusion


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/ •  [email protected]

Stay Informed


Thank you

Appendix


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