BRKSP 2551 1

Introduction to
Segment Routing
Alberto Donzelli, Principal Architect
BRKSP-2551
• Introduction
• Standardization and market update
• Technology overview
• LDP-SR coexistence and migration
• IGP based protection: TI-LFA
• Flexible Algorithm and soft slicing
• Traffic Engineering and traffic
Agenda •
steering
Controller path computation and
automation
• Circuit Style SRTE (and PLE)
• Conclusions
BRKSP-2551 © 2024 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Introduction
Infrastructure Simplification, de-layering
and Convergence Areas
Delayering Unified Infrastructure Horizontal Integration

IP Data Access
ATM/Ethernet Circuit Aggregation
SDH/OTN Video Edge
WDM Fixed Mobile Core and DC
Transformation
Automation and Intent driven Virtualization

RON Fixed - Mobile End to End IP
Routed Optical Network Data – Video - PLE Segment Routing
Segment Routing Unified Fabric
Simplify Virtualize Automate Program
SR Unified Fabric
New business capabilities built on the network as the platform;
Enabling customers to achieve business outcomes faster with ruthless ease
Understanding Today’s Service Creation
Limited Cross-domain Automation, Cumbersome Service Assurance
Legacy Central Office

Complex E2E Quality of Service (QoS)
Metro Network Domain Core Network Domain Data Center Domain
L2VPN L3VPN VXLAN VNF VNF
Aggregation
Ethernet MPLS IP
Access
Centralized Services Delivery
Hardware
Appliances
End-to-end service provisioning is lengthy and complex

• Multiple network domains under different management teams
• Manual operations
• Heterogeneous underlay and overlay networks
SR-MPLS: SDN ready
“Network as a Fabric” for Service Creation
Homogenous Cross-domain Automation & Assurance
SDN
Control
Cloud Scale Networking
Central Office
SDN SDN SDN
Access Metro Network Domain Core Network Domain Data Center Domain
BGP signaled VPN L2/L3 VNF VNF
Aggregation
VNF
Segment Routing
VNF
Centralized Services Delivery
Compute Leaf Spine
End-to-end service provisioning is simple

• Multiple network domains under same management teams
• Automated operations
• Homogenous underlay and overlay networks
Intent Based Network Virtualization
Soft Slicing
SDN
Cloud Scale Networking Control Controller
Central Office
Access
Metro Network Core and Peering Network Network Data Center
High Bandwidth
Encrypted mMTC
Low Delay
uRLLC BGP VPN VNF
VNF
IGP Segment Routing VNF
VNF
Compute Leaf Spine
Simplified intent based Model driven, Multi Domain Path Single infrastructure for different SLA
steering, per destination, per Computation, Intent aware and forwarding requirements
flow forwarding and protection.
Simplify Automate Virtualize
Standardization
and market
update
Segment Routing Standardization IETF
First RFC document - RFC 7855 (May 2016)
Reference IETF drafts and RFCs examples
IS-IS Architecture
Active working groups
• Segment Routing Architecture RFC 8402

OSPF • Segment Routing Policy Architecture RFC 9256
PCEP MPLS
BGP • Segment Routing with MPLS data plane RFC 8660
• Segment Routing interworking with LDP RFC 8661
IDR • SR-MPLS over IP RFC 8663
6MAN IS-IS
• IS-IS Extensions for Segment Routing RFC 8667
• IGP Flexible Algorithm WG Document
• IS-IS Traffic Engineering (TE) Metric Extensions RFC 7810
OSPF
• OSPF Extensions for Segment Routing RFC 8665
• IGP Flexible Algorithm WG Document
• OSPF Traffic Engineering (TE) Metric Extensions RFC 7471
A comprehensive list @ www.segment-routing.net
Segment Routing Public Interoperability
…
2015 2016 2017 2018 2023 2024
First SR-MPLS First SRv6

interop interop
• Since 2015, EANTC has hosted vendor-neutral interoperability events focused on Segment Routing
• Emphasis on protocol interoperability and functionality testing, EANTC results provide starting guidance to an operator’s own interop
validation
• Public whitepaper with results posted after each event (EANTC 2021 results)
• Strong participation from network equipment vendors confirm SR as de-facto SDN architecture
• Cisco has remained committed to the event with participation including networking equipment as
well as automation / controller / orchestrator
From Thought to Deployment Leadership
Americas EMEA APJC
585 474 205 2%

