Brkrst-3122 (Flex Algo SR)

#CLUS
Segment Routing
Technology deep-dive and advanced
use cases
Jose Liste – Technical Marketing Engineer
BRKRST-3122
#CLUS
Agenda
• SR IGP Flex Algo

• Per-Link Delay Measurement
• SRv6
• Demonstration
#CLUS BRKRST-3122 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Cisco Webex Teams
Questions?
Use Cisco Webex Teams (formerly Cisco Spark)
to chat with the speaker after the session
How
1 Find this session in the Cisco Events App
2 Click “Join the Discussion”
3 Install Webex Teams or go directly to the team space
4 Enter messages/questions in the team space
Webex Teams will be moderated cs.co/ciscolivebot#BRKRST-3122

by the speaker until June 18, 2018.
#CLUS © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 4
Industry at large backs up SR
Strong customer De-facto SDN Standardization Multi-vendor Open Source

adoption Architecture IETF Consensus Linux, VPP
WEB, SP, DC,
Metro, Enterprise
Segment Routing
• Source Routing
• the topological and service (NFV) path is encoded in the packet header
• Scalability
• the network fabric does not hold any per-flow state for TE or NFV
• Simplicity
• automation: TI-LFA
• protocol elimination: LDP, RSVP-TE, NSH…
• End-to-End Unified SR Fabric

• DC, Metro, WAN
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
SR IGP Flex Algo
SR IGP Flex Algo
• Complements the SRTE solution by adding new Prefix-Segments
with specific optimization objective and constraints
• minimize igp-metric or delay or te-metric
• avoid SRLG or affinity
• Leverages the SRTE benefits of simplicity and automation

• Automated sub-50msec FRR (TI-LFA)
• On-Demand Policy (ODN)
• Automated Steering (AS)
"Flex Algo is very valuable addition to SRTE solution that allow to
auto-steer unicast and multicast traffic via any topology/path
based on operator defined logic.
Ease of configuration and operational management, ability to

provision dynamic constrained paths based on a single SR label
with local repair (TI-LFA) respecting the same constraints as the
primary path are some of the benefits that we might realize with
Flex Algo."
Arkadiy Gulko - Thomson Reuters
IGP SR Algorithm
• Each Prefix SID is related to an algorithm
• Each node advertises its ALGO capability
Currently defined algorithms
• 0: Shortest Path First (SPF) algorithm based on link metric.
• This is the well-known shortest path algorithm as computed by the IS-IS Decision
process. Consistent with the deployed practice for link-state protocols, algorithm
0 permits any node to overwrite the SPF path with a different path based on local
policy
• 1: Strict Shortest Path First (SPF) algorithm based on link metric.
• The algorithm is identical to algorithm 0 but algorithm 1 requires that all nodes
along the path will honor the SPF routing decision. Local policy MUST NOT alter
the forwarding decision computed by algorithm 1 at the node claiming to support
algorithm
Flexible Algorithm
• We call “Flex-Algo”
• The algorithm is defined by the operator, on a per-deployment basis
• Flex-Algo K is defined as
• The minimization of a specified metric: IGP, delay, …
• The exclusion of certain link properties: link-affinity, SRLG, …
• Example
• 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”
Flex-Algo Participation Advertisement
• Each node MUST advertise Flex-Algo(s)
that it is participating in
Alg128
Nodes 0 and 9 participate to Algo 0 and 128 and 129
1 2
Nodes 1/2/3/4 participate to Algo 0 and 128 4 3
0
Nodes 5/6/7/8 participate to Algo 0 and 129
5 6 9
8 7
Alg129
Prefix-SID for each Flex-Algo
• If a node advertises participation in a Flex-Algo
likely it also advertises a prefix SID for that Flex-Algo
Node 9 advertises Alg128

Prefix SID 16009 for ALGO 0 1 2
Prefix SID 16809 for ALGO 128
Prefix SID 16909 for ALGO 129 0 4 3
5 6 9
Node 2 advertises
Alg129
No additional loopback address
• Flex-Algo Prefix SID’s can be advertised as additional prefix-SID’s
of the existing loopback address
Node 9 advertises loopback0 1.0.0.9/32 with

0 4 3
Prefix SID 16909 for ALGO 129 1.0.0.9
5 6 9
8 7
Flex-Algo Definition
• Each node MUST have the definition of the Flex-Algo(s)
that it is participating in
• e.g. ALGO 128: minimize on IGP metric and avoid TE affinity RED
• Local configuration
• likely automated via a solution such as NSO
• Learned from a central entity via ISIS flooding
• new top TLV defined for Flex-Algo definition advertisement
Flex-Algo Computation and Prefix-SID
installation
• A node N computes Flex-Algo K if
• it is enabled for K, and
• it has a consistent definition for K
• If so, the first step is to define the topology of K

• N prunes any node that is not advertising participation to K
• N prunes any link that is excluded by the algorithm of K
• e.g. if K excludes TE-affinity RED then any link with TE-affinity RED is pruned
• The resulting topology is called Topo(K)
Flex-Algo Computation and Prefix-SID
installation
• The second step is to compute shortest-path tree on Topo(K) with
the metric defined by K
• it could be the IGP metric, the TE metric or the delay
• The third step is to install any reachable Prefix-SID of Flex-Algo K
in the forwarding table
Example 1
• Grey nodes support Algo 0/128/129
• Green nodes support 0/128
1 2
• Red nodes support 0/129 Alg128
0 4 3
• Algo 128: minimize IGP metric
• Algo 129: minimize IGP metric 5 6 9
• Nodes advertise a Prefix SID 8 7

