MPLS SDN 2015 - SPRING interoperability testing

SPRING
Interoperability testing report
Stéphane Litkowski, Network Architect and Orange Expert

2
Agenda
1. Orange & Segment Routing
2. Proof of Concept (POC)
3. Summary of tests
4. Conclusion

3
Orange Business Services interest on SR
 Fast & good reaction to failure
– Fast reroute thanks to TI-LFA
– IGP micro loop avoidance
 Tactical TE
– Using PCE

4
Why Fast ReRoute ?
 More and more applications are carried over IP/MPLS networks
– as IP/MPLS networks become the only network
– as applications moves from LAN to WAN/cloud
 Some applications are more sensitive to consecutive packets loss
 We must find a cure:
– Fast(er) IGP convergence
– “It’s never enough”
– FRR
Convergence
time
Timeline
LoCt with FRR
time
Timeline

5
Why Topology Independent LFA (TI-LFA)?
 Provides 100% coverage for link and node protection.
 During FRR, enforce the post convergence path from the PLR
to each destinations.
– FRR path is easier to manage (see draft-ietf-rtgwg-lfa-
manageability)
– FRR path is de facto well sized
– FRR path is predicatable

6
Topology Independent LFA applicability
 Directly applicable to all IGP destinations
– Prefix Segments (SR), LDP FECs (MPLS), IGP prefixes (IP)
 Incremental deployment possible
 Number of labels to push is reasonable in Orange ASes
– See my MPLS SDN 2014 talk !

7
Agenda
3. Summary of tests
4. Conclusion

8
PoC high level goals
 Segment Routing base interoperability with 3 vendors
– Cisco (IOS XR, ASR9k)
– Alcatel Lucent (SROS, 7750)
– Juniper (JunOS, MX)
– This testing was performed using early codes from all vendors
 Fast-reroute use case with Segment Routing*
 Two POCs set up
– 2 sites/teams
* not available on all early codes

9
POC#1 topology
E A
F B
D
Tester
C
Tester
 Vendors :
– A&B are Cisco
– E&F are Juniper
– C&D are Alcatel Lucent
 Segment Routing control plane : IS-IS
 Segment Routing data plane : MPLS
 MPLS LER & LSR :
– Flows : VPN-IPv4, VPN-IPv6,
L2VPN, Internet (IPv4 and 6PE)

10
 Vendors :
– A&B are Cisco
– G,E,F are Juniper
– C is Alcatel Lucent
 Segment Routing control plane : IS-
IS
 Segment Routing data plane : MPLS
 MPLS LSR function only
 Own SR code developed for
testing all flags and fancy topologies
POC#2 topology
A B
C
G E F
Tester
Tester
SR
simulator
Tester

11
 Goal : ensure IS-IS extensions are correctly populated and
interpreted as defined at IETF
 All implementations supports the minimum set of extensions to
build a live segment routing network : Prefix-SID, Node-SID,
Adj-SID LAN and p2p.
 All implementations are interworking correctly at control plane
level
Control plane testing Works well
!

12
root@juniper> show isis database
CISCO.00-00 Sequence: 0x1b6, Checksum: 0x741a, Lifetime: 64492 secs
…
TLVs:
Authentication data: 14 bytes
Area address: 49.0001 (3)
Speaks: IP
Hostname: A
IP address: 1.1.1.1
Router Capability: Router ID 1.1.1.1, Flags: 0x00
SPRING Capability - Flags: 0x80, Range: 8000, SID-Label: 16000
IS extended neighbor: TSTP1.00, Metric: default 500000
IP address: 10.166.0.9
Neighbor's IP address: 10.166.0.10
P2P IPV4 Adj-SID - Flags:0x30, Weight:0, Label: 24002
IS extended neighbor: TSTJ1.00, Metric: default 700000
IP address: 10.166.0.21
IS extended neighbor: TSTR2.00, Metric: default 1000000
IP address: 10.166.0.61
IP extended prefix: 1.1.1.1/32 metric 0 up
8 bytes of subtlvs
Node SID, Flags: 0x40, Algo: SPF(0), Value: 4
IP extended prefix: 101.1.0.0/24 metric 1000000 up
No queued transmissions
Control plane testing Juniper router learning
CISCO SR informations

