Segment Routing Technology Deep Dive and Advanced Use Cases

© 2016 Cisco and/or its affiliates. All rights reserved. 2
Cisco
Connect
Segment Routing:
Technology Deep-Dive and
Advanced Use Cases
Thierry Couture
Consulting Systems Architect
dax@cisco.com
January 2018

© 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public
Agenda
• Introduction
• Quick Segment Routing Recap
• SRv6
• SR Traffic Engineering (SR-TE)
• Conclusion

Ground Rules
• Assumptions:
• Working knowledge of networking
• Working knowledge of IP
• Working knowledge of MPLS
• Working knowledge of Traffic Engineering
• Working knowledge of IPv6
• Out of scope:
• Segment Routing transition and migration mechanisms (SR/LDP Interop, SRMS, Inter-
AS, vpnv4/rt5 stitching, etc.)
• SR Configuration (RTFM)
• Services Overlay (L3VPN, EVPN, etc.)
4

Breaking News:
The Internet is GROWING
(and dad doesn’t want to pay for it anymore!)
6

Segment Routing is Really About Simplification
Description “Classic” Network SR/EVPN
Management
Plane
CLI, SNMP, SSH, Telnet, Syslog, NetFlow, BMP,
RCMD, Netconf, E-OAM, MPLS-OAM, YANG
(IETF/OpenConfig), gRPC, GPB, PCEP, etc.
NC/YANG, SR-
OAM, SR Traffic
Matrix, Telemetry
Service Plane L2VPN, L3VPN, BGP-VPLS, LDP-VPLS, EVPN,
L2TPv3, GRE, PPP, OTV, LISP, NSH, etc.
EVPN
(+ L3VPN)
Control Plane OSPFv2 (IPv4), OSPFv3 (IPv6), ISIS, LDP, T-
LDP, RSVP-TE, BGP, Controller, etc.
IGP
(incl. FRR)
BGP
Forwarding
Plane
IP, MPLS, IPv6, VXLAN, PBB, LISP, GRE,
MPLSoGRE, etc.
SR
MPLS/IPv6
7
Simplification is really about saving XYZ…

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
• Reduce state, reduce lookups, reduce…
• Segment: an identifier for any type of instruction
• Segment identifies network points and/or vectors (forwarding)
• Segment identifies services
• Segments can be combined (“stacked”)
10

Segment Routing – Forwarding Plane
• MPLS: an ordered list of segments is represented as a stack of labels
• Segment ID → Label
• Basic building blocks distributed by the IGP or BGP
• Push, Continue, Next –> Push, Swap, Pop
• IPv6: an ordered list of segments is encoded in a routing extension header
• More details later…
11

IGP Prefix Segment
• Shortest-path to the
IGP prefix
• Equal Cost Multipath
(ECMP)-aware
• Global Segment
• Label = 16000 + Index
• Index of NodeX = X is
used for illustrative
purposes
• Distributed by
ISIS/OSPF
• Prefix != Route Entry
• NOT Dynamically
allocated
12
DC (BGP-SR)
10
11
12
13
14
2 4
6 5
7
WAN (IGP-SR)
3
1
PEER
16005

IGP Adjacency Segment
• “Pop and Forward on
the IGP adjacency”
• Local Segment
• Dynamically allocated
• Value “30X0Y”
used for illustration
• X is the “from”
• Y is the “to”
• Advertised as a label
value
• Distributed by
ISIS/OSPF
13
DC (BGP-SR)
10
11
12
13
14
2 4
6 5
7
WAN (IGP-SR)
3
1
PEER
30204