for each Algo they support Alg129
• For example, for node N: 16000 + N
• + 0 for Algo 0
• + 800 for Algo 128
• + 900 for Algo 129
Example 1
16002 Algo 0
1 2 16802 Flex-Algo 128
Alg128
0 4 3
16009 Algo 0
5 6 9 16809 Flex-Algo 128
7 16909 Flex-Algo 129

8
Alg129
16007 Algo 0
16907 Flex-Algo 129
Example 1 – Topo(0)
1 2
0 4 3
5 6 9
8 7
1 2
Alg128
0 4 3
5 6 9
8 7
Alg129
Example 1 – Prefix-SID 16009 of Algo 0
1 2
0 4 3
5 6 9
8 7
Example 1 – Prefix-SID 16809 of Flex-Algo 128
1 2
0 4 3
Example 1 – Prefix-SID 16909 of Flex-Algo 129
5 6 9
8 7
Example 1 – FIB of node 0
• 16009 via 1 or 5
• 16809 via 1
• 16909 via 5
• 16002 via 1
• 16802 via 1
• 16007 via 5
• 16907 via 5
Example 1 – FIB of node 1
• 16009 via 2 or 4
• 16809 via 2 or 4
• 16002 via 2
• 16802 via 2
• Node 1 does not install Prefix-SID

for Flex-Algo 129 as Node1 does not participate in 129
Notes
• This computation is performed by any node part of K
• If a node is part of 2 Flex-Algo’s, it performs the described
computation independently for each Flex-Algo
• ECMP is obviously supported in each Flex-Algo
TI-LFA
• The TI-LFA algorithm is performed within Topo(K)
• The backup path is expressed with Prefix-SID’s of Algo K
• Benefits: the backup path is optimized per Flex-Algo!
Example – Primary paths per Algo
1.1.1.3/32
SID(algo 0) 16003
SID(algo 128) 16803
At node 1 for destination 3
16003 => 16003 via 2
2 3
16803 => 16803 via 2
1 4
6 100
5
All nodes participate to Algo 128
which is defined as min IGP metric
and avoid red affinity
Each node in this topology supports SR alg0, alg128
Default IGP link metric: I:10
Example – TI-LFA Backup path per Algo
1.1.1.3/32
SID(algo 0) 16003
SID(algo 128) 16803
At node 1 for destination 3
16003 => 16003 via 2
2 3
Backup: <24065, 16003> via 6
1 4
16803 => 16803 via 2
6 5 Backup: <24065, 16803> via 6
100
The usage of Algo-128 Prefix-SID 16803 ensures that the

Algo 128 backup path also avoids the red link
Reminder: 240XY is the Adj SID from node X to node Y
Use-Case – Dual Plane
1 2
• Green nodes support 0/128 Alg128
0 4 3
• Red nodes support 0/129
9
• Algo 128: minimize IGP metric 5 6
Alg129
• Nodes advertise a Prefix SID for each Algo they support
• For example, for node N: 16000 + N
• + 0 for Algo 0
Note: use of TE-affinities is not necessary
• + 800 for Algo 128
• + 900 for Algo 129
Use-Case – Dual Plane with link affinity
Alg128
1 2
• Green nodes support 0/128
0 4 3
• Red nodes support 0/129
9
and exclude purple links 8 7
• Algo 129: minimize IGP metric Alg129
and exclude purple links
1 2
0 4 3
Topo(128) 9
CLI - Dual Plane with link affinity
router isis 1
is-type level-2-only Alg128
net 49.0001.0000.0000.0002.00
affinity-map PURPLE bit-position 1
1 2
flex-algo 128
0 4 3
exclude affinity PURPLE
!
address-family ipv4 unicast 5 6 9
router-id 1.1.1.2
segment-routing mpls 8 7
! Alg129
interface Loopback0
address-family ipv4 unicast
prefix-sid absolute 16002 Config of Node 2
prefix-sid algorithm 128 absolute 16802
!
interface GigabitEthernet0/2/0/4
affinity flex-algo PURPLE
Use-Case – Delay vs Cost of Transport
• All nodes support Algo 0 & 128 23
2 1 2 2
• ISIS link metric 10
• Algo 128: minimize delay metric 0 1 1 9
• Per-link measurement of delay and 2 16 2
advertisement as delay metric via ISIS 5 6
• Delay metric at that time shown in green
1 2 1 2
0 16009 (Cost) 9 0 16809 (delay) 9
5 6 5 6
CLI - Delay vs Cost of Transport
router isis 1
is-type level-2-only
net 49.0001.0000.0000.0002.00 23
flex-algo 128 2 1 2 2
metric-type delay
! 0 1 1 9
router-id 1.1.1.2 2 16 2
segment-routing mpls
5 6
!
interface Loopback0
Config of Node 2
prefix-sid absolute 16002
prefix-sid algorithm 128 absolute 16802
!
performance-measurement
interface GigE0/0/2/6
delay-measurement
Automated Steering
• SRTE Automated Steering is leveraged for IGP Flex-Algo
segment-routing
traffic-eng
on-demand color 100
dynamic mpls
flex-algo 128
“Any 100-colored BGP route should be steered

