Segment Routing in Service Provider Network - Dejan Jaksic

Segment Routing in Service Provider networks
Dejan Jaksic, Systems Engineer

djaksic@cisco.com
Agenda
• Introduction to Segment Routing

• Control plane and Data plane
• Segment routing and LDP interworking
• Traffic protection using TI-LFA and SR-TE with use cases
• Sneak peak on SRv6
• Conclusion
19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia 3

Introduction to Segment Routing
SP Disruption: Complexity vs. Value
Application / Service / Customization
Revenues, Stickiness
OSI Reference
Model Traditional SP Cloud Scale SP
Application Complexity
Presentation
Value
Session
Transport
Network
Data-Link The complexity should
Physical Complexity be where the ROI is best
Complex Network
19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia
The 2 faces
The next wave of segment
What is segment routing? routing
An LS IGP protocol extension
An IP/MPLS architecture
bringing network
designed with SDN in mind
simplification/optimization
• No LDP
• Lighter protocol suite • Right balance between distributed
• Less adjacencies, less states to intelligence and centralized
maintain optimization and programming
• No IGP to LDP synchronization • SR-TE
• Eliminates delays in activating a path • Wide applications
• Topology independent fast reroute using • (SP, OTT/Web, GET) across
post convergence back up path (WAN, Metro/Agg, DC)
• 50 ms protection • MPLS and IPv6 dataplanes
• no microloops • SDN controller
• 100% coverage of network topologies
Easy troubleshooting
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
§ Segment: an identifier for any type of instruction
– forwarding or service
§ This presentation: IGP-based forwarding construct
Segment = Instructions such as

"go to node N using the shortest path”

Segment Routing
§ MPLS (SR MPLS): an ordered list of
segments is represented as a stack of
labels
– SR re-uses MPLS data plane without any
change (push, swap, pop operations) Control Plane IPv4 IPv6 IPv6
– 1 segment = 1 label
– a segment list = a label stack
§ IPv6 (SRv6): an ordered list of segments is Data Plane

represented as a routing extension header, MPLS IPv6
see 4.4 of RFC2460
– 1 segment = 1 address
– a segment list = an address list in the SRH
This session mostly focuses SRv6
§ IGP-based segments require minor on MPLS IPv4 data plane
extension to the existing link-state routing
protocols (OSPF and IS-IS) or BGP
Segment Routing Standardization
§ IETF standardization in SPRING working group Sample IETF Documents
Problem Statement and Requirements
§ First RFC document - RFC 7855 (May 2016) (RFC 7855)
§ Protocol extensions progressing in multiple Segment Routing Architecture

(draft-ietf-spring-segment-routing)
groups
IPv6 SPRING Use Cases
– IS-IS (draft-ietf-spring-ipv6-use-cases)
– OSPF
Segment Routing with MPLS data plane
– PCE (draft-ietf-spring-segment-routing-mpls)
– IDR Topology Independent Fast Reroute using Segment Routing
– 6MAN (draft-bashandy-rtgwg-segment-routing-ti-lfa)
– BESS IS-IS Extensions for Segment Routing
(draft-ietf-isis-segment-routing-extensions)
§ Broad vendor support OSPF Extensions for Segment Routing
(draft-ietf-ospf-segment-routing-extensions)
§ Several interop reports are available
PCEP Extensions for Segment Routing
§ Strong customer adoption and support (draft-ietf-pce-segment-routing)
– WEB, SP, Enterprise

Close to 40 IETF drafts in progress
19 - 21 March 2018 | Cisco Connect |
Over 75% have a Cisco implementation
Rovinj, Croatia
Two dataplane instantiations
§ MPLS
– leverage the mature MPLS HW with only SW upgrade
– 1 segment = 1 label
– a segment list = a label stack
§ IPv6
– leverages RFC2460 provision for source routing extension header
– 1 segment = 1 address
– a segment list = an address list in the SRH

Simple and Efficient Transport of
MPLS services
§ Efficient packet networks leverage ECMP-

aware shortest-path!
– Prefix segment! A B
§ Simplicity
PE1 PE2
– one less protocol to operate
– No complex LDP/ISIS synchronization to M N
troubleshoot
All VPN services ride on the prefix segment

to PE2

IGP Segment Identifiers
Prefix/Node SID Adjacency SID
65 65
65 B C D 9101 B C D
65 9105
A Z A 9107 Z
N O P N O P
9105
§ Globally significant within SR domain 9103

§ Locally significant to node allocating it
§ Any node in SR domain can execute the
associated instruction § Node processes SID and switches packet
towards adjacency
§ All nodes switch packet towards
prefix/node via shortest path § Only originating node can execute the
associated instruction
§ Advertised as a relative (index) value
§ Advertised as an absolute value
§ Make use of a per-node reserved block
(SR Global Block or SRGB) 19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia
IGP Prefix Segment
16004
§ Shortest-path to the IGP prefix
– Equal Cost MultiPath (ECMP)-aware
§ Global Segment in SR domain
1 2
16004
§ All nodes switch packet towards 16004 16004
prefix/node via shortest path 16004