Segment Routing
• Distributed routing protocol (IGP, BGP) used to compute shortest
or best paths and advertise segments
• Segments identify forwarding resources within the topology and
are encoded as MPLS labels (or IPv6 SR extension headers).
• Global segments: nodes / prefixes
• Local segments: peers, output interfaces
• Traffic that does not require path engineering – let IGP/BGP and
ECMP decide
• Traffic that does require path engineering – SDN controller
chooses explicit paths (based on operator policy) and programs
source (border router, VM, application) with forwarding policies
• Example: match flow X → push segments / MPLS label stack / IPv6 EH
• Downstream nodes switch based on label stack without carrying
any per-flow state (reuses MPLS data plane)
14
4 5
3
6 7
AS2
2
1
AS1
BGP-LS
PCEP
pkt
16007
16003
16002
SR
PCE

Segment Routing MPLS
• Reuse MPLS dataplane while extending existing routing protocols
• Enables traffic engineering (TE) and fast reroute (FRR) with much lower network complexity and
state (e.g., RSVP-TE, LDP)
• Enables unified / simplified forwarding plane between DC, Metro and WAN (no complex QinQ,
MPLS, or IP tunnel stitching at network boundaries)
• Enabler of controller based path engineering/programmability (SDN)
• Delivers on the key tenets of SDN for Service Providers including:
o Tight application interaction with the network → full path programmability → flow-based, e2e, inter-domain
o Network optimization → improved capacity management and utilization
o New revenue opportunities → BW on demand & calendaring, low latency, disjoint TE, scavenger
15
InternetDC Metro WAN
ToR,
vRouter
or application
SR
PCE

Segment Routing - Control Plane
• IGP
• ISIS
• TLV
• OSPF
• Opaque LSA (type 10)
• BGP
• BGP-LU
• Controller Based
• From closed loop automated control to “management-plane-ish”
16

© 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 17
MPLS Control and Forwarding Operation with Segment
Routing
PE1 PE2
IGPPE1 PE2
Services
IPv4 IPv6
IPv4
VPN
IPv6
VPN
VPWS VPLS
Packet
Transport LDP
MPLS Forwarding
RSVP BGPStatic IS-IS OSPF
No changes to
control or
forwarding plane
IGP or BGP label
distribution for
IPv4 and IPv6.
Forwarding plane
remains the same
MP-BGP

router ospf 1
router-id 1.1.1.1
segment-routing mpls
area 0
interface Loopback0
passive enable
prefix-sid absolute 16001
!
!
!
OSPF Configuration Example
Prefix-SID for loopback0
Enable SR on all areas
SID index 1
1.1.1.11.1.1.2
1.1.1.5 1.1.1.3
DR
1.1.1.4
18

MPLS LFIB with Segment Routing
• LFIB populated by IGP’s (ISIS /
OSPF), BGP, Controller, etc.
• Forwarding table remains constant
(Nodes + Adjacencies) regardless
of number of paths
• Other protocols (LDP, RSVP, BGP)
can still program LFIB
19
PE
PE
PE
PE
PE
PE
PE
PE
P
In
Label
Out
Label
Out
Interface
L1 L1 Intf1
L2 L2 Intf1
… … …
L8 L8 Intf4
L9 L9 Intf2
L10 Pop Intf2
… … …
Ln Pop Intf5
Node-SID
Adjacency-SID
Forwarding
table remains
constant

Multi-Domain Topology
• SR Path Computation
Element (PCE)
• PCE collects via BGP-
LS
• IGP segments
• BGP segments
• Topology
20
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
SR
PCE

End-to-End Policy, Unified Data Plane
• Construct a path by
combining segments
to form an end-to-end
path:
• 16001 (Prefix-SID)
• 16002 (Prefix-SID)
• 30204 (Adj-SID)
• 40407 (Peer-SID)
• Per-application
flow engineering
• Millions of flows
• No signaling
• No midpoint state
• No reclassification at
boundaries
21
PCEP, Netconf, BGP
SR
PCE
Low-Latency to 7
for application …
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
16001
16002
30204
40407
{16001,
16002,
30204,
40407 }

Industry at large backs up SR
Strong customer
adoption
WEB, SP, Enterprise
Standardization
IETF
Multi-vendor
Consensus
Interop testings
De-Facto SDN
Architecture