13
 Goal :
– ensure MPLS dataplane is correctly populated
– Ensure forwarding for both Adj-SID and node-SID is working
well
– Ensure we can combine any SID in a label stack
– Ensure ECMP works with node-SID
Forwarding plane testing Works well
!

14
Forwarding plane testing
Simulating a crazy path
 Forwarding plane works fine on all implementations, we can
combine any segment to create fancy paths :
A B
C
D E F
Tester
Tester
500 500
50
50 50
700 700
24022
131043
300144
ETH
24022
131043
16004
16001
300144
800004
IP
Adj SID
SRGB start
16000, Index 6
SRGB start
16000, Index 5
SRGB start
800000, Index 3
SRGB start
800000, Index 2
SRGB start
800000, Index 1
SRGB start
16000, Index 4
Tested with
more than
10 labels in
the stack
16003

15
 ECMP works fine up to a certain stack depth (seen on all
implementation) :
ECMP with Prefix-SID
A B
C
D E F
Tester
Tester
500 500
50
25 25
700 700
24018
SRGB start
16000, Index 6
SRGB start
16000, Index 5
SRGB start
800000, Index 3
SRGB start
800000, Index 2
SRGB start
800000, Index 1
SRGB start
16000, Index 4
300640
24002
ECMP 
ETH
16005
24018
300640
800003
IP
Adj SID
Expected
behavior

16
 ECMP works fine up to a certain stack depth (seen on all
implementation) :
A B
C
D E F
Tester
Tester
500 500
50
25 25
700 700
24018
ETH
16005
24018
300640
800004
24002
800002
IP
Adj SID
SRGB start
16000, Index 6
SRGB start
16000, Index 5
SRGB start
800000, Index 3
SRGB start
800000, Index 2
SRGB start
800000, Index 1
SRGB start
16000, Index 4
800003
300640
24002
No ECMP 
Expected
behavior
Purely theorical test

17
 Implementations can inspect only up to a certain label stack
depth
 This is a theorical limitation that service provider may not face
in a real deployment :
– Shortest path only requires one segment
– Fast-reroute requires one segment in more than 95% of cases
– First analysis on Traffic Engineering shown that few segments
may be required (topology dependent)
 Entropy label usage provides even more confidence (no need
of deep inspection)
Ready for
deployment

18
 Goal :
– ensure that IPFRR works well with SR path
– ensure that LDP traffic can be protected by SR
– evaluate TILFA when available
Fast reroute testing

19
RLFA using SR path
A B
D E F
Tester
Tester
500 500
50
700 100
SRGB start
16000, Index 5
SRGB start
800000, Index 3
SRGB start
800000, Index 2
SRGB start
800000, Index 1
ETH
800004
IP
SRGB start
16000, Index 4
Primary path
stack
rLFA FRR path
stack
ETH
800004
IP
800001
PQ
Works well
!
slitkows@F> show route table mpls.0 label 800004
mpls.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
800004 *[IS-IS/18] 00:12:34, metric 550
> to 1.0.0.5 via ge-5/0/0.0, Swap 16004
to 1.0.0.1 via ge-0/1/3.0, Swap 800004, Push 800001(top)

20
TILFA enforcing postconvergence path
Works well
!
A B
D F
50k
500k
700k
500k 600k
R Simulated node advertising prefixes
1.0.0.0/32 -> index 17
1.0.0.1/32 -> no PrefixSID
1.0.0.2/32 -> Index 19
1.0.0.3/32 -> no PrefixSID
 Router « R » owns both SR
and non-SR prefixes
 In case of A-D link failure,