5
§ Label = 16000 + Index 16004
– Advertised as index
§ Distributed by ISIS/OSPF
3 4
1.1.1.4/32
16004
All nodes use default SRGB
16,000 – 23,999

IGP Adjacency Segment
§ Forward on the IGP adjacency
§ Local Segment
1 2
§ Only originating node can execute
the associated instruction
Adj to 2
5
§ Advertised as label value 24042
§ Distributed by ISIS/OSPF
Adj to 5
3 4 24045
24043
Adj to 3

All nodes use default SRGB
16,000 – 23,999
Combining IGP Segments 16004

24045
§ Steer traffic on any path through the network Packet to 5
§ Path is specified by a stack of labels

1 2
§ No path is signaled
§ No per-flow state is created
5
§ Single protocol: IS-IS or OSPF 24045
Packet to 5
3 4
16004 24045

Anycast Prefix Segments
§ Anycast prefix: same prefix advertised by multiple nodes (identifies
group)
§ Anycast prefix-SID: prefix-SID associated with anycast prefix
§ Same prefix-SID for the same prefix!
§ Traffic is forwarded to one of the Anycast prefix-SIDs based on best IGP
path
§ If primary node fails, traffic is auto re-routed to the other node

BGP Prefix Segment
§ Shortest-path to the
BGP prefix
§ Global Segment
16001
§ 16000 + Index 12
– Index of NodeX = X is 10
2 4
used for illustrative
purposes 1
7
§ Signaled by BGP 13
3 6 5
11
14
DC (BGP-SR) WAN (IGP-SR) PEER

Control plane and Data plane
MPLS Control and Forwarding Operation with Segment Routing
Services
MP-BGP
No changes to
IPv4 IPv6
PE1 PE2 IPv4 IPv6
VPN VPN
VPWS VPLS control or
forwarding plane
Packet
Transport LDP RSVP Static BGP IS-IS OSPF IGP or BGP label
distribution for
PE1 IGP PE2
IPv4 and IPv6.
MPLS Forwarding
Forwarding plane
remains the same

SR enabled node
SID Encoding
SRGB = [ 16,000 – 23,999 ] – Advertised as base = 16,000, range = 8,000
Prefix SID = 16,001 – Advertised as Prefix SID Index = 1
Adjacency SID = 24000 – Advertised as Adjacency SID = 24000
§ Prefix SID
– Label form SR Global Block (SRGB)
– SRGB advertised within IGP via TLV
– In the configuration, Prefix-SID can be configured as an absolute value or an index
– In the protocol advertisement, Prefix-SID is always encoded as a globally unique index
Index represents an offset from SRGB base, zero-based numbering, i.e. 0 is 1st index
E.g. index 1 à SID is 16,000 + 1 = 16,001
§ Adjacency SID
– Locally significant
– Automatically allocated by the IGP for each adjacency
– Always encoded as an absolute (i.e. not indexed) value

SR IS-IS Control Plane Summary
• IPv4 and IPv6 control plane

• Level 1, level 2 and multi-level routing
• Prefix Segment ID (Prefix-SID) for host prefixes on loopback interfaces
• Adjacency Segment IDs (Adj-SIDs) for adjacencies
• Prefix-to-SID mapping advertisements (mapping server)
• MPLS penultimate hop popping (PHP) and explicit-null signaling

SID index 1
1.1.1.2 1.1.1.1
IS-IS Configuration – Example

1.1.1.4 1.1.1.6
router isis 1 DIS
address-family ipv4 unicast Wide metrics
metric-style wide
enable SR IPv4 control plane and
segment-routing mpls
SR MPLS data plane on all ipv4
!
interfaces in this IS-IS instance
address-family ipv6 unicast
metric-style wide Wide metrics
! enable SR IPv6 control plane and
interface Loopback0 SR MPLS data plane on all ipv6
passive interfaces in this IS-IS instance
prefix-sid absolute 16001 Ipv4 Prefix-SID value for
! loopback0
prefix-sid absolute 20001 Ipv6 Prefix-SID value for
! loopback0
!

SR OSPF Control Plane Summary
• OSPFv2 control plane

• Multi-area
• IPv4 Prefix Segment ID (Prefix-SID) for host prefixes on loopback
interfaces
• Adjacency Segment ID (Adj-SIDs) for adjacencies
• Prefix-to-SID mapping advertisements (mapping server)
• MPLS penultimate hop popping (PHP) and explicit-null signaling

SID index 1
1.1.1.2 1.1.1.1 1.1.1.4
OSPF Configuration Example