via the prefix-SID(ALGO 128) of the BGP nhop”
Automated Steering – Dual Plane
segment-routing 8/8 VPN-label 80000
traffic-eng
on-demand color 100
color 100
dynamic mpls 1 2 via 1.0.0.9/32
flex-algo 128 16809
router isis 1 0 4 3
flex-algo 128
5 6 9
FIB
8 7
8/8: push 80000 16809
• Node 0 automatically steers any BGP route with color 100 from 9 via 16809 hence via
the green plane only
• One single Flex-Algo Prefix-SID expresses the end-to-end SLA path
Automated Steering – Dual Plane
segment-routing 7/8 VPN-label 70000
traffic-eng
on-demand color 100
via 1.0.0.9/32
dynamic mpls 1 2
flex-algo 128 16009
router isis 1 0 4 3
flex-algo 128
5 6 9
FIB
7/8: push 70000 16009
8 7
• Node 0 automatically steers any BGP route without color from 9 via 16009 (any plane)
Consistency
• Any node advertises his definition of Flex-Algo
• As soon as a difference between two definitions of the same Flex-Algo is detected,
the Flex-Algo is disabled
• any Prefix-SID of that Flex-Algo is removed from FIB
• no path is computed
• Recommendation
• configure two nodes to advertise the Flex-Algo definition for the domain
• one with a higher priority
• do not configure any per-node local definition
• this way, all the nodes deterministically use the same definition
• Or leverage a solution such as NSO to ensure the domain-wide consistency of the

config
OSPF and SRv6
• Same applies to OSPF
• Same applies to SRv6
ODN and AS Inter-Domain delay
SR
PCE
segment-routing
traffic-eng
on-demand color 100
dynamic mpls 9 23
pce
2 1 2 3 2
flex-algo 128
0 1 1 1 9
2 7 16 2
6 5 4
Domain 1 Domain 2
• Any node of both domain supports Algo 128 • The ISIS metric per link is 10
• Algo 128 is defined as min delay • 9 advertises 2/8 with color 100
• The delay of each link is reported in drawing
ODN and AS Inter-Domain delay – Cont.
SR
PCE
9 23
2 1 2 3 2
FIB
2/8: push <16805, 16809> 0 1 1 1 9

2 7 16 2
6 5 4
16805 16809
• Upon receiving 2/8, node 0 dynamically creates an SRTE policy to 9
• As 9 is beyond its domain, node 0 requests the computation from its PCE and indicates that Flex-
Algo128 is needed
• PCE replies with MPLS stack <16805, 16809>
IETF
• draft-ietf-spring-segment-routing
• Prefix-SID per Algorithm
• draft-ietf-spring-segment-routing-policy
• SR Policy architecture, ODN, AS
• draft-ietf-lsr-flex-algo
• Customization of Algo and consistency
• draft-ietf-isis-te-app
• Used to flood Flex-Algo specific link affinities
• RFC7810 (IS-IS Traffic Engineering (TE) Metric Extensions)
• Used to advertise extended TE metrics – e.g. link delay
Conclusion
SR IGP Flexible Algorithm
• Scalability
• Single SID is used to enforce traffic on the Flex-algo specific path
• Flexible
• Any operator can define its custom algorithm
• Functionality
• Optimum TI-LFA backup paths respecting the same constraints as primary path
• Inter-domain SR Policy based on SR IGP Flex Algo
• Applicable to multicast
• Automation and Simplicity

• TE-path from anywhere to anywhere automatically computed by IGP
• ODN and Automated Steering
• Network-wide consistency check
Per-Link Delay
Measurement
ISIS Signaling
Type Description
----------------------------------------------------
33 Unidirectional Link Delay
34 Min/Max Unidirectional Link Delay
35 Unidirectional Delay Variation
ISIS
• RFC 7810 (IS-IS Traffic Engineering (TE) Metric Extensions)

• Used to advertise extended TE metrics – e.g. link delay (in usec)
OSPF and BGP-LS
Value Sub-TLV
27 Unidirectional Link Delay
28 Min/Max Unidirectional Link Delay
29 Unidirectional Delay Variation
OSPF
• RFC 7471 (OSPF Traffic Engineering (TE) Metric Extensions)

• Used to advertise extended TE metrics – e.g. link delay (in usec)
• BGP-LS: draft-ietf-idr-te-pm-bgp
Leveraged by SRTE – SR Policy
segment-routing
• SR Policy for min delay traffic-eng
policy FOO
color 20 end-point ipv4 1.1.1.3
binding-sid mpls 1000
candidate-paths
preference 100
dynamic mpls
metric
type delay
Leveraged by SRTE – IGP Flex Algo
• IGP SR Flex Algo for minimum delay
router isis 1
flex-algo 128
metric-type delay
Per-link delay Measurement
• Over a measurement internal
• minimum Used as metric for SRTE (Policy or Flex-Algo)
• average
• maximum Not used by SRTE
• variance
• One-way or Two-way
• one-way requires clock synchronization
Minimum delay is of interest for SRTE
• Minimum delay provides the propagation delay
• fiber length / speed of light
• A property of the topology
• with awareness of DWDM circuit change
• SRTE (Policy or Flex-Algo) can optimize on min delay
Average, Max and Variance are dealt by QoS
• Depends on congestion
• (traffic burst over line rate) / line rate
• Highly variable at any time scale
• Not controlled by routing optimization
• Controlled by QoS
• Priority queue, WRR, WFQ…
• Tail-Drop, RED…
Link Delay - Configuration
• If the link is enabled for an IGP, then this IGP automatically includes
the delay TLV in its LSP/LSA
1 2
performance-measurement performance-measurement
interface <GigE0/0/0/0> interface <GigE0/0/0/0>
delay-measurement delay-measurement
Link Delay – Probe Measurement
TX Timestamp T1 RX Timestamp T2
PM Query Packet
Local-end 1 2 Remote-end
PM Response Packet
RX Timestamp T4 TX Timestamp T3
• One Way Delay = (T2 – T1)

• Two-Way Delay = (T2 – T1) + (T4 – T3)
Query Packet using RFC 6374 Packet Format
Destination MAC Address – Mcast MAC Address
Source MAC Address

