The document discusses the evolution of Software-Defined Networking (SDN) and the integration of Segment Routing (SR) for improved programmable and application-aware multilayer networking. Segment Routing addresses operator needs by simplifying network operations, optimizing costs, and providing flexible end-to-end path definitions through segments. It also highlights ongoing collaboration and draft submissions to IETF for implementing necessary extensions in routing protocols like IS-IS and OSPF.

1. SDN with SR - evolution rather than
revolution
Programmable & Application aware
multilayer networking with Segment
Routing
Jeff Tantsura
1

2. 2
You are here…

3. 3
SDN Falls
Is this the future?

4. Decentralized
4
Decentralized
Centralized

5. 5

6. 6
You are here

7. 7
Where
do we
go from
here?

8. SDN ambitions
service provider expectations(2012)
8

9. SDN ambitions
service provider expectations(2013/14)
9

10. Open flow and unicorns in
networking
10
NFV possibilities

11. There is no Silver Bullet
for Complexity
11
C≤1/R
Impossible!

12. We need to separate
policy from reachability
12
!=

13. Logically centralized,
physically distributed !
“If you can’t explain it simply, you don’t understand it well
enough ”
Albert Einstein
13

14. SR addresses operator’s needs &
makes SDN promises true
› Faster TTM, simplification
– Programmability and Application awareness
› OPEX reduction
– Removes complexity from the network, no LDP/RSVP, state is in the
packet, fully automatic 100% IP FRR coverage, native IPv6
› CAPEX optimization
14
– Investment protection - can be used with the existing equipment, only
SW upgrade needed (HW on ingress in some cases)
› Packet/Opto integration
– Coherent multilayer resource provisioning and dynamic reoptimization
– On demand bandwidth and admission control
– Connection-oriented connectivity, carrier grade OAM

15. Sr Is Real and
happening!
› Excellent endorsement and leadership
from SP and Entreprise operators
› IETF: Multi-vendor consensus and collaboration:
IS-IS for IP Internets S. Previdi, Ed.
Internet-Draft C. Filsfils
Intended status: Standards Track A. Bashandy
Expires: December 20, 2014 Cisco Systems, Inc.
– Stefano Previdi - Cisco
– Jeff Tantsura - Ericsson
– Wim Hendericks - ALU
– Hannes Gredler - Juniper
› We have submitted detailed IETF drafts:
15
– Architecture
– Use-cases
– ISIS extensions
– OSPF extensions
– BGP extensions
– PCEP extensions
– FRR with 100% coverage
H. Gredler
Juniper Networks, Inc.
S. Litkowski
B. Decraene
Orange
J. Tantsura
Ericsson
June 18, 2014
IS-IS Extensions for Segment Routing
draft-ietf-isis-segment-routing-extensions-02
Abstract
Segment Routing (SR) allows for a flexible definition of end-to-end
paths within IGP topologies by encoding paths as sequences of
topological sub-paths, called "segments". These segments are
advertised by the link-state routing protocols (IS-IS and OSPF).
This draft describes the necessary IS-IS extensions that need to be
introduced for Segment Routing.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any

16. Abstract Routing
Model
draft-filsfils-rtgwg-segment-routing
16

17. Segment Routing
› Segment Routing (SR) leverages the source routing and
tunneling paradigms.
› A node steers a packet through a controlled set of
instructions, called segments, by prepending the packet
with an SR header.
› A segment can represent any instruction, topological or
service-based.
17

18. IGP Node Segment
A
B C
N O
D
P
› Z advertises its global node segment
18
Z
65
– simple ISIS sub-TLV extension
– simple OSPF Opaque sub-TLV extension
A packet injected
anywhere with
active segment 65
will reach Z via
ecmp-aware
shortest-path
› All remote nodes install the node segment to Z in the SR dataplane along
the shortest path to Z
draft-ietf-isis-segment-routing-extensions
draft-psenak-ospf-segment-routing-extensions

19. IGP Adjacency Segment
A B C
M N O
Z
D
P
9003
A packet injected at node
C with active segment 9003
is forced through the link
C->O
65
› C allocates a local segment for its datalink adjacency CO
› C advertises the adjacency segment in the IGP
19
– Simple ISIS sub-TLV extension
– simple OSPF Opaque sub-TLV extension
› C is the only node to install the adjacency segment in SR dataplane
draft-ietf-isis-segment-routing-extensions
draft-psenak-ospf-segment-routing-extensions

20. A path with Adjacency
Segments
› Source routing along any explicit path
– stack of adjacency labels
› SR provides for entire path control
20
B C
N O
Z
D
P
A
9101
9105
9107
9103
9105
9101
9105
9107
9103
9105
9105
9107
9103
9105
9107
9103
9105
9103
9105
9105

21. Combining Segments
› Source Routing
› ABCOPZ is expressed as {72, 9003, 65}
21
A B C
M N O
Z
D
P
9003
72 72
65
65

22. Cross domain controller
segmented and hierarchical
22
Cross Domain Orchestration
Sites Subscribers Services VM’s
BGP-LS-SR
Inter domain
AAA
PCRF
SDN
CTL
SDN
CTL
Edge DC
Fabric
DC
Orch.
DC
Compute
Service Level – Inter-domain
Hierarchical
Residential
SDN
CTL
Router
SDN
CTL
Router
Inter Area
IP/MPLS Transport Service Edge DataCenter
3G/LTE
DSL
GPON
PE
CE
Business
Router Router
Segment routing domain in focus today