router ospf 1 1.1.1.5 1.1.1.3
DR
router-id 1.1.1.1 Enable SR on all areas
area 0
interface Loopback0
passive enable
prefix-sid absolute 16001 Prefix-SID for loopback0
!
!
!

MPLS Data Plane Operation (labeled)
Prefix SID Adjacency SID
SRGB [16,000 – 23,999 ] SRGB [16,000 – 23,999 ]
Adjacency
SID = X
Swap Pop
X
X X Y Y
Payload Payload Payload Payload
§ Packet forwarded along IGP shortest path (ECMP) § Packet forwarded along IGP adjacency
§ Swap operation performed on input label § Pop operation performed on input label
§ Same top label if same/similar SRGB § Top labels will likely differ
§ PHP if signaled by egress LSR
§ Penultimate hop always pops last adjacency SID
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 Data Plane Operation (Adjacency SIDs)
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

BRKRST-2124 27
Co-existence with other MPLS label distribution protocols
§ The MPLS architecture permits concurrent usage of multiple label
distribution protocols
– LDP, RSVP-TE, … and SR control plane can co-exist without interaction
§ Each node’s Label Manager

– Reserves a label range (SRGB) for SR control-plane
– Ensures that all dynamic labels are outside the SRGB block
– Ensures that a dynamic label is uniquely allocated
§ Each LSR must ensure that it can uniquely interpret its incoming labels
– Adjacency segment: locally unique label allocated by the label manager
– Prefix segment: operator ensures the unique allocation of each label within the allocated
SRGB
§ If both an SR and LDP label exist for a prefix, LDP is preferred by default,
but SR can be configured as preferred
MPLS-to-MPLS – label switching
§ MPLS-to-MPLS LDP and SR entries co-exist

§ These entries are indexed on a label
§ The incoming labels handled by LDP (or other label distribution protocols) and
SR are unique
§ Multiple MPLS-to-MPLS entries can be programmed for the same prefix
§ cfr. LSP midpoint cross connect
1.1.1.1/32
LDP: in 24003 – out 24005
SR: in 16004 – out 16004
24003 24005
LDP Payload Payload
16004 16004
SR Payload Payload
MPLS-to-IP – label disposition
§ MPLS-to-IP LDP and SR entries co-exist

§ These entries are indexed on a label
§ The incoming labels handled by LDP and SR (or other label distribution
protocols) are unique
§ Multiple MPLS-to-IP entries can be programmed for the same prefix
1.1.1.1/32
LDP: in 24005 – out pop
SR: in 16004 – out pop
24005
LDP Payload Payload
16004
SR Payload Payload
IP-to-MPLS label imposition
§ The preference of SR labels over LDP labels for IP-to-MPLS entries can
be configured in IS-IS/OSPF
§ If both labels are available, the preference setting indicates which one to
install in the FIB
§ Default: prefer LDP
§ See SR/LDP coexistence and interworking section
router isis 1
segment-routing mpls sr-prefer

MPLS LFIB with Segment Routing
§ LFIB populated by IGP (ISIS / PE PE
OSPF) PE PE
§ Forwarding table remains constant PE

P
PE
(Nodes + Adjacencies) regardless PE PE

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

Segment Routing and LDP interworking
LDP to SR
§ When a node is LDP capable but its next-
hop along the SPT to the destination is not LDP SR
LDP capable LDP SR
– no LDP outgoing label
§ In this case, the LDP LSP is connected to

the prefix segment A Z
§ C installs the following LDP-to-SR FIB B C D 16066

entry:
– incoming label: label bound by LDP for FEC Z
– outgoing label: prefix segment bound to Z
– outgoing interface: D Out Label (LDP), Input Label Out Label
Prefix
Interface (LDP) (SID), Interface
§ This entry is derived automatically at the Z 16, 0 32 16066, 1
routing layer, no config needed!

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia 35
SR to LDP
§ When a node is SR capable but its

next-hop along the SPT to the SR LDP
destination is not SR capable SR LDP
– no SR outgoing label available
§ In this case, the prefix segment is A Z
connected to the LDP LSP
B C D
– Any node on the SR/LDP border installs
SR-to-LDP FIB entry(ies)
Out Label (SID), Input Label Out Label (LDP),

Prefix
Interface (SID) Interface
Z ?, 0 ? 16, 1