L2 Encap - RFC 7213
Ether-Type
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL EOS | Exp |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GAL/GAch
|0 0 0 1|Version| Reserved | GAL Channel Type(0xc) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Control Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QTF | RTF | RPTF | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | DS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DM Packet - RFC 6374
. .
. . Timestamp - 1588v1 (8 bytes)
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 4 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URO Type | Length={6,18} | UDP-Destination-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP/UDP Return TLV - RFC 7876
(for one-way mode)
Default
• Every 3 second, a query
• a two-way query is sent
• Every 30 seconds, a probe

• min, avg, max, var are computed over the last 10 queries
• Last-Probe EDT trigger with (min, avg, max, var)
• Every 120 seconds, an aggregation

• min, avg, max, var over the last 4 probes are computed
• Last-Aggregation EDT trigger with (min, avg, max, var)
• IF [abs(min-F.min)/F.min >= 10%] and [abs(min-F.min)>=1000usec]
THEN an LSDB change is triggered to flood the new link delay values
a last-advertisement EDT is triggered with these values
F.min is the last flooded value of min-delay. This is what the rest of the network thinks of this link min delay.
Routing stability – Telemetry accuracy
Every 30sec EDT Telemetry push
1 2
Every 120sec
IF significant min change ISIS/OSPF/BGP-LS update
THEN trigger an ISIS/OSPF flood
• SRTE optimization only needs minimum delay

• IGP to only flood/update if the meaningful parameter changes (min)
• Use telemetry to collect the evolution of other delay components at
finer time scale (min, max, avg at probe period)
Default
• Automated discovery of the per-link propagation delay
• Automated signaling in ISIS/OSPF/BGP-LS
• Automated churn protection
• a change is advertised if > 10% and > 1000usec (200km of fiber)
• Automated detection of optical path change
• Worst-case 240sec for a degradation
• 60sec if accelerated mode enabled
Customization
• Ample ability to customize the measurement behavior
If we had more time
• Bundle
• Per SR Policy delay measurement
• ECMP support
• Per SR Policy loss measurement
• Per-Link Loss measurement
Conclusion
Conclusion
• SRTE integrated framework for SLA delivery
• Per-link delay measurement
• Automation
• Simplicity
• Scale
• Functionality
Real
• Visit the SR booth at World of Solutions and enjoy demonstrations
on Flex Algo, MPLS-PM, ODN and Automated Steering !
SRv6
Objective of SRv6
IPv6 provides reachability
IoT services Micro-services
IP
Metro/Core Legacy Next-Gen Data Center
5G 4G Network DC
xDSL
5G
FTTH
5G Cable
Source Address
Support 5G growth Support container adoption for

IPv6 addresses summarization Destination Address micro-services
IPv6
SRv6 for underlay
SRv6 for Underlay Simplification, FRR, TE, SDN
IPv6 for reach
Opportunity for further simplification
NSH for NFV Additional Protocol and State
UDP+VxLAN Overlay Additional Protocol just for tenant ID
SRv6 for Underlay Simplification, FRR, TE, SDN
IPv6 for reach
• Multiplicity of protocols and states hinder network economics
Network Programming
Network as a computer - SR for
anything
Network instruction
Locator Function
• 128-bit SRv6 SID

• Locator: routed to the node performing the function
• Function: any possible function
either local to NPU or app in VM/Container
• Flexible bit-length selection
Network instruction
Locator Function Args*
• 128-bit SRv6 SID

• Locator: routed to the node performing the function
• Function: any possible function
either local to NPU or app in VM/Container
• Arguments: optional argument bits to be used only by that SID
• Flexible bit-length selection
Network Program
Next Segment Locator 1 Function 1
Locator 2 Function 2
Network Program
Network Program
Network Program in the Packet Header
IPv6 header Source Address Locator 1 Function 1
Active Segment Locator 1 Function 1

Segment
Routing
Header
IPv6 payload TCP, UDP, QUIC
Argument shared between functions
TAG
Segments Left
“Global”
Argument
Metadata TLV
Group-Based Policy
TAG
Segments Left
Metadata TLV
SRv6 Header
TAG
Segments Left
Metadata TLV
SRv6 for anything
TAG
Segments Left
Optimized for HW processing
Locator 1 Function 1 e.g. Underlay & Tenant use-cases
Optimized for SW processing
e.g. NFV, Container, Micro-Service
Metadata TLV
SRv6 for anything
TAG
Segments Left
Turing
Metadata TLV
IETF
Lead Operators and Academia
SRv6 Architecture
SR Header
ISIS and BGP
• Lightweight extension
• ISIS: TE and FRR
• BGP: Overlay/VPN
SR Policy Architecture
Service Chaining
SD-WAN
BGP-LS
OAM and PM
Yang
SRH Insertion
#CLUS © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public
NG Mobility
3GPP standardization: TR 29.892 - CP-173160
END and END.X
END SID
• END function
• shortest-path to SID’s endpoint
• endpoint updates DA with next SID
• endpoints forwards according to updated DA 2
• 0:0:0:0:1 is commonly used for an END function
A2::1
END function
SRv6 Domain
END.X SID
• END.X function
• shortest-path to SID’s endpoint
• endpoint updates DA with next SID
• endpoint forwards to interface associated with 2 4
SID
A2::C4
• 0:0:0:0:Ck is commonly used for an END.X END.X
function where k identifies the interface function
• e.g. 0:0:0:0:C4 is the END.X of node 2 associated
with the interface to 4
SRv6 Domain
Endpoint function
SR: 〈A4::1, A6::1, A8::〉
A1 A3 A6
A1:: A3:: A6::
A5 A8
A5:: A8::
50
A2 A4 A7
A2:: A4:: A7::
Default metric 10
• For simplicity function 1 denotes the most basic function
• Shortest-path to the Node
SR FRR - TI-LFA
A2::C4
TI-LFA 2 4
100
A5::0
1
• 50msec Protection upon
local link, node or SRLG failure
6 5
• Simple to operate and understand A5::0
• automatically computed by the router’s IGP process A5::0
<50mec FRR
• 100% coverage across any topology
• predictable (backup = postconvergence) A5::/64
Pri → via 5
• Optimum backup path FRR → insert A2::C4
• leverages the post-convergence path, planned to carry the traffic
• avoid any intermediate flap via alternate path
• Incremental deployment
• Distributed and Automated Intelligence
SR Control-Plane
• No new protocol
• Lightweight extension to ISIS and OSPF
Cisco Implementation
• Leveraging the existing TI-LFA SR-MPLS code
• FCS sinced 2014
• Numerous deployments
SRTE
Distributed & Automated TE
A2::0
A3::0
MOS
2
BRU
A3::0 1
SFO NY TOK
4 5 3
FIB FIB BGP