Web / OTT
50%
Service Providers
48%
Enterprise
Deployed
Active Testing
Deployment Planned
Technology
Overview
Segment Routing
• Source Routing paradigm
Data Plane
• Stateless IP fabric !!!
MPLS IPv6 Path expressed in the packet Data
(segment labels) (+ SR extension header)
Shortest path
Control Plane
Routing protocols with SDN controller

extensions ( BGP, PCEP,
(IS-IS, OSPF, BGP) NETCONF/YANG)
Paths options Traffic Engineered path
Dynamic Explicit
(Optimized CSPF computation) (expressed in the packet)
Massive Protocol Symplification
Before After
L2/L3VPN Services LDP BGP L2/L3VPN EVPN BGP
Inter-Domain Connectivity BGP-LU
Inter-Domain Connectivity with SLA
Protection FRR/TE RSVP IGP+
Traffic Engineering
Segment
LDP Protection FRR – TI-LFA
Intra-Domain CP Routing
Intra -Domain CP
IGP
Control Plane
Architecture
Before and After
MPLS Architecture with LDP
Router to Router Router to Router

IP prefixes Label/Prefix binding
Control Plane
IGP
Routing Label
Information LDP Information
Base (RIB) Base (LIB)
MPLS Architecture with SR
Router to Router
IP prefixes/labels
Control Plane
IGP
Routing Label
Information Information
Base (RIB) Base (LIB)
IGP Segments
Why not to use the IGP to program MPLS labels?
IGP segments
Two basic building blocks distributed by IGP
• Prefix Segments
• Adjacency Segments
IGP Prefix Segment
Shortest-path to the IGP prefix Loopack0
1.1.1.6/32
Global Segment
16006
Equal Cost MultiPath (ECMP)-aware 2 4
Label = 16000 + Index 16006
16006
Advertised as index
1 16006 6
Distributed by ISIS/OSPF 16006
16006
Global Segment
3 5
RP/0/RP0/CPU0:Node-1#sh mpls forwarding prefix 1.1.1.6/32
Tue Jan 29 10:30:53.133 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ----------------- ------------ --------------- ------------
16006 16006 1.1.1.6/32 Te0/0/0/2 77.1.2.2 0
16006 1.1.1.6/32 Te0/0/0/3 77.1.3.3 0
IGP Prefix Segment
Shortest-path to the IGP prefix Loopack0
1.1.1.6/32
Global Segment
Te0/0/0/4 16006
Equal Cost MultiPath (ECMP)-aware 2 4
Label = 16000 + Index 16006
16006
Advertised as index
1 6
Distributed by ISIS/OSPF
Global Segment
3 5
Tue Jan 29 10:30:53.133 UTC
------ ----------- ----------------- ------------ --------------- ------------
16006 16006 1.1.1.6/32 Te0/0/0/4 77.2.4.4 0
IGP Prefix Segment
Loopack0
Shortest-path to the IGP prefix 1.1.1.6/32
Global Segment 16006

2 4
Equal Cost MultiPath (ECMP)-aware
Label = 16000 + Index
Advertised as index 1 6
Global Segment 3 5
Tue Jan 29 10:30:53.133 UTC
------ ----------- ----------------- ------------ --------------- ------------
16006 Pop 1.1.1.6/32 Te0/0/0/1 77.4.6.4 0
IGP Adjacency Segment
Forward on the IGP adjacency
Local Segment
Advertised as label value 2 4
Label automatically
1 Adj to 2
6
24054
allocated from the
dynamic label pool Adj to 5
3 5 24056
24053
Adj to 3
Combining IGP Segments
Steer traffic on any path through the
network 16006
Packet to 6
Path is specified by a stack of labels
2 4
No path is signaled Packet to 6
No per-flow state is created

Single protocol:
1
16005
24054
100
6
16006
IS-IS or OSPF 24054

Packet to 6
16006
Packet to 6 3 5
16005 24054
Forwarding
Plane
MPLS Data Plane Operation
Prefix SID
SRGB [16,000 – 23,999 ] SRGB [16,000 – 23,999 ] SRGB [16,000 – 23,999 ] SRGB [16,000 – 23,999 ]
A B C D Loopback X.X.X.X
Prefix SID Index = 41
Push Swap Pop Pop