Mapping Server
§ A wants to send traffic to Z, but
– Z is not SR-capable, Z does not advertise any prefix-SID
à which label does A have to use? Z ó 16066
§ The Mapping Server advertises the SID mappings
for the non-SR routers (on behalf of non-SR capable
nodes)
A Z(16066) Z
– for example, it advertises that Z is 16066
§ A and B install a normal SR prefix segment for B C D
16066
§ C realizes that its next hop along the SPT to Z is not
SR capable hence C installs an SR-to-LDP FIB entry
– incoming label: prefix-SID bound to Z (16066)
– outgoing label: LDP binding from D for FEC Z Out Label (SID), Input Label Out Label (LDP),
Prefix
Interface (SID) Interface
– outgoing interface: D
Z 16066 16066 16, 1
§ A sends a frame to Z with a single label: 16066
§ Note: Mapping server is a control plane mechanism
and doesn’t have to be in the data path
Traffic protection TI-LFA and SR-TE with use cases
Simple and Efficient Transport of MPLS services
16002
§ No change to
service vpn
configuration Packet to 8
– MPLS services MP-BGP
ride on the prefix vpn
segments Packet to 8 3 4 Packet to 8
CE PE PE CE
§ Simple: IGP-only
– One less protocol 7 1 2 8
to operate
1.1.1.2/32
– No LDP, no Prefix-SID 16002 10.0.0.0/30
2001::a00:0/126
5 6
RSVP-TE
16002
vrf RED SR Domain vrf RED
vpn
Packet to 8
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
§ Prevents transient congestion and suboptimal routing

– leverages the post-convergence path, planned to carry the traffic
§ Incremental deployment
– also protects LDP and unlabeled traffic

Topology Independent LFA – Implementation
§ Leverages existing and proven LFA technology

– P space: set of nodes reachable from node S (PLR) without using protected link L
– Q space: set of nodes that can reach destination D without using protected link L
§ Enforcing loop-freeness on post-convergence path

– Where can I release the packet?
At the intersection between the post-convergence shortest path and the Q space
– How do I reach the release point?
By chaining intermediate segments that are assessed to be loop-free

Explicit Post-Convergence Path – Example
A B C
§ Protecting link D-E on node D
§ LFA: D switches all traffic
destined to PE2 towards the F
D E
edge node PE1
à an edge node and edge links are
used to protect the failure of a core 100 100 100 100
link
§ TI-LFA: D switches all traffic PE2
PE1
destined to PE2 via core links Default metric: 10

TI-LFA – Single-Segment Example
§ TI-LFA for link R1R2 on R1 A Z
§ Calculate P and Q spaces Packet to Z Packet to Z

– They overlap in this case R1 R2
§ Calculate post-convergence SPT P-space
§ Find PQ node on post-convergence prefix-SID(R4) R5

prefix-SID(Z)
SPT prefix-SID(Z)
Packet to Z
Packet to Z
§ R1 will push the prefix-SID of R4 on R4 R3
the backup path

Q-space
Default metric:10

TI-LFA – Double-Segment Example
§ TI-LFA for link R1R2 on R1 A Z
§ Calculate P and Q spaces Packet to Z Packet to Z
§ Calculate post-convergence SPT R1 R2
§ Find Q and adjacent P node on post- prefix-SID(R4)

adj-SID(R4-R3)
convergence SPT prefix-SID(Z)
R5
prefix-SID(Z)
Packet to Z
§ R1 will push the prefix-SID of R4 and Packet to Z
the adj-SID of R4-R3 link on the R4 R3

1000
backup path
P-space Q-space
adj-SID(R4-R3)
Default metric:10
prefix-SID(Z)
Packet to Z

Explicit Post-Convergence Path
Computation leverages proven and existing LFA technology
intersection of post-convergence SPT with P and Q spaces
Number of Segments to form the Repair Tunnel
Symmetric network, link protection: Proven: <= 2 segments to get into Q space
Asymmetric network or node protection:
No theoretical bound
In reality, as we already saw for RLFA, things are much simpler !
Orange use-case in practice:
100% link protection
100% use <= 2 segments
100% node protection (<=4 segments)
99.72% use <= 2 segments
0.24% use 3 segments
0.04% use 4 segments

Traffic Engineering with Segment Routing
§ Provides explicit routing

§ Supports constraint-based routing Segment
Routing
§ Supports centralized admission control
§ Uses existing ISIS / OSPF extensions to
advertise link attributes
§ No RSVP-TE to establish LSPs
§ Supports ECMP!
TE LSP

Circuit Optimization RSVP vs SR Optimization
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 Algo 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
Old algorithm and technology , ATM optimized
With SR we can do much better SID List: {7, 3}
ECMP, minimized SID list, IP-optimized

SR –TE Binding SID
2 § Binding Segment is a fundamental building block
of SRTE
24008 § The Binding Segment is a local segment

1 3 – Has local significance
pkt 5
160074 pkt § A Binding-Segment ID identifies a SRTE Policy
7
16003 16003 – Each SRTE Policy is associated 1-for-1 with a
6 Binding-SID
pkt pkt
§ Packets received with Binding-SID as top label are
8 9
steered into the SRTE Policy associated with the
Binding-SID
– Binding-SID label is popped, SRTE Policy’s SID list
is pushed
§ Binding SID can be automatically assigned or
statically configured as part of the SRTE policy