A2::/64 → OIF MOS A3::/64 → OIF TOK Advert X/64
A3::/64 → OIF NY Advert Y/64 with Latency
• IGP minimizes cost instead of latency
Distributed & Automated TE
On-Demand distributed TE
Y/64 via A3::0 Low-Latency

X/64 via A3::0 along IGP path MOS
2
BRU
1
SFO NY TOK
4 5 3
FIB
BGP A2::/64 → OIF MOS
X/64 → A3::0 A3::/64 → OIF NY
Y/64 → A3::0 with Lat. X/64 → A3::0
Y/64 → insert <A2::1, A3::1>
• Distributed and Automated Intelligence
• Dynamic SRTE Policy triggered by learning a BGP route with SLA contract
• No PBR steering complexity, No PBR performance tax, No RSVP, No tunnel to

configure
Centralized TE
Low-Latency to 7
for application …
Input Acquisition
• BGP-LS
• Telemetry 12
<A1::1,
Policy Instantiation A2::C4, 10
2 50
4 Low Lat, Low BW
A4::C7>
• PCEP 1
7
• BGP-TE 13
3 6 5
• Netconf / Yang
Algorithm 11
14
• SR native Default ISIS cost metric: 10
DC (BGP-SR) WAN (IGP-SR) PEER
SR Control-Plane
• Same CP as SRTE for MPLS
• BGP-LS
• Telemetry
• PCEP
• BGP-TE
• YANG
• Lightweight extension to define SRv6 SID and capabilities
• Leveraging the existing SRTE MPLS code
• FCS sinced 2015
• Numerous deployments
• Centralized
• Distributed
• ODN
• Automated Steering
SR-VPN
T/64
Overlay IPv6 Hdr SA = T::1, DA = V::2 3
Payload
• Automated 1 Green Overlay

• No tunnel to configure V/64
via A2::C4
• Simple
IPv6 Hdr SA = A1::0, DA = A2::C4
• Protocol elimination IPv6 Hdr SA = T::1, DA = V::2
Payload
• Efficient
• SRv6 for everything
2
IPv6 Hdr SA = T::1, DA = V::2
Payload
4
V/64
T/64
Overlay with Underlay Control 3
Payload
• SRv6 does not only 1 Green Overlay
eliminate unneeded IPv6 Hdr SA = A1::0, DA = A3::1
V/64
overlay protocols SR Hdr < A3::1, A2::C4 > via A2::C4
IPv6 Hdr SA = T::1, DA = V::2 with Latency
• SRv6 solves problems that Payload
these protocols cannot 3

IPv6 Hdr SA = A1::0, DA = A2::C4
solve SR Hdr < A3::1, A2::C4 >
Payload
2
Payload
4
V/64
SR Control-Plane
• No new protocol
• no new SAFI
• Lightweight extension to BGP Prefix-SID attribute
• IOS-XR and IOS-XE implementations available
• Open-source BGP/RIB client for VPP
• Open-source dataplane for VPP and Linux
SR-NFV
T/64
Integrated NFV IPv6 Hdr SA = T::1, DA = V::2
3
Payload
1
• Stateless
• NSH creates per-chain state IPv6 Hdr SA = A1::0, DA = A3::A32
< A3::A32, A4::1,
Server 3
in the fabric SR Hdr
A5::A76, A2::C4 >
3
App 32
IPv6 Hdr SA = T::1, DA = V::2 Container
• SR does not Payload
• Application is SR aware or 4
Server 5
not
5
App 76
• Application can work on VM
IPv4, IPv6 or L2
2
4
V/64
T/64
Integrated NFV 3
1
• Integrated with underlay SLA
Server 3
3
App 32
Container
IPv6 Hdr SA = A1::0, DA = A4::1
SR Hdr
< A3::A32, A4::1,
A5::A76, A2::C4 > 4
IPv6 Hdr SA = T::1, DA = V::2 Server 5
Payload
5
App 76
VM
4
V/64
T/64
Integrated NFV 3
1
• Stateless
• NSH creates per-chain state Server 3
in the fabric
3
App 32
Container
• SR does not IPv6 Hdr SA = A1::0, DA = A5::A76
• App is SR aware or not SR Hdr

< A3::A32, A4::1,
A5::A76, A2::C4 > 4
IPv6 Hdr SA = T::1, DA = V::2 Server 5
• App can work on IPv4, IPv6 Payload
5
App 76
or L2 VM
4
V/64
T/64
Integrated NFV 3
1
• Integrated with Overlay
Server 3
3
App 32
Container
IPv6 Hdr SA = A1::0, DA = A2::C4 4

