But
when
it
comes
to
Hardware
switches,
misconcep4ons
abound
•
OpenFlow
is
not
mature
•
OpenFlow
does
not
work
with
current
hardware
•
OpenFlow
does
not
scale
Motivation: ONF Point of View SDN/OpenFlow
successful
•
in
DataCenters
•
with
So@ware
Switches
•
and
Overlay
networks
SPRING-OPEN Project Goals 1. Demonstrate
maturity
and
scale
of
the
ONF
work
product
in
hardware
readily
available
today
using
the
latest
stable
versions
of
ONF
protocols
–
eg.
OF
1.3.4.
2. Provide
feedback
to
ONF
WGs
on
their
work
product
from
an
implementa4on
of
the
chosen
networking
scenario.
3. Promote
adop4on
by
crea4ng
a
core-‐kernel
that
is
extensible
for
value-‐add
towards
deployment,
interoperability
and
differen4a4on.
SDN Based Control of Open Segment Routers OpenFlow
1.3
Rou4ng,
Recovery,
Label
imposi4on
Requests
SR
Labels
imposed
by
controller
OSR
FIB
built
by
controller
Requests
Open
Segment
Routers
(OSR)
Why Segment Routing 1.
Eliminates
label
distribu4on
protocols
–
LDP
and
RSVP-‐TE
2.
Source
rou4ng
via
‘segments’
–
maps
to
labels
in
MPLS
3.
Introduces
globally
significant
labels
–
simpler,
easier
to
debug
Segment
Rou4ng
(SR)
or
SPRING
(IETF
name)
–
Source
Packet
Rou4ng
In
NetworkinG
Think
of
Segment
Rou4ng
as
a
beher
MPLS
network
with
no
change
to
the
MPLS
data
plane.
Dell Involvement Dell Networking S4810-ON Open Networking Switch Ingress
Port
Incoming
Packet
VLAN
Flow
Table
Termina4on
MAC
Flow
Table
Unicast
IPv4
Rou4ng
Flow
Table
z
MPLS
Forwarding
Flow
Table
ACL
Policy
Flow
Table
Apply
Ac4ons
-‐push/pop
-‐TTL
mpls
-‐Set
-‐Output
-‐Group
Outgoing
Packet
z
Group
Table
Entries:
L3
Unicast
MPLS
Unicast
ECMP
Pkt.
+
Meta-‐
Data
+
Ac4on
Set
{}
Egress
Port
or
Group
SPRING-‐OPEN
Hardware
Abstrac4on
Summary of Features 1. Default
Segment
Rou4ng
with
MPLS
(node-‐segments)
,
ECMP,
PHP
and
OpenFlow
1.3
(mul4-‐tables
&
groups)
2. ARP/ICMP
handling,
subnet-‐configura4on,
pinging
router-‐IPs
(normal
router
behavior)
3. Link
and
Switch
failure
recovery
(taking
ECMP
into
account)
4. Crea4ng
an
SR
tunnel
with
loose
and
strict
hops
5. Crea4ng
policies
(priori4zed)
and
assigning
them
to
SR
tunnels.
Summary of Features 6. Segment
s4tching
(where
tunnel
requires
pushing
more
than
3
labels,
and
so
we
s4tch-‐segments
of
the
tunnel
to
get
around
hardware
limita4ons)
7. Use
of
Adjacency
Segments
• For
selec4ng
one
of
many
ports
(fine-‐grained
traffic
steering)
• For
hashing
across
mul4ple
ports
(enabling
load-‐ balancing
across
mul4ple
non-‐ECMP
paths)
8. Consistent
loop-‐free
updates
using
des4na4on
rooted
in-‐trees
Non
-‐
Goals
1. Not
crea4ng
GA
product;
no
QA;
will
not
be
ready
for
produc4on
nor
interoperate
with
other
networks
and
network
control
planes.
Will
support
some
elements
helpful
for
produc4za4on
(eg.
config,
troubleshoo4ng/OAM,
visibility
etc.)
2. Not
delivering
a
specific
service
like
Bandwidth-‐ TE
/VPN/NFV.
Instead
suppor4ng
core-‐capabili4es
to
build
such
services
on
top
(extensibility
op4ons)
3. Not
a
plugfest
–
data
and
control
plane
choices
will
be
made;
however
choices
should
be
replaceable
by
other
parts,
both
commercial
and
open-‐source
as
long
as
they
conform
to
the
requirements
onosproject
hacomono
nozomiito
wernerkrauss
mitsuakitohei
nagix
i524
line_developers
yanzm
takatsunobuhiro
yusuke
tk3fftk
kazumax55
mraible
cassininazir
destraynor
chrislema
addyosmani
eileencodes
marktimemedia
caitiem20
csswizardry
62gerente
morganepeng
aki_iinuma