Low-Latency segment-routing
Node1
traffic-eng
Use-Case policy POLICY1
color 20 end-point ipv4 1.1.1.3
T:15 T:15
candidate-paths
I:10 I:10
1 2 3 preference 100
T:8 dynamic mpls
SID-list: <16005, 16004, 16003> I:10 metric
T:10 type te
I:30
5 4
Default IGP link metric: I:10

Default TE link metric: T:10 6
§ Head-end computes a SID-list that expresses the shortest-path according to the

selected metric

BRKRST-2124 49
Service Disjointness from the same head-end
Use-Case
segment-routing
Node1
traffic-eng
policy POLICY1
POLICY1 SID-list: 2 I:100
3 color 20 end-point ipv4 1.1.1.7
<16002, 30203, 16007>
candidate-paths
preference 100
dynamic mpls
1 4 7 metric
type igp
POLICY2 SID-list: association group 1 type node
<16005, 16006, 16007> !
5 I:100
6 policy POLICY2
Default IGP link metric: I:10 candidate-paths
preference 100
dynamic mpls
§ The head-end computes two, metric
type igp
disjoint paths association group 1 type node

Link Delay Measurement Protocol
(phase1) One Way Delay = (T2 – T1)
(future) Two-Way Delay
• PTP
– Accurate time-stamp
TX Timestamp T1 RX Timestamp T2
• MPLS PM Local-end Remote-end

– using GAL/Gach defined in RFC 6374
PM Query Packet 99.2.1.2
• IGP and BGP support:

– Extended TE Link Delay Metrics will be 99.1.2.1 PM Response Packet
supported in ISIS (RFC 7810) and OSPF (RFC
7471)
XTC (PCE) view
– BGP-LS (draft-ietf-idr-te-pm-bgp) Extended TE Link[0]: local address 99.1.2.1, remote address 99.2.1.2
Link Delay Metrics Local node:
ISIS system ID: 0000.0000.6666 level-2 ASN: 64002
– Two-way delay Remote node:
TE router ID: 5.5.5.5
Host name: Napoli-5
ISIS system ID: 0000.0000.5555 level-2 ASN: 64002
• No additional configuration in ISIS/OSPF/BGP- Metric: IGP 1, TE 1,Delay 6000
Bandwidth: Total 125000000, Reservable 0
IS : Latency automatically flooded Adj SID: 24005 (protected) 24004 (unprotected)
Excluded from CSPF: no
Reverse link exists: yes

Different VPNs need different underlay SLA
I: 50
2 4
1 CE Basic VPN should
D: 15
use lowest cost
6 5 underlay path
IGP cost 30
Default IGP cost: I:10 Objective:
Default Delay cost: D:10 operationalize this
service for simplicity,
scale and performance
TE cost 20
I: 50
2 4
Premium VPN
1 CE should use lowest
D: 15 delay path
6 5
Default IGP cost: I:10

Default Delay cost: D:10
On-Demand SR Policy work-flow
Automatic LSP setup and steering
➎
router bgp 1
➌ BGP: 20/8 via PE4
neighbor 1.1.1.10 VPN-LABEL: 99999
➋ BGP: 20/8 via PE4
Low-Delay (color 20)
address-family vpnv4 unicast RR VPN-LABEL: 99999
!
Low-Delay (color 20)
segment-routing
traffic-eng
on-demand color 20 ➍ PE4 with Low-
Delay (color 20)? I: 50 ➊ BGP: 20/8 via
preference 100
metric
SR Policy template 2 4 CE
Low-Delay (color 20) ➎ use template
type delay
color 20 1 CE 20/8
➏ à SID-list D: 15
<16002, 30204>
6 5
Default IGP cost: I:10

Default Delay cost: D:10

Automated performant steering
➐➑ ➌ BGP: 20/8 via PE4
VPN-LABEL: 99999
➋ BGP: 20/8 via PE4
Low-latency (color 20)
RR VPN-LABEL: 99999
Low-latency (color 20)
Low Latency to PE4

➍ PE4 with Low-
latency (color 20)? ➐ I: 50 ➊ BGP: 20/8 via
Automatically, the service route 2 4 CE
resolves on the Binding SID (4001) of ➎ use template
color 20 1 CE 20/8
the SR Policy it requires
➏ à SID-list L: 15
<16002, 30204>
6 5
Simplicity and Performance
➐ instantiate
No route-policy required. No complex SR Policy Default IGP cost: I:10
PBR to configure, no PBR BSID 4001 Default Latency cost: L:10
performance tax ➑ Install in FIB 20/8

via BSID label 4001
A service head-end automatically instantiates an SR Policy to a BGP next-hop when required (on-demand)
Automatically steering the BGP traffic into this SR Policy
Crossing the AS border: BGP Peering Segment
AS1 30024 AS6

2 4 6.1.1.6/32
30024 18006
18006
1 10 11 pkt 6
pkt
16002 pkt
30024 3 5
18006
pkt
§ “Pop and Forward to the BGP peer”is missing?