Push
16041 16041
VPN Label VPN Label VPN Label
Payload Payload Payload Payload Payload
MPLS Forwarding Plane Operation
Adjacency SID, Prefix SID, VPN label
SRGB [16,000 – 23,999 ] SRGB [16,000 – 23,999 ] SRGB [16,000 – 23,999 ] SRGB [16,000 – 23,999 ]
A B X D Loopback X.X.X.X
Adjacency Prefix SID Index = 41
SID = 30206
Push Pop Pop Pop
Push
Push
30206
16041 16041
VPN Label VPN Label VPN Label
Payload Payload Payload Payload Payload
SR reserved
label blocs
Reserve Label Space for SR Operation
Segment Routing Global Block (SRGB) – Segment Routing Local Bloc (SRLB)
• SRGB allocation
• Default Range SRGB is 16000-23999
• Any custom range can be defined
Available label space
• SRLB allocation
• Default Range SRLB is 15000-15999
• Any custom range can be defined
• To be used for static configuration of locally
significant SIDs (e.g. Adjacency SID, Binding
SIDs)
This ranges are reserved and no used by

other protocols (LDP, BGP, RSVP-TE)
MPLS and LDP coexistence
LDP FEC to 1.1.1.1/32
4 3 2 1
24001 24004 32020 24005

Payload Payload Payload Payload
16,000 Idx 0 16,000 Idx 0 16,000 Idx 0
SRGB
SRGB
SRGB
…
16,001 Idx 1 …
16,001 Idx 1 16,001
… Idx 1
… … … … … …
23,999 Idx 7,999 23,999 Idx 7,999 23,999 Idx 7,999
24,000 24,000 24,000
24,001 24,004 24,004 32,020 32,020 24,005
… …
… … …
1,048,575 1,048,575 1,048,575
LDP-SR
coexistence and
Migration
Simplest migration LDP to SR
Assumptions:
• all the nodes can be upgraded to SR
• all the services can be upgraded to SR
Initial state: All nodes run LDP, not SR

LDP LDP
2 4
LDP LDP
1 LDP 6
3 5
LDP LDP
LDP Domain
Assumptions:

SR+LDP SR+LDP
Step1: All nodes are upgraded to SR
2 4
• In no particular order SR+LDP SR+LDP
• leave default LDP label imposition preference
1 LDP 6
3 5
SR+LDP SR+LDP
SR+LDP Domain
Assumptions:

SR+LDP SR+LDP
• In no particular order 2 4
SR+LDP SR+LDP
1 SR 6
Step2: All PEs are configured to prefer SR label
imposition sr-prefer 3 5
• In no particular order
SR+LDP SR+LDP
SR+LDP Domain
Assumptions:

SR SR
2 4
• In no particular order SR SR
1 SR 6
†
Step2: All PEs are configured to prefer SR
label imposition 3 5
• In no particular order SR SR
Step3: LDP is removed from the nodes in SR Domain

the network
Final state: All nodes run SR only
• In no particular order
sr-prefer configuration
IOS XR
IOS-XR
segment-routing
!
router isis core
address-family ipv4 unicast
segment-routing mpls sr-prefer
!
!
commit
IGP based
Traffic
Protection
TI-LFA
Topology Independent LFA (TI-LFA) – Benefits
100%-coverage 50-msec link, node, and SRLG protection

Simple to operate and understand
• automatically computed by the IGP
• One configuration line only
Prevents transient congestion and suboptimal routing
• leverages the post-convergence path, planned to carry the traffic
TI-LFA – Zero-Segment Example
A 8
TI-LFA for link R1-R2 on R1 16008
Calculate post-convergence SPT Packet to 8
• SPT with link R1R2 removed from topology

1 2
Derive SID-list to steer traffic on
post-convergence path 16008
Packet to 8
R1 will steer the traffic towards Packet to 8
5
LFA R3
RP/0/0/CPU0:XR-1# sh mpls forwarding labels 16008

Sat Feb 4 15:09:07.355 CET
Local Outgoing Prefix Outgoing Next Hop Bytes 4 3
------ ----------- ------------------ ------------ --------------- ------------
16008 16008 SR Pfx (idx 8) Te0/0/1/2 20.40.86.40 627555
16008 SR Pfx (idx 8) Te0/0/1/3 20.77.86.77 0 (!)
Default metric: 10
TI-LFA – Single-Segment Example
TI-LFA for link R1-R2 on R1 16008 A 8