Segment Routing Standardization
• IETF standardization in SPRING working
group
• Protocol extensions progressing in
multiple groups
• IS-IS
• OSPF
• PCE
• IDR
• 6MAN
• BESS
• Broad vendor support
• Strong customer adoption
• WEB, SP, Enterprise
23
Sample IETF Documents
Problem Statement and Requirements
(RFC 7855)
Segment Routing Architecture
(draft-ietf-spring-segment-routing)
IPv6 SPRING Use Cases
(draft-ietf-spring-ipv6-use-cases)
Segment Routing with MPLS data plane
(draft-ietf-spring-segment-routing-mpls)
Topology Independent Fast Reroute using Segment Routing
(draft-bashandy-rtgwg-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 40 IETF drafts in progress

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

IPv6 adoption is a reality
% website reachability by country
Source: 6lab.cisco.com – World maps – 11-June-2017
Global IPv6 traffic
grew 243% in 2015
Globally IPv6 traffic will
grow 16-fold from 2015 to
2020
IPv6 will be 34% of total
Internet traffic in 2020

IPv6 Provides E2E Reachability
Support 5G growth
IPv6 addresses summarization
5G
5G
5G
IoT services
Support container adoption for
micro-services
Next-Gen Data Center
Micro-services
Source Address
Destination
Address
IPv6
Metro/Core
Network
IP
4G
xDSL
FTTH
Cable
Legacy
DC

Opportunity for further simplification
• Multiplicity of protocols and states hinder network economics
IPv6 for reach
Additional Protocol just for tenant IDUDP+VxLAN Overlay
Additional Protocol and StateNSH for NFV
RSVP for FRR/TE States scaling problem (k*N^2)

SRv6 – Segment Routing & IPv6
• Simplicity
• Protocol elimination
• SLA
• FRR and TE
• Overlay
• NFV
• SDN
• SR is de-facto SDN architecture
• 5G Slicing
29
IPv6 for reach
SRv6 for anything else

IPv6 Header
• Next Header (NH)
• Indicates what comes next
31

NH = IPv4 4

NH = IPv6 41

NH = TCP 6

NH = UDP 17

NH = Routing Extension
• Generic routing extension header
• Defined in RFC 2460
• Next Header: UDP, TCP, IPv6…
• Hdr Ext Len: Any IPv6 device can skip this header
• Segments Left: Ignore extension header if equal to 0
• Routing Type field:
• 0 Source Route (deprecated since 2007)
• 1 Nimrod (deprecated since 2009)
• 2 Mobility (RFC 6275)
• 3 RPL Source Route (RFC 6554)
• 4 Segment Routing
36
43

NH = SRv6
• NH = 43, Type = 4
37
4
RFC2460SRspecific
43
TAG

SRH
• SRH contains
• the list of segments
• Segments left (SL)
• Flags
• TLV
• Active segment is in the IPv6 DA
• Next segment is at index SL-1
• The last segment is at index 0
• Reversed order
38
4
43
Active Segment
Last Segment
See IETF draft-ietf-6man-segment-routing-header,
currently revision -06
TAG

Source Node
• Source node is SR-capable
• SR Header (SRH) is created with
• 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
• First Segment is set to " − 1
• IP DA is set to the first segment
• Packet is send according to the IP DA
• Normal IPv6 forwarding
Version Traffic Class
Next = 43 Hop LimitPayload Length
Source Address = A1::
Destination Address = A2::
Segment List [ 0 ] = A4::
Next Header Len= 6 Type = 4 SL = 2
First = 2 Flags TAG
IPv6Hdr
SRHdr
Payload
Flow LabelFlow Label
4
A4::
1
A1::
SR Hdr
IPv6 Hdr SA = A1::, DA = A2::
( A4::, A3::, A2:: ) SL=2
Payload
2
A2::
3
A3::
40

Non-SR Transit Node
• Plain IPv6 forwarding
• Solely based on IPv6 DA
• No SRH inspection or update
41
SR Hdr
( A4::, A3::, A2:: ) SL=2
Payload
4
A4::
1
A1::
2
A2::
3
A3::

SR Segment Endpoints
• SR Endpoints: SR-capable nodes whose
address is in the IP DA
• SR Endpoints inspect the SRH and do:
• IF Segments Left > 0, THEN
• Decrement Segments Left ( -1 )
• Update DA with Segment List [ Segments Left ]
• Forward according to the new IP DA
42
SR Hdr
( A4::, A3::, A2:: ) SL=1
Payload
First = 2 Flags TAG
IPv6Hdr
SRHdr
Payload
4
A4::
A
A1::
2
A2::
3
A3::

SR Segment Endpoints
• SR Endpoints: SR-capable nodes whose
address is in the IP DA
• SR Endpoints inspect the SRH and do:
• IF Segments Left > 0, THEN
• Decrement Segments Left ( -1 )
• Update DA with Segment List [ Segments Left ]
• Forward according to the new IP DA
• ELSE (Segments Left = 0)
• Remove the IP and SR header
• Process the payload:
• Inner IP: Lookup DA and forward
• TCP / UDP: Send to socket
• …
43
Standard IPv6 processing
The final destination does
not have to be SR-capable.
SR Hdr
( A4::, A3::, A2:: ) SL=0
Payload
First = 2 Flags TAG
IPv6Hdr
SRHdr
Payload
4
A4::
1
A1::
2
A2::
3
A3::

SR for Anything
Network as a Computer
(Network Programmability)

Network instruction
• 128-bit SRv6 SID
• Locator: routed to the node performing the function
• Function: any possible function (optional argument)
either local to NPU or app in VM/Container
• Flexible bit-length selection
45
Locator FunctionLocator Function(arg)

Network Program
Next Segment
Locator 1 Function 1
46

Network Program
Next Segment
Locator2 Function2
47

Network Program
Next Segment
48

Argument shared between functions
Locator1 Function1 Argument1
Metadata TLV
“Global”
Argument

SR Header
Metadata TLV
Segments Left

SID Function – Anything!
• SID functions are locally defined on their parent node
• They can do anything…
• An SR header contains a network program
51
SRHdr
Segment List [ 0 ]
Segment List [ 1 ]
First = 2 Flags TAG
Segment List [ 2 ]
TLVs
Function 1
Function 2 Args
Function 3 Args
Global arguments

Integrated NFV
• A3::A32 means
• App in Container 32
• @ node A3::/64
• Stateless
• NSH creates per-chain state
in the fabric
• SR does not
• App is SR aware or not
53
IPv6 ( A1::0, A3::A32 )
payload
IPv6 ( T1::0, V2::0 )
SRH
{ A3::A32, A4::0,
A5::A76, A2::C4 }
1
2
4
V/64
3
T/64
4
App 32
Container
Server 3
5
App 76
VM
Server 5
IPv6 ( T1::0, V2::0 )
payload
App 32
Container3

Integrated NFV
• Integrated with
underlay SLA
54
1
2
4
V/64
3
T/64
4
5
App 76
VM
Server 5
3
App 32
Container
Server 3
IPv6 ( A1::0, A4::0 )
payload
IPv6 ( T1::0, V2::0 )
SRH
{ A3::A32, A4::0,
A5::A76, A2::C4 }

Integrated NFV
• A5::A76 means
– App in VM 76
– @ node A5::/64
• Stateless
– NSH creates per-chain state
in the fabric
– SR does not
• App is SR aware or not
1
2
4
V/64
3
T/64
4
5
App 76
VM
Server 5
3
App 32
Container
Server 3
IPv6 ( A1::0, A5::A76 )
payload
IPv6 ( T1::0, V2::0 )
SRH
{ A3::A32, A4::0,
A5::A76, A2::C4 }

Integrated NFV
• Integrated with
Overlay
56
1
2
4
V/64
3
T/64
4
5
App 76
VM
Server 5
3
App 32
Container
Server 3
IPv6 ( A1::0, A2::C4 )
payload
IPv6 ( T1::0, V2::0 )
SRH
{ A3::A32, A4::0,
A5::A76, A2::C4 }
IPv6 ( T1::0, V2::0 )
payload

More SRv6 Use-Cases
• 6CN: Enhancing IP to search for Content
• 6LB: Enhancing load-balancers (MAGLEV)
• Video Pipeline (Media Services)
• 5G Slicing
• 5G Ultra-Low Latency (1ms)
57

SRv6 status
• Cisco HW
• ASR9k – IOS/XR
• ASR1k – IOS/XE
• NCS55K – IOS/XR commited
• Nexus9K – NX-OS in planning
• Open-Source
• Linux Kernel 4.10 (Feb. 2017)
• FD.IO
58

Network Programming
• An SRv6 segment is a function at a node
• An SRv6 segment list is a network program
• The network acts as a large computer
• Integrated use-cases well beyond underlay (TE, FRR)
• NFV
• Container networking
• Efficient content management: Spray, 6CN, 6LB
• Video pipeline
• Simplification: IPv6+SRv6 only !
59
SRHdr
Segment List [ 0 ]
Segment List [ 1 ]
First = 2 Flags TAG
Segment List [ 2 ]
TLVs
Function 1
Function 2 Args
Function 3 Args
Global arguments

Motivations for SR-TE
• RSVP-TE combined FRR and TE – aaarrgghhhhh…
• Legacy solutions challenging at scale
• Core states in k*n^2
• No inter-domain (or very difficult)
• Legacy solutions feature complex configuration
• Tunnel interfaces and/or per-device flow state
• Legacy solutions offer complex and fragile steering
• PBR, autoroute, per-flow state
• Granularity tradeoffs with scale
61

SR-TE
• In SR, FRR is taken care of via TI-LFA, it is not a TE function…
• Simple, Automated and Scalable
• No core state: state in the packet header
• No tunnel interface: “SR Policy”
• Prescriptive hop by hop, or use wormholes, your choice…
• Static
• Headend configuration
• Dynamic
• No headend a-priori configuration: on-demand policy instantiation
• No headend a-priori steering: on-demand steering
• Multi-Domain
• XTC for compute
• Binding SID (BSID) for scale
• Lots of Functionality
• Designed with lead operators along their use-cases
62

IETF key document for SR-TE
See IETF draft-filsfils-spring-segment-routing-policy, currently revision -00

Topology Independent LFA (TI-LFA) – Benefits
• Based on Loop Free Alternates
• For every point in a forwarding graph, we pre-compute a loop-free option
• Meant to cover the gap between failure and routing re-convergence
• 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
65
BRKR
ST-

TI-LFA – Zero-Segment Example
• TI-LFA for link R1R2 on R1
• Calculate post-convergence SPT
• SPT with link R1R2 removed from
topology
• Derive SID-list to steer traffic on
post-convergence path à empty
SID-list
• R1 will steer the traffic towards
LFA R5
66
1000
Default metric: 10
A
55
4
Packet to Z
Packet to Z
prefix-SID(Z)
1 2
Z
3
Packet to Z
prefix-SID(Z)

TI-LFA – Single-Segment Example
• Calculate post-convergence
SPT
• Derive SID-list to steer traffic
on post-convergence path à
<Prefix-SID(R4)>
• Also known as “PQ-node”
• R1 will push the prefix-SID of
R4 on the backup path
67
Packet to Z
prefix-SID(Z)
prefix-SID(R4)
Default metric:10
5
21
A Z
3
Packet to Z
prefix-SID(Z)
Packet to Z
4
Packet to Z
prefix-SID(Z)
4

TI-LFA – Double-Segment Example
• Calculate post-convergence SPT
• Derive SID-list to steer traffic on
post-convergence path à
<Prefix-SID(R4), Adj-SID(R4-R3)
• Also known as “P- and Q-node”
• R1 will push the prefix-SID of
R4 and the adj-SID of R4-R3
link on the backup path
68
Default metric: 10
5
21
A Z
R3R4 34
Packet to Z
prefix-SID(Z)
Packet to Z
Packet to Z
prefix-SID(Z)
adj-SID(R4-R3)
prefix-SID(R4)
Packet to Z
prefix-SID(Z)
adj-SID(R4-R3)
1000
Packet to Z
prefix-SID(Z)

SRTE DB
• A headend can learn an attached domain topology via its
IGP or a BGP-LS session
• A headend can learn a non-attached domain topology via a
BGP-LS session
• A headend collects all these topologies in the SR-TE
database (SRTE-DB).
• The SRTE-DB is multi-domain capable
70

SR Policy Identification
• An SR Policy describes an optimization objective between a head end and an
end-point
• An SR Policy is uniquely identified by a tuple
(head-end, color, end-point)
Head-end: where the SR Policy is instantiated (implemented)
Color: an arbitrary numerical value to differentiate multiple SRTE Policies between the
same pair of nodes
End-point: the destination of the SR Policy
2 3
7 6
4
1
5
SR Policy
(1, green, 4)
Head-end: 1
Color: green
End-point: 4
71

SR Policy Color
• Each SR Policy has a color
• Color is used to indicate a certain treatment (policy) provided by an SR Policy
• Only one SR Policy with a given color C can exist between a given node
pair (head-end (H), end-point (E))
• In other words: each SR Policy triplet (H, C, E) is unique
• Example:
• High-BW=“blue”, Low-latency=“green”
• steer traffic to 1.1.1.0/24 via Node4
into High-BW SR Policy (1, blue, 4)
• steer traffic to 2.2.2.0/24 via Node4
into LL SR Policy (1, green, 4)
2 3
7 6
4
1
5
(1, green, 4)
(1, blue, 4)
1.1.1.0/24
2.2.2.0/24
Low-latency
High-BW
72

SR Policy – Candidate Paths
• An SR Policy contains
multiple candidate paths
• An SR Policy instantiates
one single path in RIB/FIB
• i.e. the selected path
among the candidate paths.
• A candidate path is either
dynamic or explicit
• A candidate path may have one or
more weighted SID-lists
• Traffic steered onto an SR Policy
Path is load-shared over all
SID-lists of that path
73
SR Policy
Cpathn
Preferencen
...
Cpath1
Binding-SIDn
Preference1
Binding-SID1
SID-list1m
...
Weight1m
SID-list11
Weight11
SID-listnk
...
Weightnk
SID-listn1
Weightn1

Candidate Paths (Cont.)
• A head-end may be informed about a path for a policy <color, end-
point> by various means including: local configuration (CLI), netconf,
PCEP, or BGP
netconfCLI
PCEPBGP
SRTE
74

Path’s source does not influence selection
Provided by
e.g. local configuration
Provided by
e.g. BGP SR-TE
Selection depends on validity and best
(highest preference value)
SR Policy
( Head, Color, End )
SID-list11
<16003,
16004>
Weight 1
SID-list12
<16004>
Weight 4
Cpath1
Pref 110
SID-list21
<16004>
Cpath2
Pref 100
VALIDVALIDVALID
✔ Cpath3
Pref 200
SID-list31
<16005,
16004>

Path’s source does not influence selection
Provided by
e.g. local configuration
Provided by
e.g. BGP SR-TE
Selection depends on validity and best
(highest preference value)
SR Policy
( Head, Color, End )
SID-list11
<16003,
16004>
Weight 1
SID-list12
<16004>
Weight 4
Cpath1
Pref 110
SID-list21
<16004>
Cpath2
Pref 100
VALIDVALIDINVALID
✔
Cpath3
Pref 200
SID-list31
<16005,
16004>
BRKRST-3122

BSID of a policy
• The BSID of an SR Policy
refers to its selected path
77
SR Policy
Pathn
Preferencen
...
Path1
Binding-SIDn
Best Pref
Binding-SID
SID-listm
...
Weightm
SID-list1
Weight1
SID-listk
...
Weightk
SID-list1
Weight1

Policy – FIB entry
2 3
6 5
41
20
Default link metric: 10
10GE
40GE
SR Policy
SID-list:
{16003,
16004}
Selected
Path
BSID:
40104
In Out Out_intf Fraction
40104 {16003, 16004} To Node2 100%
Forwarding table on Node1

Dynamic Path
Headend Computation

Prefer SR-native Algorithm
2
4
1
5 3
6
7
8 9
Classic Circuit Algo is not optimum!
SID List: {4, 5, 7, 3}
Poor/no ECMP, big SR list
ATM optimized
SR-native is optimum
Shortest SID list with Max ECMP
SID List: {7, 3}
IP-optimized
2
4
1
5 3
6
7
8 9

segment-routing
traffic-eng
policy POLICY1
color 20 end-point ipv4 1.1.1.3
binding-sid mpls 1000
candidate-paths
preference 100
dynamic mpls
metric
type te
margin absolute 5
sid-limit 6
81
Min-Metric with Margin
and max SID list
2 3
4
1
T:15
6
5
T:15
T:5
I:30
T:8
Default IGP link metric: I:10
Default TE link metric: T:10
Min-Metric(1 to 3, TE)
= SID-list <16005, 16004, 16003>
Cumulated TE metric = 23
Min-Metric(1 to 3, TE, m=5, s<=6)
= SID-list <16005, 16003>
Max Cumulated TE metric = 25 < 23+ 5

segment-routing
traffic-eng
policy POLICY1
candidate-paths
preference 100
dynamic mpls
metric
type latency
Node1
2 3
4
1
Default TE link metric: T:10
T:15
5
T:15
I:30
T:8SID-list: {16005, 16004, 16003}
6
Low-Latency
• Min-metric on TE metric where propagation latency is encoded in TE metric
• same with margin and Max-SID
• same with latency metric automatically measured by a node for its attached links and
distributed in the IGP
82

segment-routing
traffic-eng
affinity bit-map
Plane1 0x00000001
Plane2 0x00000002
!
policy POLICY1
candidate-paths
preference 100
affinity
exclude-any Plane2
dynamic mpls
metric
type igp
Node1
Plane Affinity
• Min-Metric on IGP metric with exclusion of a TE-affinity “Plane2”
• all the links part of plane 2 are set with TE-affinity “Plane2”
83
1 2
11 12
3
13 14
21 22
23 24
Plane1
Plane2
SID-list:
{ 16014, 16003 }

segment-routing
traffic-eng
policy POLICY1
candidate-paths
preference 100
dynamic mpls
metric
type igp
association group 1 type node
policy POLICY2
candidate-paths
preference 100
dynamic mpls
metric
type igp
association group 1 type nodeNode1
2 3
5 6
4 71
I:100
I:100
SID-list:
{16002, 30203, 16007}
SID-list:
{16005, 16007}
Service Disjointness from same headend
• The headend computes two disjoint paths
84
I:20

On-demand SR Policy
Intra-Domain

On-Demand SR Policy
• 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
• Color community is used as SLA indicator
• Reminder: an SR policy is defined (endpoint, color)
86
BGP
Next-hop
BGP Color
Community

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

2
6
1 CE
5
4
I: 50
T: 15
On-demand SR Policy work-flow
BGP: 20/8 via
CE
20/8
RR
BGP: 20/8 via PE4
VPN-LABEL: 99999
Low-latency (color 20)
BGP: 20/8 via PE4
VPN-LABEL: 99999
router bgp 1
neighbor 1.1.1.10
address-family vpnv4 unicast
!
segment-routing
traffic-eng
on-demand color 20
metric
type te
PE4 with Low-
latency (color 20)?
use template
color 20
à SID-list
<16002, 30204>
animated
Default IGP cost: I:10
Default TE cost: T:10
no route-policy required!
SR Policy template
88

Benefits
• SLA-aware BGP service
• No a-priori full-mesh of SR policy configuration
• 3 to 4 common optimization templates are used throughout the network
• color => optimization objective
• No complex steering configuration
• Automated steering of BGP routes on the right SLA path
• Data plane performant
• BGP PIC FRR data plane protection is preserved
• BGP NHT fast control plane convergence is preserved
89

XR Transport Controller (XTC)
• XTC is an IOS XR multi-domain, stateful SR PCE*
• IOS XR: XTC functionality is available on any physical or virtual IOS XR node,
activated with a single configuration command
• SR: Stateful with native SR-optimized computation algorithms – same as the
head end!
• Multi-domain: Real-time reactive feed via BGP-LS/ISIS/OSPF from multiple
domains; computes inter-area/domain/AS paths
• Stateful: takes control of SRTE Policies, updates them when required
• XTC is fundamentally distributed
• Not a single all-overseeing entity, but distributed across the network; RR-alike
deployment
* Path Computation Element
91

XTC consolidates the topologies
• XTC combines the different
topologies to compute
paths across entire topology
Domain1 Domain2
A BR1 BR3
BR2 BR4
Domain3
Z
BR5
BR6
BGP-LSPeering
links
Domain1 Domain2
A BR1 BR3
BR2 BR4
Domain3
Z
BR5
BR6
XTC
92

XTC – High Availability (HA)
• XTC leverages the well-known standardized PCE HA
• Head-end sends PCEP Report for its SR Policies to all connected XTC nodes
• Head-end delegates control to its primary XTC
• Delegate flag (D) is set in PCRept to primary XTC
• Upon failure of the primary XTC, head-end re-delegates control to another XTC
93

SR TE
• Simple, Automated and Scalable
– No core state: state in the packet header
– No tunnel interface: “SR Policy”
– No headend a-priori configuration: on-demand policy instantiation
– No headend a-priori steering: on-demand steering
• Multi-Domain
– XTC
• Lots of Functionality
– Designed with lead operators along their use-cases
94

Segment Routing is Really About Simplification
Description “Classic” Network SR/EVPN
Management
Plane
CLI, SNMP, SSH, Telnet, Syslog, NetFlow, BMP,
RCMD, Netconf, E-OAM, MPLS-OAM, YANG
(IETF/OpenConfig), gRPC, GPB, PCEP, etc.
NC/YANG, SR-
OAM, SR Traffic
Matrix, Telemetry
Service Plane L2VPN, L3VPN, BGP-VPLS, LDP-VPLS, EVPN,
L2TPv3, GRE, PPP, OTV, LISP, NSH, etc.
EVPN
(+ L3VPN)
Control Plane OSPFv2 (IPv4), OSPFv3 (IPv6), ISIS, LDP, T-
LDP, RSVP-TE, BGP, Controller, etc.
IGP
(incl. FRR)
BGP
Forwarding
Plane
IP, MPLS, IPv6, VXLAN, PBB, LISP, GRE,
MPLSoGRE, etc.
SR
MPLS/IPv6
96
Simplification is really about saving XYZ…

Stay Up-To-Date on SR
http://www.segment-routing.net/
https://www.linkedin.com/groups/8266623
https://twitter.com/SegmentRouting
https://www.facebook.com/SegmentRouting/ amzn.com/B01I58LSUO
97

Segment Routing Technology Deep Dive and Advanced Use Cases

More Related Content

What's hot

Similar to Segment Routing Technology Deep Dive and Advanced Use Cases

More from Cisco Canada

Recently uploaded

Segment Routing Technology Deep Dive and Advanced Use Cases