What
§ Local Segment – like an adjacency SID external to the IGP
How do I get topology info of external domains?
– Dynamically allocated but persistent
XR Transport Controller (XTC)
• An IOS XR-powered Stateful Path

Computation Element (PCE) SR PCE
• Multi-Domain topology Collection North-Bound API

• Real-time reactive feed Multi-Domain
Computation
Topology
• Computation
• Native SR-TE algorithms backed by
extensive scientific research
“Collection” “Deployment”
BGP-LS PCEP/BGP-SRTE
ISIS / OSPF

XTC Receives & Consolidates Multiple Topologies from
multiple domains
§ Each domain feeds its
Domain1 Domain2 Domain3
A BR5
topology to XTC via BGP-LS BR1 BR1 BR3 BR3 BR5
BR2 BR2 BR4 BR4 BR6 BR6 Z

§ XTC combines the different
topologies to compute
paths across entire topology XTC
Domain1 Domain2 Domain3
A BR1 BR3 BR5
Peering
links
BR2 BR4 BR6 Z
BGP-LS
XTC = XR Transport Controller 19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia
Service Disjointness segment-routing
Node1
traffic-eng
policy POLICY1
Intra and inter domain color 20 end-point ipv4 1.1.1.3
candidate-paths
preference 100
XTC XTC dynamic mpls pce
metric
type igp
SID-list:
1 I:100
2 I:100
3 association group 1 type node
{30102, 30203} segment-routing
Node6
traffic-eng
5 4
7 policy POLICY2
candidate-paths
preference 100
SID-list:
6 I:100
7 I:100
8 dynamic mpls pce
metric
{16007, 16008} type igp
Default IGP link metric: I:10 association group 1 type node
§ Two dynamic paths between two different pairs of (head-end, end-point) must
be disjoint from each other

Path Computation
Distributed or Centralized ?
Policy Single-Domain Multi-Domain
Reachability IGP’s Centralized
Low Latency Distributed or Centralized Centralized
Disjoint from same node Distributed or Centralized Centralized
Disjoint from different node Centralized Centralized
Avoiding resources Distributed or Centralized Centralized
Capacity optimization Centralized Centralized
Multi Layer Centralized Centralized

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

SR IGP Flex Algo = “TE inside IGP” J
• Complements the SRTE solution by adding new Prefix-Segments with specific

optimization objective and constraints:
minimize igp-metric or delay or te-metric (links delay also option)
avoid SRLG or affinity
• Leverages the SRTE benefits of simplicity and automation
Automated sub-50msec FRR (TILFA)
On-Demand Policy (ODN)
Automated Steering (AS)
• Include or exclude multiple links from IGP topology – we treat single network as
multiple networks with different constraints and topologies
• Flex Algo can be defined per operator per use case:

• Operator1 defines Flex-Algo 128 as “minimize IGP metric and avoid link-affinity “green”
• Operator2 defines Flex-Algo 128 as “minimize delay metric and avoid link-affinity “blue
• We announce Prefix SID Per Flex Algo to other nodes in SR domain
SR-TE
§ Simple, Automated and Scalable

– No state in the network: state in the packet header
– No tunnel interface: “SR Policy”
– No head-end a-priori configuration: on-demand policy instantiation
– No head-end a-priori steering: automated steering (on demand NH)
§ Multi-Domain
– XR Traffic Controller (XTC) for compute
§ Lots of Functionality and flexibility
– Designed with lead operators along their use-cases
– DEMOS:
https://www.youtube.com/watch?v=8mwhagiNv9s&list=PLcSD8Cbk0fFHTO4bnb3NC8pJk
a3_ZvoRY 19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia
Sneak peak on SRv6
Network instruction for Network as a Computer
Locator Function Args*
§ 128-bit SRv6 SID

– Locator: routed to the node performing the function
– Function: any possible function – it defines action to be performed on the node
either local to NPU or app in VM/Container
– Arguments: optional argument bits to be used only by that SID
– Flexible bit-length selection

SRv6 Header
TAG
Segments Left
Locator 1 Function 1
Metadata TLV
Next header field: 43 → Routing
19 - 21 March 2018 | Cisco Routing Type
Connect | Rovinj, Croatia field: 4 → Segment routing
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
IPv6 SR Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next 43
Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Each segment is an IPv6 address |
| Destination Address
|
|
| |
Active Segment
• Segments are encoded in reverse order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Last segment index is 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Next Header | Hdr Ext Len | Routing 4 Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First segment index is First Segment | First Segment | Flags | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Active segment index is Segments Left |
Last Segment / Final
|
| Segment List[0] (128 bits Destination
IPv6 address) |
• Active Segment is copied in the |
|
@Segment List [0] |
|
Destination Address field of the IP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |
header .
.
Active Segment
...
.
.
. @Segment List [Segments Left] .
• Additional data can be stored in TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Security (HMAC), NFV metadata, … |