Calculate post-convergence SPT Packet to 8
Packet to 8
Derive SID-list to steer traffic on
1 2
post-convergence path →
via node 4
• Also known as “PQ-node” 16004
R1 will push the prefix-SID of 16008 5
16008
R4 on the backup path Packet to 8
Packet to 8
RP/0/0/CPU0:XR-1# sh mpls forwarding labels 16008
Sat Feb 4 15:09:07.355 CET 4 3
------ ----------- ------------------ ------------ --------------- ------------
16008 16008 SR Pfx (idx 8) Te0/0/1/2 20.40.86.40 627555
16004 16008 SR Pfx (idx 8) Te0/0/1/3 20.77.86.77 0 (!)
Default metric:10
TI-LFA – Double-Segment Example
A 8
16008
Packet to 8 Packet to 8
TI-LFA for link R1-R2 on R1 1 2
Calculate post-convergence SPT
SID-list to steer traffic on post- 16004
convergence path → <Prefix- 24043
5
SID(R4), Adj-SID(R4-R3) 16008 16008
• R4 “P- and R3 Q-node” Packet to Z Packet to 8
R1 will push the prefix-SID of
4 3
R4 and the adj-SID of R4-R3
R4 R3
1000
link on the backup path
24043 Default metric: 10
16008
Packet to Z
TI-LFA protection Coverage
Every prefix in the FIB is protected
RP/0/0/CPU0:XR-1#sh route 50.50.50.50
Routing entry for 50.50.50.50/32
Known via "isis dc", distance 115, metric 20, labeled SR, type level-2
Installed Feb 1 09:19:33.208 for 2d21h
Routing Descriptor Blocks
33.77.86.77, from 50.50.50.50, via TenGigE0/0/0/1, Backup (TI-LFA)
Repair Node(s): 69.69.69.69
Route metric is 40
33.40.86.40, from 50.50.50.50, via TenGigE0/0/0/0, Protected
Route metric is 20
No advertising protos.
RP/0/0/CPU0:XR-1#show isis fast-reroute summary

IS-IS SR-AS-1 IPv4 Unicast FRR summary
Critical High Medium Low Total
Priority Priority Priority Priority
Prefixes reachable in L2
All paths protected 0 0 4 8 12
Some paths protected 0 0 0 0 0
Unprotected 0 0 0 0 0
Protection coverage 0.00% 0.00% 100.00% 100.00% 100.00%
TI-LFA – Timeline
detection
Link cut
IGP path Computation
Per-Prefix reconvergence
TI-LFA
Primary Primary path
protected DROP Protected Path
path (post convergenge)
Path
~500ms T0 T1T2 T3
T1 – T0 = time to detect the failure: from few ms (light down) ~15-30ms (BFD)
T2 – T1 = time to invalidate the impacted interface: few ms (Hierarchical FIB)
T2 – T0 < 50ms
T3 – T1 = time for IGP to re-converge, sub-second (~500ms)
Flex Algo and IGP
extended TE metrics
Link Delay Measurement
One Way Delay = (T2 – T1)
Two-Way Delay
• TWAMP probe (rfc 5357)

TX Timestamp T1 RX Timestamp T2
• IGP and BGP-LS support:
• Extended TE Link Delay Metrics is supported in Local-end Remote-end
ISIS (rfc 8570) and OSPF (rfc 7471) PM Query Packet

99.2.1.2
• BGP-LS (rfc 8571) Extended TE Link Delay

Metrics 99.1.2.1 PM Response Packet
• Latency automatically included in IGP topology

and SR-PCEs
IOS-XR SR- PCE view
performance-measurement Link[0]: local address 99.1.2.1, remote address 99.2.1.2
interface TenGigE0/0/0/8 Local node:
delay-measurement ISIS system ID: 0000.0000.6666 level-2 ASN: 64002
! Remote node:
interface TenGigE0/0/0/9 TE router ID: 5.5.5.5
delay-measurement Host name: Napoli-5
! ISIS system ID: 0000.0000.5555 level-2 ASN: 64002
delay-profile interfaces Metric: IGP 10, TE 50,Delay 6000
advertisement Bandwidth: Total 125000000, Reservable 0
periodic Adj SID: 24005 (protected) 24004 (unprotected)
minimum-change 200 Excluded from CSPF: no
threshold 5
Multiple Prefix SIDs for the same end-point
for different intent Default IGP metric: 10
Default Delay metric: 10
Operator-defined custom IGP algorithm 5 1 2

leveraging dedicated Prefix-SIDs set
8 3
7
Example:
Operator configure pref-SID 16004 associated to
Loopback 0 6 7 4 Loopback0
IGP: 100 IGP: 100 Default Algo 0
Prefix SID: 16004
Operator defines Flex-Algo 128 as “minimize delay Metric = IGP
metric”
5 1 2
Dedicated Prefix SID flex-algo 128 17004
For each destination two different SIDs are 8 3
7
installed in FIB
Loopback0
6 D: 1
7 D: 1
4 Algo 128
Prefix SID: 17004
Metric = Delay
5 1 2
router 4
router isis wan