traffic should flow through
ABDR path
PQ
Expected protection path for
non SR prefixes : ABFDR
(remote LFA)
Expected protection path for SR
prefixes : ABDR (TILFA using
postconvergence path)
P
Q
L2 1.0.0.0/32 [502/115] low priority
via 10.166.0.22, TenGigE0/0/0/0, D, SRGB Base: 800000, Weight: 0
TI-LFA backup via B (P) [3.3.3.3], D (Q) [1.1.1.1]
via 10.166.0.62, TenGigE0/0/0/2 B, SRGB Base: 16000
Label stack [ImpNull, 16507, 800017]
src R.00-00, 0.0.0.0, prefix-SID index 17, R:0 N:0 P:1 E:0 V:0 L:0
L2 1.0.0.1/32 [502/115] low priority
Remote FRR backup via F [4.4.4.4], via 10.166.0.62, TenGigE0/0/0/2 B, SRGB Base: 16000,
Weight: 0
Label stack [16002, None]
src R.00-00, 0.0.0.0
L2 1.0.0.2/32 [502/115] low priority
TI-LFA backup via B (P) [3.3.3.3], D (Q) [1.1.1.1]
via 10.166.0.62, TenGigE0/0/0/2 B, SRGB Base: 16000
Label stack [ImpNull, 16507, 800019]
src R.00-00, 0.0.0.0, prefix-SID index 19, R:0 N:0 P:1 E:0 V:0 L:0
L2 1.0.0.3/32 [502/115] low priority
Remote FRR backup via F [4.4.4.4], via 10.166.0.62, TenGigE0/0/0/2 B, SRGB Base: 16000,
Weight: 0
Label stack [16002, None]
src R.00-00, 0.0.0.0

21
TI LFA with ECMP protection path
 Fancy topologies to have TI LFA use per ECMP paths
Works well
!
And …
E A
F B D
Tester
C
Tester
5
5
70
70
50
200
6 parallel
adjacencies
P Q
ETH
16003
IP
Primary path
stack
SRGB start
16000, Index 3
SRGB start
16000, Index 4
SRGB start
16000, Index 2
SRGB start
800000, Index 5
SRGB start
800000, Index 6
TILFA FRR path
stack
ETH
Adj-SID
IP
800006
16003
?

22
TI LFA with ECMP protection path : choice of Adj-SID
 Per prefix FIB loadsharing
BF
24212
24213
24214
24215
24217
24216
TILFA FRR path
stack
ETH
24212
IP#1
800006
16003
ETH
24213
IP#2
800006
16003
ETH
24214
IP#3
800006
16003
InLabel Outlabel OutInterface
24212 Pop If1
24213 Pop If2
24214 Pop If3
…

23
TI LFA with ECMP protection path : choice of Adj-SID
 Use Bundle-Adj-SID (S flag)
BF
24212 / 300
24213 / 300
24214 / 300
24215 / 300
24217 / 300
24216 / 300
TILFA FRR path
stack
ETH
300
IP#1
800006
16003
Each interface has two Adj-SIDs
InLab
el
Outlab
el
OutInterface
300 Pop Loadbalance If1,If2 … If6
24212 Pop If1
24213 Pop If2
Not
implemente
d

24
TI LFA with a lot of protection lists
 Fancy topologies to have TI LFA use per destination protection
lists
A B
D F
T
1
T
2
R
1
RZ
1
R3
0
RZ
30
500 500
500500
1
1
10M
…
Simulated topology,
30 different chains,
30 different P and Q
PQ
PQ
R1
TI-LFA backup via RZ1 (P) [1.0.0.51], R1 (Q) [1.0.0.11]
R2
R3
…
R7
Node-SID
Adj-SID
Works well
!
10M
1
1
50

25
Agenda
3. Summary of tests
4. Conclusion

26
Good Interoperability results!
 Good interoperability on base Segment Routing features
– Node/prefix segment, adjacency segment, SR capability (SRGB)
– Even though the specification is young and 3 beta implementations were used
 Some minor points to mention that does not prevent deployments :
– Adjacency-SID bundle/set are not implemented by anyone
– Few bugs on all codes and very reactive corrections (early codes used, so it was
expected)
– Few CLI enhancements required for better manageability
– FRR could be optimized to manage ECMP (inherent to FRR, not SR)
 LDP – SR interop is not widely implemented yet
 Using the same SRGB on all nodes would be very useful but is not yet available
– to simulate domain wide labels, especially as SR stacks multiple labels from
multiples nodes hence has more labels to troubleshoot.
– Option 1: Having all vendors agree on the same default??
– Option 2: Having a (fully) configurable SRGB on all implementations/plateform?