| First (128
Segment List[n-1] Segment
bits IPv6 address)
|
|
| @Segment List [First Segment] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
// Optional Type Length Value objects (variable) //
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Node
A B C D
A:: B:: C:: D::
• Source node is SRv6-capable IPv6 Hdr SA = A::, DA = B::

SR Hdr ( D::, C::, B:: ) SL=2
• SR Header (SRH) is created with Payload
Segment list in reversed order of the path

Segment List [ 0 ] is the LAST segment
Segment List [ 𝑛 − 1 ] is the FIRST segment
Segments Left is set to 𝑛 − 1 Version Traffic Class FlowLabel
Flow Label
First Segment is set to 𝑛 − 1
IPv6 Hdr
Payload Length Next = 43 Hop Limit
• IP DA is set to the first segment Source Address = A::
Destination Address = B::
• Packet is send according to the IP DA Next Header Len= 6 Type = 4 SL = 2
= Normal IPv6 forwarding First = 2 Flags RESERVED
SR Hdr
Segment List [ 0 ] = D::
Segment List [ 1 ] = C::
Segment List [ 2 ] = B::
19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia Payload
Non-SR Transit Node
A B C D
A:: B:: C:: D::
IPv6 Hdr SA = A::, DA = B::

SR Hdr ( D::, C::, B:: ) SL=2
Payload
• Plain IPv6 forwarding

• Solely based on IPv6 DA
• No SRH inspection or update

SR Segment Endpoints
• SR Endpoints: SR-capable nodes A
A::
B
B::
C
C::
D
D::
whose address is in the IP DA
IPv6 Hdr SA = A::, DA = C::
• SR Endpoints inspect the SRH and do: SR Hdr ( D::, C::, B:: ) SL=1
Payload
IF Segments Left > 0, THEN
Decrement Segments Left ( -1 )
Update DA with Segment List [ Segments Left ]
Forward according to the new IP DA
Version Traffic Class FlowLabel
Flow Label
IPv6 Hdr
Source Address = A::
Destination Address = C::
Next Header Len= 6 Type = 4 SL = 1
First = 2 Flags RESERVED
SR Hdr
Payload
SR Segment Endpoints
• SR Endpoints: SR-capable nodes A B C D
whose address is in the IP DA A:: B:: C:: D::
• SR Endpoints inspect the SRH and do: IPv6 Hdr SA = A::, DA = D::
SR Hdr ( D::, C::, B:: ) SL=0
IF Segments Left > 0, THEN Payload
Decrement Segments Left ( -1 )

Update DA with Segment List [ Segments Left ]
Forward according to the new IP DA
ELSE (Segments Left = 0)
Version Traffic Class FlowLabel
Flow Label
Remove the IP and SR header
IPv6 Hdr
Process the payload:
Source Address = A::
Inner IP: Lookup DA and forward
TCP / UDP: Send to socket Standard IPv6 processing Destination Address = D::
The final destination does
… Next Header Len= 6 Type = 4 SL = 0
not have to be SR-capable.
First = 2 Flags RESERVED
SR Hdr
19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia Payload
END – Default endpoint
• Default endpoint behavior (node segment)
Decrement Segments Left, update DA
Forward according to new DA
• Node B advertises prefix B::/64 (B::/64 is the SID locator)
Packets are forwarded to B along the default routes (shortest path)
• On B, the default endpoint behavior is associated with ID 0 (0 is the function)
• The SID corresponding to the default endpoint behavior on node B is B::0
IPv6 Hdr SA = A::, DA = B::0

B
SR Hdr (…,C::,B::0,…) SL=k
B:: /64
Payload C
IPv6 Hdr SA = A::, DA = C::

SR Hdr (…,C::,B::0,…) SL=k-1
Payload
Functoins Defined in Net Programming
• End Endpoint function The SRv6 instantiation of a prefix SID
• End.X Endpoint function with Layer-3 cross-connect The SRv6 instantiation of a Adj SID
• End.T Endpoint function with specific IPv6 table lookup
• End.DX2 Endpoint with decapsulation and Layer-2 cross-connect L2VPN use-case
• End.DX6 Endpoint with decapsulation and IPv6 cross-connect IPv6 L3VPN use (equivalent
of a per-CE VPN label)
• End.DX4 Endpoint with decapsulation and IPv4 cross-connect IPv4 L3VPN use (equivalent
of a per-CE VPN label)
• End.DT6 Endpoint with decapsulation and IPv6 table lookup IPv6 L3VPN use (equivalent
of a per-VRF VPN label)
• End.DT4 Endpoint with decapsulation and IPv4 table lookup IPv4 L3VPN use (equivalent
of a per-VRF VPN label)
• End.B6 Endpoint bound to an SRv6 policy SRv6 instantiation of a Binding SID
• End.B6.Encaps Endpoint bound to an SRv6 encapsulation Policy SRv6 instantiation of a
Binding SID
• End.BM Endpoint bound to an SR-MPLS Policy SRv6/SR-MPLS instantiation of a Binding SID
• End.S Endpoint in search of a target in table T
• End.AS Endpoint to SR-unaware APP via static proxy
• End.AM Endpoint to SR-unaware APP via masquerading