is-type level-2-only
8 3
7
net 49.0001.0000.0000.4444.00
flex-algo 128
6 7 4 Loopback0
IGP: 100 IGP: 100 Default Algo 0
metric-type delay
Prefix SID: 16004
advertise-definition
Metric = IGP
interface Loopback0
5 1 2
passive
prefix-sid absolute 16004 8 3
7
prefix-sid algorithm 128 absolute 17004
Loopback0
6 Delay: 1
7 Delay: 1
4 Algo 128
Prefix SID: 17004
Metric = Delay
Flex Algo can be used also to build 5 1 2

virtual topologies
8 3
7
Excluding Nodes
• Node is not participating in a flex Algo
6 7 4 Loopback0
IGP: 100 IGP: 100
• Excluding (including) Links Default Algo 0
Prefix SID: 16004
Metric = IGP
• E.g. Only high bw links
5 1 2
• E.g Only macsec links
• E.g Plane A – Plane B 3
7
• Done via link affinity exclusion/inclusion
Loopback0
6 7 4 Algo 128
IGP: 100 IGP: 100 Prefix SID: 17004
Metric = Delay
Flex Algo properties
One single SID even for complex intent

e.g. Low Latency, exclude/include affinity.
Protected path stays in Flex Algo virtual topology

TI-LFA aware
Segment
Routing Traffic
Engineering
Traffic Engineering with Segment Routing
Source-Based routing – State only at ingress PE

Segment
• Supports constraint-based routing
Routing
• Supports centralized admission control
Uses existing ISIS / OSPF extensions to advertise link
attributes
No RSVP-TE to establish LSPs
ECMP aware
Supports unequal load balance
NO STATE in the network: Scaling, Programming Efficiency
TE LSP
MPLS LFIB with Segment Routing
LFIB populated by IGP (ISIS / OSPF) PE
PE
More efficient label allocation than LDP
PE PE
Source base routing: no state in P nodes PE

P
PE
PE PE
Forwarding table remains constant

(Nodes + Adjacencies) regardless of number of paths In Out Out
Label Label Interface
L1 L1 Intf1
Network
Node L2 L2 Intf1 Forwarding
Segment Ids … … … table remains
L8 L8 Intf4 constant
L9 L9 Intf2
Node L10 Pop Intf2
Adjacency … … …
Segment Ids
Ln Pop Intf5
Circuit Optimization vs SR Optimization
Intent: path to 3 avoid links RED
2 2
1 3 1 3
5 5 pkt
4 7 16007 4 7
6 16003 16003
6
pkt pkt
8 9 8 9
Classic RSVP-TE algorithm is not efficient!!

SR-native algo is needed
Need to specify all hops: {4, 5, 7, 3}
!No more circuit!
No ECMP,
Recognized Innovation - Sigcomm 2015
With SR we can do much better
Old algorithm and technology , ATM optimized
SID List: {7, 3}
ECMP, minimized SID list, IP-optimized
Low- Delay path
Metric Type Delay
D:1500 D:1500
I:10 I:10 segment-routing
SID-list:
<16005, 16004, 16003>
1 2 3 traffic-eng
D:800
policy POLICY1
I:10
D:800 D:800 color 20 end-point ipv4 1.1.1.3
I:10 I:10 candidate-paths
5 4 preference 100
D:2200 dynamic
I:10 metric
Node1
D:2000 type delay
I:10 6
• Head-end computes a SID-list that expresses the shortest-path according to the selected
metric delay
SR Policy – configuration example
On Node1:
User-defined
segment-routing
name
traffic-eng
policy POLICY1 Color and End-point
color 20 end-point ipv4 1.1.1.4
binding-sid mpls 1000 Binding-SID
candidate-paths
➊ preference 100 20
dynamic
metric type te ➋ 2 3
Candidate Paths
constraints
affinity 1 4
exclude-any color red
! ➊ 6 5
➋ preference 200
explicit segment-list SIDLIST1 Default link metric: 10
!
segment-list name SIDLIST1 segment-routing
index 10 mpls label 16002 traffic-eng
index 20 mpls label 30203 affinity-map
index 30 mpls label 16004 color red bit-position 0
WECMP example
On Node1:
segment-routing
traffic-eng
policy POLICY1
binding-sid mpls 1000
candidate-paths Path preference
preference 200 200
20
explicit segment-list SIDLIST1
weight 1
Explicit SID-list1, 2 3
! Weight 1
explicit segment-list SIDLIST2
Explicit SID-list2, 1 4
weight 4
!
Weight 4
segment-list name SIDLIST1 6 5
index 10 mpls label 16002 Default link metric: 10
index 20 mpls label 30203 SID-list1
index 30 mpls label 16004 FIB @ head-end Node1
! Incoming label: 1000
segment-list name SIDLIST2 Action:pop and push <16002, 30203, 16004> (20%)
index 10 address ipv4 1.1.1.4 SID-list2 push <16004> (80%)
Automated
Steering
Automated Steering
How to inject traffic into a Traffic Engineering LSP
• Traditional ways are complex to be configured and managed and