23. 23

24. OpenDaylight Project
Goals
§ Code: To create a robust, extensible, open source code base that covers
the major common components required to build an SDN solution and create
a solid foundation for Network Functions Virtualization (NFV)
§ Acceptance: To get broad industry acceptance amongst vendors and
users
§ Community: To have a thriving and growing technical community
contributing to the code base, using the code in commercial products, and
adding value above, below and around.
24
2
4

25. OpenDaylight
Momentum
25

26. How Does This
Compare?
26

27. Broad Industry Support
for OpenDaylight
27
2
7

28. ODL: BGP processing
28
Controller
MD-SAL Notification MD-SAL Set MD-SAL Get
MD-SAL
BGP-LS-SR
RESTCONF
/operational
BGP-­‐RIB
/operational
Topology
BGP-LS Topology
Exporter
MD-SAL Set
Application
(Topology Consumer)
BGP-LS-SR
speaker (RR)
draft-ietf-idr-ls-distribution
draft-gredler-idr-bgp-ls-segment-routing-extension

29. ODL: PCEP processing
29
Controller
MD-SAL Notification MD-SAL Set MD-SAL Get
MD-SAL
PCEP
RESTCONF
/operational /operational
Topology
PCE
MD-SAL Set
Applications
(topology/constrains/feedback)
PCEP speaker
(ingress)
H-PCE
I2RS/OF/other SBI’s
draft-sivabalan-pce-segment-routing
draft-ietf-pce-stateful-pce
draft-ietf-pce-pce-initiated-lsp

30. 30
I want a path from
A to F
Min link BW=10G
Min link delay < 10ms
A->F Topology
A->B->D->F
A->C->E->F
Link BW Delay
A->B 10G 10ms
B->D 200G(SRLG) 15ms
D->F 10G 10ms
Link BW Delay
A->C 10G 5ms
C->E 100G 10ms
E->F 10G 10ms
SR
PCEP
->C->E->F
SDN Orchestration

31. 31
I want a non-constrained
path
from A to F
Optimize BW use
== UCMP
A->F Topology
A->B->D->F
A->C->E->F
Link BW Delay
A->B 10G 10ms
B->D 200G(SRLG) 15ms
D->F 10G 10ms
Link BW Delay
A->C 10G 5ms
C->E 100G 10ms
E->F 10G 10ms
SR
PCEP
->{B,C}->F
SDN Orchestration

32. SDN Orchestration: analytics
realtime feedback reoptimization
32
My link
towards F is
overloaded
A->F Topology
A->B->D->F
A->C->E->F
Link BW Delay
A->B 10G 10ms
B->D 200G(SRLG) 15ms
D->F 10G 10ms
Link BW Delay
A->C 10G 5ms
C->E 100G 10ms
E->F 10G 10ms
SR
PCEP
->B->D->F

33. Glue between OF & IP/Mpls
networks
33 App App App Ericsson SDN
OpenDaylight APIs (REST)
RR
L1 L2 L3 L11 L12 L13
Segment routing domain
App App App
Base Network Service Functions
Service Abstraction Layer (MD-SAL)
SR logic
BGP
Stateful
PCE
L3
Controller
OFx.x NETCONF
OF1
R3
OF2
OF3
BGP-LS/ PCEP
R1 R2
I want a path
from OF1 to R3
for FEC “XYZ”
SR OF
(OF1-L1,
OF2-L2
OF3-L3)
PCEP
OF
SWAP L13 by L13
LFIB
SWAP L13 by L13
SWAP L13 by L13
LFIB
SWAP L13 by L13 LFIB
POP L13
OF ISIS/OSPF
MATCH FEC XYZ

34. IP/MPLS + Optical interworking
brings connection-oriented transport
into connectionless IP/MLPL world
34
App App App Ericsson/Ciena SDN
Controller
OpenDaylight APIs (REST)
Stateful
PCE
L0-L2
OFx.x NETCONF FUTURE
IP
MPLS
IP
MPLS
IP
MPLS
IP
MPLS
ROADM
Stateful
PCE
L3
TL1
IP
MPLS
Netconf
ROADM ROADM
ROADM
Segment routing domain
OPTO PATH
RR
App App App
Base Network Service Functions
Service Abstraction Layer (MD-SAL)
VNTM
Manager
PCEP BGP
IP
MPLS
IP
MPLS
ROADM ROADM

35. US tier 1: SR Core SDN + OF Edge
use case
35
MP-BGP(LS,RFC3107)
Core
MLWC CNC
Edge
SDN
BGP-LS MP-BGP(LS,RFC3107)
IP
Core
IP
Core
IP
Core
IP
Core
ROADM
IP
Core
ROADM ROADM
ROADM
MLWC
RR
Segment routing domain
Edge
SDN
Silver LSP
CNC MLWC
Cross Domain Orchestration
DC DC

36. More information
› IETF WG covering Segment Routing
– SPRING - http://tools.ietf.org/wg/spring/
› Relevant protocol extensions are defined in OSPF and ISIS
WG:
36
– https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/
– http://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-
02
– https://datatracker.ietf.org/doc/draft-psenak-ospf-segment-routing-ospfv3-
extension/

37. Q&A?
37

38. 38