Introduction to Segment Routing

© 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 1Cisco Confidential 1© 2013 Cisco and/or its affiliates. All rights reserved.

Ismail AliTechnical Consultant, Cisco Systems Malaysia

© 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 2

• Introduction

• Incremental Deployment Use Cases

• Standardization

• Conclusion



• Source Routing: source chooses a path and encodes it in packet header as an ordered list of segments.

• Segment: an identifier for any type of instructionServiceContextLocatorIGP-based forwarding constructBGP-based forwarding constructLocal value or Global Index

Segment = Instructions such as "go to node N using the shortest path"


• MPLS: an ordered list of segments is represented as a stack of labelsSR re-uses MPLS data plane without any change

• IPv6: an ordered list of segments is represented as a routing extension header

This presentation focuses on MPLS data plane

IPv6 IPv6

IPv6

Control Plane

IPv4

MPLSData Plane


• Locally significant to node allocating it

• Node processes SID and switches packet towards adjacency

• Advertised as an absolute value

• Globally significant within SR domain

• All nodes switch packet towards prefix/node via shortest path

• Advertised as a relative (index) value

• Make use of a per-node reserved block (SR Global Block or SRGB)

B C

N O

Z

D

P

A

91019105

9107

9103

9105

B C

N O

Z

D

P

A

65

65

65 65

Prefix/Node SID Adjacency SID


D(php)

7

A B

C D

E103

103

Payload Payload

201202

Payload

202201202

Payload

202

Payload Payload

C D

A B

E

202

202

201

102202

Payload

A B102

C D

E

202

Payload

202Payload

C E C D EB C D(php)

EB

Node Path Adjacency Path Combined Path


• Efficient packet networks leverage ecmp-aware shortest-path!node segment!

• Simplicityone less protocol to operateNo complex LDP/ISIS synchronization to troubleshoot

8

A B

M N

PE2PE1

All VPN services ride on the node segment to PE2



• Tokyo to Brusselsdata: via US: cheap capacityVoIP: via Russia: low latency

• CoS-based TE with SRIGP metric set such asTokyo to Russia: via Russia

Tokyo to Brussels: via US

Russia to Brussels: via Europe

Anycast segment “Russia” advertised by Russia core routers

• Tokyo CoS-based policyData and Brussels: push the node segment to Brussels

VoIP and Brussels: push the anycast node to Russia, push Brussels

10

Node segment to Brussels

Node segment to Russia


• For Traffic Engineering

• or for OAM

11

B C

N O

Z

D

P

A

91019105

9107

9103

9105

91019101

91059107

91039105

9101


Path ABCOPZ is ok. I account the BW. Then I steer the traffic on this path

FULL66

6568

Tunnel AZ onto {66, 68, 65}

The network is simple, highly programmable and responsive to rapid changes

2G from A to Z please


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 segmentsNo application state

Segment Routing

SDNController

Applications1

2

3


• Applications program the network on a per-flow basis

• End-to-End policyDC, WAN, AGG, PEER

• Millions of flowsNo per-flow midpoint stateNo reclassification atboundaries

• SimpleBGP and ISIS/OSPF

DC (or AGG)

10

11

12

13

14

2 4

6 5

7

Default ISIS cost metric: 10Default Latency metric: 10

50

WAN

3

1

PEER

Low Lat, Low BW

High-BW to 7for 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 7for 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 7Load-share across DC edgesfor 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 onlyfor 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 142nd VNF at 6 for application …

Push{16014,

301,16003,16006,302, 16005}

High Lat, High BW


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

© 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 20Cisco Confidential 20© 2013 Cisco and/or its affiliates. All rights reserved.


• Control plane scale and complexity• Many protocols• Many encapsulations• Many bugs• Forwarding plane capacity• Lots of growth == lots of stress


• Peering --- want programmatic control over policy• Massively Scaled Datacenters (even more protocols, high device and link counts, commodity hardware, greater vendor diversity, legacy applications)• Inter-DC vs External workloadsLatency-sensitive vs bulkScheduled vs unscheduled