often have performance impact (e.g. Policy Based Tunnel Selection
PBTS)
• With Segment Routing steering traffic into a Traffic Engeneering
policy is completely automated for BGP signaled services.
SR Policy Identification
• The tunnel Interface construct has been replaced by the SR Policy
• In SR there is no tunnel anymore, the policy is programmed only at the headend.
• An SR Policy is uniquely identified by end-point and color:

End-point: the destination of the SR Policy
Color: a numerical value to differentiate multiple SRTE Policies between the same
pair of nodes.
segment-routing
2 4
traffic-eng
policy POLICY1
SR Policy
candidate-paths
Color 128 1 † 6 preference 100
dynamic
End-point: 6 metric
type latency
3 5
SR Policy Color
For the same source/end-point different colors for different SLA
• E.g Green = Low Latency and Blue = High Bandwidth
• SRTE Policy Color go hand in hand with BGP Ext. Community Color
• Extended Community Color is specified in RFC 5512
2 4
Color 128, 6
1 6
†
Color 130, 6
3 5
Segment Routing - Automated Steering (AS)
Steer traffic into SR Policy based on Next Hop BGP and Color
vrf 1234
• BGP signaled routes (e.g. IPv4, IPv6, VPNv4, EVPN):

import route-target
3450:3450
End-pont = BGP Next Hop

!
• export route-policy SET_COLOR_128_130
export route-target
• Route color = SR policy color 3450:3450
• Automated steering into the Policy RR

10.10.10.0/24 NH=6 color=128 (GREEN)
20.20.20.0/24 NH=6 color=130 (BLUE)
Route policy to
advertise routes with
Destination
2 4 specific color
10.10.10.0/24 – NH 6 10.10.10.0/24
1 † 6 20.20.20.0/24
20.20.20.0/24 - NH 6
3 5
Segment Routing – ODN (+AS)
Setup SRTE policy to the BGP NH On Demand
• End-pont = BGP Next Hop color GREEN (128)

• No existing policy but ODN template defined
RR
10.10.10.0/24 NH=6 color=128 (GREEN)
segment-routing
20.20.20.0/24 NH=6 color=130 (BLUE)
traffic-eng
on-demand color 128
preference 100 Route policy to
dynamic advertise routes with
metric type latency 2 4 specific color
10.10.10.0/24
10.10.10.0/24 – color 128 NH 6 1 † 6 20.20.20.0/24
3 5
Per Flow Automated Steering (AS)
Steer traffic into SR Policy based on Destination – Color – DSCP
• End-pont = BGP Next Hop

• Route color = SR policy color
• Different path for the same color/destination RR
10.10.10.0/24 NH=6 color=RED
• Based on QoS (DSCP)
• Source address
Route policy to
• etc advertise routes with
2 4 specific color
Destination Class Green

10.10.10.0/24
10.10.10.0/24 – NH 6 MQC* Class BLU 1 † 6
Class 1 Green
Class 2 BLU
Match To Class
3 5
*MQC Modular QoS CLI
Mapping
Other Steering mechanism
• Preferred path: for L2 services. The pseudowire of the L2 service is mapped over a SRTE
policy (and not following the IGP path)
• Static Route: traffic towards specific route (or Next hop) will be steered over the policy
• Autoroute include: IGP shortcut – the IGP will use the policy as a preferred link between
headend and tail-end of the policy
• Color-Only Automated Steering - is a traffic steering mechanism where a policy is created
with given color, regardless of the endpoint.
• Using Binding Segments - using BSID to stitch SRTE policies
More info at : https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/segment-routing/77x/b-segment-routing-cg-ncs5500-77x/configure-sr-te-policies.html#id_128905
SR-TE Use
Cases
Inter domain
connectivity
(Including SLA)
Crossing IGP borders
• With a stack of labels through border routers
• Source Based Routing: only ingress node need to be programmed
• This means all other nodes needs only to support basic SR forwarding
• Not only best effort connectivity!