SR Hdr
< A3::A32, A4::1, Server 5
A5::A76, A2::C4 >
5
App 76
Payload VM
2
Payload
4
V/64
SR Control-Plane
• No new protocol
• Re-use all the SRTE Control Plane
• we said this since day1
• SR is about topology and service segments 
• IOS-XR and IOS-XE implementations available
• Open-source VPP
• Open-source Linux
Real
• Visit the SR booth at World of Solutions and enjoy demonstrations
on SRv6, TE, NFV !
More use-cases
• Spray
• SD-WAN
• 5G / Network Slicing
• 6CN: enhancing IP to search for Content
• 6LB: enhancing load-balancers
• Better flow stickiness and load distribution
• Service Pipeline
• Micro-Services
Where are we?
SRv6 timeline
First SRv6 demo: NCS 5500 Cisco Live US 2017 More to come…
Spray use-case SRv6 VPN
VPP First SRv6 HW demo ASR 1000 5G + Network slicing
ASR9k in merchant sillicon ASR 9000
SD-WAN
ASR1k VPN DP use-case NCS 5500
VPP+NFV
BGP Control Plane
Apr 2016 Mar 2017 Apr 2017 May 2017 Jun 2017 Sep 2017 2018
SRv6 VPN+NFV: Barefoot SR VPN InterOp

MPLS World Con.
VPP SRv6 VPN HW demo NCS 5500
Linux ASR 9000
ASR 1000
VPP
Linux
Barefoot
Implementations
• Cisco HW
• NCS 5500 – IOS XR
• ASR 9000 – IOS XR
• ASR 1000 – IOS XE
• Open-Source
• Linux 4.10
• FD.IO
• Barefoot HW
Linux
FD.IO
• VPN (v4 and v6)
& TE
& NFV
• Cisco HW with XR and XE
• Barefoot HW with P4 code
• FD.IO
blogs.cisco.com/sp/segment-routing-ipv6-interoperability-demo-is-already-there
• Linux
Conclusion
Segment Routing
• Strong industry support
• Fantastic deployment rate
• Bold architecture: network programming
• Numerous use-cases
• Feel free to join the lead-operator team!
Stay up to date
amzn.com/B01I58LSUO
segment-routing.net
linkedin.com/groups/8266623
twitter.com/SegmentRouting
facebook.com/SegmentRouting/
Cisco Webex Teams
Questions?
Use Cisco Webex Teams (formerly Cisco Spark)
to chat with the speaker after the session
How
1 Find this session in the Cisco Events App
2 Click “Join the Discussion”
3 Install Webex Teams or go directly to the team space
4 Enter messages/questions in the team space
Webex Teams will be moderated cs.co/ciscolivebot#BRKRST-3122

by the speaker until June 18, 2018.
#CLUS © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 135
Complete your online session evaluation
Give us your feedback to be entered

into a Daily Survey Drawing.
Complete your session surveys through
the Cisco Live mobile app or on
www.CiscoLive.com/us.
Don’t forget: Cisco Live sessions will be available for viewing
on demand after the event at www.CiscoLive.com/Online.
Continue
your Demos in
the Cisco
Walk-in
self-paced
Meet the
engineer
Related
sessions
education campus labs 1:1
meetings
Service Provider Cisco education offerings
Course Description Cisco Certification
Deploying Cisco Service Provider Network Routing SPROUTE covers the implementation of routing protocols (OSPF, IS-IS, BGP), CCNP Service Provider ®
(SPROUTE) & Advanced (SPADVROUTE) route manipulations, and HA routing features; SPADVROUTE covers advanced
routing topics in BGP, multicast services including PIM-SM, and IPv6;
Implementing Cisco Service Provider Next-
Generation Core Network Services (SPCORE) SPCORE covers network services, including MPLS-LDP, MPLS traffic
engineering, QoS mechanisms, and transport technologies;
Edge Network Services (SPEDGE) SPEDGE covers network services, including MPLS Layer 3 VPNs, Layer 2 VPNs,
and Carrier Ethernet services; all within SP IP NGN environments.
Building Cisco Service Provider Next-Generation The two courses introduce networking technologies and solutions, including OSI CCNA Service Provider ®
Networks, Part 1&2 (SPNGN1), (SPNGN2) and TCP/IP models, IPv4/v6, switching, routing, transport types, security, network
management, and Cisco OS (IOS and IOS XR).
Implementing Cisco Service Provider Mobility UMTS The three courses (SPUMTS, SPCDMA, SPLTE) cover knowledge and skills Cisco Service Provider Mobility
Networks (SPUMTS); required to understand products, technologies, and architectures that are found CDMA to LTE Specialist;
Implementing Cisco Service Provider Mobility CDMA in Universal Mobile Telecommunications Systems (UMTS) and Code Division Cisco Service Provider Mobility
Networks (SPCDMA); Multiple Access (CDMA) packet core networks, plus their migration to Long- UMTS to LTE Specialist
Implementing Cisco Service Provider Mobility LTE Term Evolution (LTE) Evolved Packet Systems (EPS), including Evolved Packet
Networks (SPLTE) Core (EPC) and Radio Access Networks (RANs).
Implementing and Maintaining Cisco Technologies Service Provider/Enterprise engineers to implement, verification-test, and Cisco IOS XR Specialist
Using IOS XR (IMTXR) optimize core/edge technologies in a Cisco IOS XR environment.
For more details, please visit: http://learningnetwork.cisco.com

Questions? Visit the Learning@Cisco Booth
Thank you
#CLUS
#CLUS
APPENDIX
SRv6 domain and its
Security
SR Domain
• The set of trusted nodes
participating in the SR solution area area
• May be organized in multiple