• Reduced complexityProtocol counts

Fewer protocols == less code == fewer bugsAmount of distributed control plane stateUnified forwarding plane (analog of BGP is the Better IGP )

• Maintain healthy vendor diversity• Want to (eventually and incrementally) enable software control

Leverage our in-house software (and networking) expertiseRe-use ongoing controller and TE work

Don’t want another new parallel network


• Well-understood forwarding plane (MPLS)• Encourages sensible engineering tradeoffs• Possibility of removing some distributed signaling protocols• Removes per-tunnel state from the core• Gets us closer to a static core, significantly quieter control plane• Good interop with existing protocols

Safe incremental deployment

• SDN with standards-based interfacesSegments are defined at a useful level of abstraction for compositionAnycast is also useful


• Autopilot for orchestration • SWAN for TE• BGP-LS for topology and SR label discovery• BGP-LU for creating tunnels

Widely supported, so we can impose on the non-SR edgeSingle label (but can hack w/Route Resolution)

Label stacks would be nicerCan scale with indirection and vanilla BGPNon-standard use of RFC 3107, maybe we can do better

• BGP prefix SID’s for the MSDC• EPE scenario for peering

BMP for route collection


• Built out a full emulation of core network using VM’s running early vendor(s) codeFantastic tool, please more fidelity.

• Modeled the entire control plane w/MPLS forwardingObviously slower in the forwarding plane

• Very basic controller driving BGP-LU via REST


• Investigated several use cases:Basic forwarding over an SR routed networkTraffic steeringEPEVendor interopServer-to-server

• Found a few bugs and interop issuesMostly design/use cases.

• Management is on the thin sideStill awkward to see some SR stateNot quite fully integrated



• IETF standardization in SPRING working group

• Protocol extensions progressing in multiple groupsIS-ISOSPFPCEIDR6MAN

• Broad vendor and customer support

Sample IETF DocumentsSegment Routing Architecture

(draft-ietf-spring-segment-routing)

Problem Statement and Requirements(draft-ietf-spring-problem-statement)

IPv6 SPRING Use Cases (draft-ietf-spring-ipv6-use-cases)

Segment Routing Use Cases (draft-filsfils-spring-segment-routing-use-cases)

Topology Independent Fast Reroute using Segment Routing(draft-francois-spring-segment-routing-ti-lfa)

IS-IS Extensions for Segment Routing(draft-ietf-isis-segment-routing-extensions)

OSPF Extensions for Segment Routing(draft-ietf-ospf-segment-routing-extensions)

PCEP Extensions for Segment Routing(draft-ietf-pce-segment-routing)

Close to 30 IETF drafts in progress


• Strong commitment for standardization andmulti-vendor support

• SPRING Working-Group• All key documents are WG-status• Over 25 drafts maintained by SR teamOver 50% are WG statusOver 75% have a Cisco implementation

• Several interop reports are available

www.segment-routing.nettools.ietf.org/wg/spring/


• Fundamental to the velocity and success• Over 30 operators involved• Technology tailored to solve real requirementsTactical: solve long-reported issuesStrategic: key architecture for long-term evolution


• Platforms: ASR9000, CRS-1/CRS-3, WAE (shipping)

• IS-IS IPv4 (shipping)Node/Adjacency SID advertisementLDP interworking (mapping server/client)Traffic protection (topology independent LFA link protection)

• OSPFv2 (shipping)Node SID advertisementTraffic protection (LFA)

• UpcomingIS-IS / OSPFv2 paritySR Traffic Engineering (manual provisioning and PCEP)OAM (Ping/Trace)



• Simple routing extensions to implement source routing

• Packet path determined by prepended segment identifiers (one or more)

• Data plane agnostic (MPLS, IPv6)

• Network scalability and agility by reducing network state and simplifying control plane

• Traffic protection with 100% coverage with more optimal routing

• Interworking capabilities with LDP-only devices

34


Thank you.

http://tools.ietf.org/wg/spring/http://www.segment-routing.net/

Internet

Introduction to Segment Routing