16003
Domain1 Domain2 Domain3
16005 L1 L2 L1
16006
best effort
pkt S 2 4
3
16005
5 6 pkt
16006
16006 pkt
pkt
SR-PCE Receives & Combines Multiple
Topologies
• Each domain feeds its
topology to the SR-PCE via BGP-LS
• SR-PCE combines the different
topologies to compute paths across entire
topology SR
PCE
BGP-LS
1 2 4
3 5 6
L1 L2 L1
SR-PCE Receives & Combines Multiple
Topologies
• SR-PCE is IOS-XR based stateful Path Computation Element (PCE)
• PCEP session between SR-PCE and Headend nodes for centralized computation
• Fundamentally Distributed (RR-like Deployment)
• Multi Domain SR
PCE
• Also supports RSVP-TE
PCEP
1 2 4
3 5 6
L1 L2 L1
End-to-End
Automation
SR Path Computation Element (SR-PCE)
Distributed SRTE path computation Cisco Crosswork Custom Custom
Optimization Engine APP APP
Distributed Computation mode – SR-TE Head-End

Visibility is limited to its own IGP domain
Single / Native SR
REST API algorithms
Multi-Domain
Centralized SRTE path computation Topology
Topo
Built on Virtual ASR9000 IOS-XR platform Compute
DB
SR-PCE runs on
virtual or physical
Multi-Domain SRTE Visibility IOS-XR node
Centralized SR-PCE for Multi-Domain Topology view Collect Deploy
Integration with Applications
North-bound APIs for topology/deployment PCEP
Delivers across the unified SR Fabric the SLA requested by the IGP
BGP-LS
service
Benefits
Simplicity and Automation Access Metro Core Metro Data Center
End-to-End network topology awareness
SLA-aware path computation across network 1 2 3 4
domains Aggregation
Interested? Segment Routing Traffic Engineering (SRTE) on segment-routing.net

Crosswork Network Controller (CNC)
Integrated solution for deploying and operating IP transport networks
Crosswork Network Controller Use Case Description

C
Common UI & API
Service Provision L2VPN & L3VPN
Provisioning services with transport intent
Optimization Engine Active Topology &
Inventory
Cisco NSO +
Service
Intent-Oriented Provision segment routing traffic-
Real Time Network Core Function
Optimization inventory Packs Transport engineering policies for services
Provisioning with SLAs.
Model-based
Service & Device Bandwidth Tactically optimize the network
SR-PCE Crosswork Data
Provisioning
Gateway Optimization during times of congestion
Collect real-time performance

Real time
information and optimize the
network
network as needed to maintain
optimization
Multivendor, Multi-domain Physical and Virtual Infrastructure the SLA
Topology & Collect and expose information

Inventory about network and services
Circuit Style
SRTE
Transport Orientated Services
Private Line Emulation and Circuit Style SR
10GE/100GE Packet 10GE/100GE Packet

OC48/OC192 L2/L3 OC48/OC192 L2/L3
OTUk OTUk
FC-1G..32G
PLE
OTN
MPLS SR MPLS
DWDM DWDM
Path protected, co-routed, bi-directional
SR policy
Bandwidth reservation on links
3
(in PCE topology database)
1 Working candidate path
A Z
Protect candidate path

2
(pre-programmed)
End2end liveness
4 (STAMP loopback probes)
Why do Protection Schemes matter?
X
Path Protection A Z
pre-allocated bandwidth end2end
MPLS-TE FRR X
Local bypass protection, without bandwidth allocated A Z
Loop Free Alternate (LFA)

Post convergence path, without bandwidth allocated
X
A Z
Each scheme does require different capacity planning strategy !
Circuit Style LSP
End to End Liveness session for 1:1 protection
Probe
Sender Query Reflector
1.1.1.2 1.1.1.3 1.1.1.4 1.1.1.5
1 6
CE 2 PE 3 44 5 PE CE
Active path
Probe
Response
7 8
• Liveness probe is following the programmed path in forward and backward direction
• Protection switchover to standby path after liveness failure on the active path.
• Achieve below 50 msec traffic loss - detection and switchover time for forward and
backwards direction.
• E2E probe is also sent to the backup path to monitor availability of the backup path.
Transport Orientated Path Protection
Controller assisted
- Co routed forward-backwards
- Bandwidth bookkeeping
- Fast path failure detection
- Sub 50ms switchover
Cisco Network
Controller
SR-MPLS/SRv6 UNDERLAY
Both PLE and CS-SR Are ‘Open’
• PLE data plane