Conclusion
Industry at large backs up SR
Strong De-facto SDN Standardization Multi-vendor Open

customer Architecture IETF Consensus Source
adoption Linux, VPP
WEB, SP, ENT,
DC, Metro, WAN

Unified “Stateless Network as a Fabric” for Service Creation
Controller
Cloud Scale Networking
Central Office
Access
Metro Network Core and Peering Network Network Data Center
EVPN VNF VNF
VNF
Segment Routing
VNF
Compute Leaf Spine
Unified underlay and overlay E2E Cross-domain automation Transform the CO into a data center
networks with segment with model-driven programmability to enable distributed service delivery
routing and EVPN and streaming telemetry and speed up service creation
Simplify Automate Virtualize

Segment Routing Product Support
§ Platforms:
– IOS-XR (ASR9000, CRS-1/CRS-3, NCS5000, NCS5500, NCS6000)
– IOS-XE (ASR1000, CSR1000v, ASR903, ASR907, ASR920, ISR4400)
– NX-OS (N3K, N9K)
– Open Source (FD.io/VPP, Linux Kernel, ODL, ONOS, OpenWRT)
– PCE (WAN Automation Engine, XTC)

Segment Routing - summary
Data Plane
Path expressed in the packet Data
MPLS IPv6
Dynamic path (segment labels) (+ SR extension header)
Control Plane
Routing protocols with SDN controller

extensions (BGP LS, PCEP,
(IS-IS,OSPF, BGP) NETCONF/YANG)
Explicit path
Paths options
Dynamic Explicit
(STP computation) (expressed in the packet)

Conclusion
§ Simple routing extensions to implement source routing

§ Packet path determined by prepended segment identifiers (one or more)
§ Data plane agnostic (MPLS, IPv6)
§ SRTE integrated framework for SLA delivery
§ Increase network scalability and agility by reducing network state and
simplifying control plane – state is in the packet
§ Interworking with LDP, RSVP-TE... and SR control plane can co-exist
without interaction
§ Traffic protection with 100% coverage with more optimal routing
§ Multiple and evolving use cases
Stay Up-To-Date
amzn.com/B01I58LSUO
segment-routing.net
linkedin.com/groups/8266623
twitter.com/SegmentRouting
facebook.com/SegmentRouting/

Segment Routing in Service Provider Network - Dejan Jaksic

Uploaded by

Document Information

Original Description:

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

Segment Routing in Service Provider Network - Dejan Jaksic

Uploaded by

Copyright:

Available Formats

Segment Routing in Service Provider networks

Dejan Jaksic, Systems Engineer

• Introduction to Segment Routing

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia 3

Segment = Instructions such as

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

§ IPv6 (SRv6): an ordered list of segments is Data Plane

§ Protocol extensions progressing in multiple Segment Routing Architecture

– WEB, SP, Enterprise

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

§ Efficient packet networks leverage ECMP-

All VPN services ride on the prefix segment

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

§ Globally significant within SR domain 9103

prefix/node via shortest path 16004

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

Combining IGP Segments 16004

§ Path is specified by a stack of labels

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

• IPv4 and IPv6 control plane

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

IS-IS Configuration – Example

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

• OSPFv2 control plane

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

OSPF Configuration Example

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

SRGB [16,000 – 23,999 ] SRGB [16,000 – 23,999 ]

Payload Payload Payload Payload

Push Swap Pop Pop

Payload Payload Payload Payload Payload

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

Payload Payload Payload Payload Payload

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

§ Each node’s Label Manager

§ MPLS-to-MPLS LDP and SR entries co-exist

§ MPLS-to-IP LDP and SR entries co-exist

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

§ LFIB populated by IGP (ISIS / PE PE

§ Forwarding table remains constant PE

(Nodes + Adjacencies) regardless PE PE

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

§ In this case, the LDP LSP is connected to

§ C installs the following LDP-to-SR FIB B C D 16066

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

§ When a node is SR capable but its

Out Label (SID), Input Label Out Label (LDP),

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

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

§ Prevents transient congestion and suboptimal routing

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

§ Leverages existing and proven LFA technology

§ Enforcing loop-freeness on post-convergence path

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

19 - 21 March 2018 | Cisco Connect | Rovinj, Croatia

§ TI-LFA for link R1R2 on R1 A Z

§ Calculate P and Q spaces Packet to Z Packet to Z