27
Agenda
3. Summary of tests
4. Conclusion

28
Wrap up (past to present)
 Segment Routing gets real
– IETF specifications (WG documents): RIP IETF fights (?)
– PoC with 3 interoperable implementations (more available)
industry is following
 Fast Reroute use case available !
– SR-based rLFA or TILFA
 Production codes are there
 Segment Routing can be deployed now on a live
network !
 Congrats to all vendors !

29
Wrap up (futur)
 Some polishing to improve base SR :
– core spec required for interoperability need to be stable now.
– Implementations are here, let's not make them non
compatible.
– prefix SID, adjacency SID, mapping-server, SR capability
– Need to clarify mapping-server behaviors
 Then tactical TE … (testing planned in 2015)
 And more … : micro loop avoidance, OAMs, path repair …
 Working also on YANG model for SR configuration/operation

31
Summary of tests
Category Test
Control plane Prefix SID P/E flags change 
Control plane Prefix SID N flag 
Control plane Prefix SID algorithm change , whatever the value of Algoritm, SPT is
computed
Control plane Prefix SID IPv6
 not supported by some vendor (not a use
case for us)
Control plane Adjacency SID P2P 
Control plane Adjacency SID LAN 
Control plane Adjacency SID Link flaps 
Control plane Mapping Server SID binding advertisement & reception

interoperability issue due to implementation of
different versions of the draft. This has been
fixed during the testing.
Control plane Mapping Server SID active/backup 
Control plane Mapping Server: adding/removing ranges 
Control plane
Mapping Server SID overlapping ranges on different
nodes
, behavior is not very clear to us, and
clarification are required at IETF level for
interoperability

32
Summary of tests
Category Test
Forwarding plane LSR forwarding Prefix SID (with different P, E flags) 
Forwarding plane LSR forwarding Adjacency SID 
Forwarding plane LSR forwarding combination of segments 
Forwarding plane LSR forwarding ECMP Prefix SID 
Forwarding plane LSR forwarding ECMP Prefix SID with high depth stack
, implementations are not ready now
to perform IP inspection when stack depth
is high
Forwarding plane
LSR : SR to LDP traffic through mapping server 
Forwarding plane LSR : LDP to SR traffic through mapping server 
Forwarding plane LER IP VPN (v4&v6) service over SR 
Forwarding plane
LER Ethernet VPN (VPLS, VPWS, VPWS+Fat PWE)
over SR 
Forwarding plane LER IP (v4&6PE) service over SR 
Forwarding plane LER : LDP as default transport protocol 
Forwarding plane LER : transport protocol preference change to SR 

33
Summary of tests
Category Test
Fast reroute TILFA, post-convergence path is LFA 
Fast reroute TILFA, post-convergence path has a PQ 
Fast reroute TILFA, post-convergence path has disjoints P Q nodes 
Fast reroute TI LFA, P and Q disjoints, ECMP to P 
Fast reroute TI LFA, P and Q disjoints, ECMP between P and Q  load sharing is done by programming
different Adj-SID for each prefix
Fast reroute TI LFA protection of IP destinations  works only if prefix has a SID through
Mapping Server
Fast reroute TI LFA protection of LDP traffic 
Fast reroute TI LFA , different P and Q for each destination 
Fast reroute TI LFA protecting SR, and fallback to LFA for non SR prefixes 
Fast reroute TI LFA protecting SR, and fallback to rLFA for non SR prefixes 
Fast reroute
TI LFA protecting SR, and fallback to LFA for P non SR
compliant 
Fast reroute rLFA using SR 
Fast reroute PLR Cisco, P Cisco, Q ALU 
Fast reroute PLR Cisco, P ALU, Q ALU 
Fast reroute PLR Cisco, P Juniper, Q Cisco 

MPLS SDN 2015 - SPRING interoperability testing

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to MPLS SDN 2015 - SPRING interoperability testing

Similar to MPLS SDN 2015 - SPRING interoperability testing (20)

Recently uploaded

Recently uploaded (20)

MPLS SDN 2015 - SPRING interoperability testing