IGP areas and BGP AS AS
AS
SRv6 Domain
Domain Blocks
• The SR domain has
Classic
• a classic address block (e.g. B::/4) address Block
• a SID block (e.g. A::/4) B::/4
SID Block
A::/4
SRv6 Domain
Trust inside the domain
• Any source A inside the domain can inject Z
SR traffic using any SID of the domain
• via SID list <S1, S2, S3> S2
S3
S1
(A, S1)(Z, S3, S2, S1, SL=3)
External traffic is not trusted Z
• Any external source A cannot

leverage the SID’s of the domain
• Any border router drops any external S2
traffic destined to its blocks S3
• A::/4 and B::/4
S1
(A, S1)(Z, S3, S2, S1, SL=3)
SRv6 SID structure
SID structure
• Any (location, function) structure is possible
• the locator identifies the endpoint of the SID
• the function is opaque to nodes other then the endpoint of the SID
• In this document, we assume (loc in 48 bits, funct in 80 bits)
Node’s classic address
• An SR node has
a classic routed address Classic
address
• B2::/128 is routed to node 2 B2::/128
SRv6 Domain
Node’s SID block
• An SR node has a routed SID block
• A2::/48 is routed to node 2
• Explicit SID’s are instantiated within the block
A2::/48 2
• A2::1/128 is a SID of node 2 Node’s
SID block
A2::/48
SRv6 Domain
Short Representation of a SID list
• <S1, S2, S3, Z>
• first to S1
• then to S2
• then to S3
• and finally to Z
Short representation of an SR packet
• (A, S1)((Z, S3, S2, S1; SL=3)
• IPv6 source address: A
• IPv6 destination address: S1
• SRH
• SID list <S1, S2, S3, Z>
• Segments Left = 3
Miscellaneous
• A SID is different than an address of an interface
• A node may receive a packet with an SRv6 SID in the DA without an
SRH. In such case the packet should still be processed by the
Segment Routing engine.
SPRAY
Vector Packet Processing
• Extensible framework that provides out-of-the-box production quality
switch/router functionality (dataplane only)
• We’ve implemented the entire SRv6 Network Programming on it
Extremely
Open Source
fast
Packet Runs on
processing commodity
stack CPU
Spray GW1
C::1
Spray Policy 1: <B2::1, B4::1, M1> CMTS4

4
Spray Policy 2: <B3::1, B5::1, M1>
Unicasted GW3
Content VPP1 2
C::3
Provider B::1
Replicate traffic to every CMTS 3

CMTS5
through TE-Engineered core 5
path then to access mcast tree
then to anycast TV GW5
C::5
Peering to Content Provider SRv6 domain (Unicast) Multicast domain
SRv6 node Non SRv6 node Subscribed to M1 channel
Flexible, SLA-enabled and efficient content injection without multicast core

Spray + Service Pipeline GW1
C::1
CMTS4
BSID A3::10 4
(Spray):
SR Policy: <A2::1, A3::10, <B2::1, B4::1>
M1> <B3::1, B5::1>
GW3
Content VPP1 VPP3 2 C::3
Provider A1:: A3::
VPP2
A2::
3 CMTS5
Perform video transcoding 5
GW5
C::5
Peering to Content Provider SRv6 domain (Unicast) Multicast domain
SRv6 node Non SRv6 node Subscribed to M1 channel
Efficient distribution with flexible video processing

Binding SID
• A Binding SID is a unique ‘alias’ of an SR policy. *
• If a packet arrives with the BSID, then the SR policy is applied on such packet
• Several Binding SIDs may point to the same SR policy
• Upon topology changes within the core of the network, the low-latency path may
change. While the path of an intermediate policy changes, its BSID does not change.
• Provides scaling, network opacity and service independence.
• A BSID acts as a stable anchor point which isolates one domain from the churn of
another domain.
#CLUS BRKRST-3122
* Naïve definition of a BSID
© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 158
SD-WAN
SD-WAN
• Delegates the application recognition and policy decision to the
Entreprise who knows better when an application needs a non-
default path and which non-default path is needed
• NFV service chaining and Traffic-Engineering policies can be
integrated in a SR policy
• Applicability to both SR-MPLS and SRv6
• To simplify, let’s focus on
• TE/SLA policy
• SRv6
Default versus BW versus Latency
• Lisbon (1) to Athens (7)
• Default
• <A7::>
Default
4
• BW: Guaranteed 50Mbps
• <A10::1, A11::1, A7::> 3
• BSID: A1::999:2
5
• Low-Latency 10 6
• <A9::1, A7::>
2 11
• BSID: A1::999:3
1 BW
A1::999:1 7
8 9
A1::999:2
Latency
App needs best-effort
Site 2
App 1 needs default
push no BSID
E1 E2
• E1 encrypts the inner packet and encapsulate in outer packet to E2

• E1 does not push any BSID
App needs guaranteed BW
Site 2
push A1::999:2
App 2 needs 10Mbps
E1 E2

• E1 pushes A1::999:2
• The network provides the guaranteed BW service to App2
App needs low-latency
Site 2
push A1::999:3
E1 E2
App 3 needs low-latency

• E1 pushes A1::999:3
• The network provides the low-latency service to App3
Disjointness
push A1::999:4
Flow 4A
E1 E2 Site 2
Flow 4B
push A1::999:5
• App 4 needs flow F4A and F4B to reach site 2 via disjoint paths
• E1 encrypts the inner packets and encapsulate in outer packet to E2
• For F4A, E1 additionally pushes A1::999:3
• For F4B, E1 additionally pushes A1::999:4
Binding SID is crucial in SD-WAN
• Identifier for a customized SLA per application per Entreprise
• Secured
• Per-BSID counters for usage-based billing
• Delegates the application recognition and policy

decision to the Entreprise who knows better when an
application needs a non-default path and which non-
default path is needed
Performance monitoring
• Enterprise-based
• Enterprise can easily monitors each individual service
• Simply sends the probes with the related BSID
• Service Provider-based
• The SP can enable per-SR-policy performance monitoring (latency/loss)
• These metrics can be leveraged by SDWAN controller and provided to
the Enterprise
• BSID Metadata to select which application to steer
5G and Network Slicing
Current mobility networks
• Well fragmented RAN, EPC, SGi
Does not scale to 5G requirements:
• Inefficient data paths
• Increased number of connected devices
• Protocol stack gets large
• Ultra-low latency
• Per-session tunnel creation • Network slicing
• Mobile edge computing
• Per-mobility event tunnel handling
SGW
PGW
SGW
UE eNB L2 Anchor L3 Anchor Service Functions Internet
SRv6 for mobile user-plane
• What about if SRv6 becomes an alternative to GTP-U?
• Removing the per-session tunneling has obvious benefits
• Optimal data path (ultra-low latency)
• Service chaining integrated within the same architecture
• Network slicing simply becomes a set of SIDs

• Achieved either via a centralized SDN solution or via SR TE with IGP FlexAlg
• Optimal resource utilization
• Good progress standardizing SRv6 for mobile user-plane

• IETF: draft-ietf-dmm-srv6-mobile-uplane-00
• 3GPP: Accepted study item in CT4 (#29.892)
SRv6
Multi-cloud use-case
• Objective is to connect several public clouds in different regions using the internet (plain IPv6) as
underlay
• SRv6 for the overlay and service chaining only
• VPP deployed as virtual private cloud gateway
Cloud provider B in region 2
snort
Cisco
ASAv
VPP
Cloud provider A in region 1
iptables
Internet
Server Server
1
VPP VPP 2
All nodes in green are SRv6 capable

Cloud provider B in region
2
snort
4 Cisco
ASAv
VPP
C2
IPv6 Hdr SA = C1::, DA = C2::C4 IPv6 Hdr SA = C1::, DA = C3::C2

SR Hdr ( C3::C2, C2::C4 ) SL=1 SR Hdr ( C3::C2, C2::D3 ) SL=0
IPv4 Hdr SA=1.1.1.0, DA=2.2.2.2 IPv4 Hdr SA = 1.1.1.0, DA = 2.2.2.2 IPv4 Hdr SA = 1.1.1.0, DA = 2.2.2.2 IPv4 Hdr SA=1.1.1.0, DA=2.2.2.2
Payload Payload Payload Payload
Internet iptables
Server VPP VPP Server

1 C1 C3 2
All nodes in green are SRv6 capable


Brkrst-3122 (Flex Algo SR)

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Brkrst-3122 (Flex Algo SR)

Загружено:

Авторское право:

Доступные форматы

#CLUS

• SR IGP Flex Algo

Webex Teams will be moderated cs.co/ciscolivebot#BRKRST-3122

Strong customer De-facto SDN Standardization Multi-vendor Open Source

• End-to-End Unified SR Fabric

• Leverages the SRTE benefits of simplicity and automation

Ease of configuration and operational management, ability to

Arkadiy Gulko - Thomson Reuters

• Each node advertises its ALGO capability

Node 9 advertises Alg128

Node 9 advertises loopback0 1.0.0.9/32 with

• If so, the first step is to define the topology of K

• Nodes advertise a Prefix SID 8 7

7 16909 Flex-Algo 129

• Node 1 does not install Prefix-SID

The usage of Algo-128 Prefix-SID 16803 ensures that the

0 16009 (Cost) 9 0 16809 (delay) 9

• SRTE Automated Steering is leveraged for IGP Flex-Algo

“Any 100-colored BGP route should be steered

• Or leverage a solution such as NSO to ensure the domain-wide consistency of the

• The delay of each link is reported in drawing

2/8: push <16805, 16809> 0 1 1 1 9

• Automation and Simplicity

34 Min/Max Unidirectional Link Delay

35 Unidirectional Delay Variation

• RFC 7810 (IS-IS Traffic Engineering (TE) Metric Extensions)

27 Unidirectional Link Delay

28 Min/Max Unidirectional Link Delay

29 Unidirectional Delay Variation

• RFC 7471 (OSPF Traffic Engineering (TE) Metric Extensions)

• One Way Delay = (T2 – T1)

Source MAC Address

• Every 30 seconds, a probe

• Every 120 seconds, an aggregation

• SRTE optimization only needs minimum delay

Support 5G growth Support container adoption for

SRv6 for Underlay Simplification, FRR, TE, SDN

IPv6 for reach

NSH for NFV Additional Protocol and State

UDP+VxLAN Overlay Additional Protocol just for tenant ID

SRv6 for Underlay Simplification, FRR, TE, SDN

IPv6 for reach

• Multiplicity of protocols and states hinder network economics

• 128-bit SRv6 SID

Locator Function Args*

• 128-bit SRv6 SID

Next Segment Locator 2 Function 2

Next Segment Locator 3 Function 3

IPv6 header Source Address Locator 1 Function 1

Active Segment Locator 1 Function 1

IPv6 payload TCP, UDP, QUIC

3GPP standardization: TR 29.892 - CP-173160

SR: 〈A4::1, A6::1, A8::〉

• For simplicity function 1 denotes the most basic function

• Shortest-path to the Node

FIB FIB BGP

• IGP minimizes cost instead of latency

Y/64 via A3::0 Low-Latency

• Distributed and Automated Intelligence

• No PBR steering complexity, No PBR performance tax, No RSVP, No tunnel to

• Automated 1 Green Overlay

these protocols cannot 3

• Application can work on VM