• https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple
• 4th revision introduced how to carry 200GE and 400GE
• Circuit-style SR policies
• Two drafts
— https://datatracker.ietf.org/doc/html/draft-schmutzer-pce-cs-sr-policy
— https://datatracker.ietf.org/doc/html/draft-sidor-pce-circuit-style-pcep-
extensions
• Presentation of both drafts at IETF113 triggered great interest and lead to
support from multiple vendors and customers
Conclusion
Simplicity Always Reduced Time to Deploy
Prevails
Simplicity reduces time to deploy
• 60% reduction in internal testing
(qualification) vs previous network
design
• 4x improvement for software upgrade
with fabric-style SP architectures
Better Productivity
Simplicity increases productivity
• 48% reduction in troubleshooting efforts
Segment Routing provides complete control vs previous network design
over the forwarding paths by combining simple
network instructions. It does not require any Reduced Capex
additional protocol. Indeed in some cases it Easy to scale Low End with support SR
• 60% reduction in CapEx by optimizing
removes unnecessary protocols simplifying the usage of feature-rich / higher-cost
your network platforms only where it is needed
• End to End without duplication inter
domain interconnections border
routers.
* Actual business impact of Segment Routing deployment done
by a large service provider in EMEA
Stay up to date with…
Segment Routing
www.segment-routing.net/
LinkedIn
www.linkedin.com/groups/8266623
Twitter
www.twitter.com/SegmentRouting
Facebook
www.facebook.com/SegmentRouting/
Segment Routing, Part I / II Textbooks

Available on Kindle and in paperback
Visit the World Of Solution SP Demo Center
- SR MPLS and SRv6 Network Slicing

- Green Routed Optical Networking
- Private Line Emulation and CS-SR
- Edge Cloud Infrastructure
- Public & Private Mobile IoT
- NaaS
Thank you

BRKSP 2551 1

Uploaded by

Document Informationclick to expand document information

Document Informationclick to expand document information

Copyright:

Available Formats

BRKSP 2551 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BRKSP 2551 1

Uploaded by

Copyright:

Available Formats

Introduction to

Alberto Donzelli, Principal Architect

Delayering Unified Infrastructure Horizontal Integration

Automation and Intent driven Virtualization

Legacy Central Office

L2VPN L3VPN VXLAN VNF VNF

End-to-end service provisioning is lengthy and complex

BGP signaled VPN L2/L3 VNF VNF

End-to-end service provisioning is simple

Compute Leaf Spine

Reference IETF drafts and RFCs examples

• Segment Routing Architecture RFC 8402

First SR-MPLS First SRv6

Americas EMEA APJC

585 474 205 2%

Routing protocols with SDN controller

Paths options Traffic Engineered path

Router to Router Router to Router

Global Segment 16006

No per-flow state is created

IS-IS or OSPF 24054

Push Swap Pop Pop

Payload Payload Payload Payload Payload

Payload Payload Payload Payload Payload

This ranges are reserved and no used by

24001 24004 32020 24005

16,000 Idx 0 16,000 Idx 0 16,000 Idx 0

Initial state: All nodes run LDP, not SR

Initial state: All nodes run LDP, not SR

Initial state: All nodes run LDP, not SR

Initial state: All nodes run LDP, not SR

Step3: LDP is removed from the nodes in SR Domain

100%-coverage 50-msec link, node, and SRLG protection

Calculate post-convergence SPT Packet to 8

• SPT with link R1R2 removed from topology

RP/0/0/CPU0:XR-1# sh mpls forwarding labels 16008

TI-LFA for link R1-R2 on R1 16008 A 8

RP/0/0/CPU0:XR-1#show isis fast-reroute summary

• TWAMP probe (rfc 5357)

ISIS (rfc 8570) and OSPF (rfc 7471) PM Query Packet

• BGP-LS (rfc 8571) Extended TE Link Delay

• Latency automatically included in IGP topology

Operator-defined custom IGP algorithm 5 1 2

router isis wan

Flex Algo can be used also to build 5 1 2

One single SID even for complex intent

Protected path stays in Flex Algo virtual topology

Source-Based routing – State only at ingress PE

Source base routing: no state in P nodes PE

Forwarding table remains constant

Classic RSVP-TE algorithm is not efficient!!

• Traditional ways are complex to be configured and managed and

• An SR Policy is uniquely identified by end-point and color:

• BGP signaled routes (e.g. IPv4, IPv6, VPNv4, EVPN):

End-pont = BGP Next Hop

• Route color = SR policy color 3450:3450

• Automated steering into the Policy RR