1. Softening the Network: Virtualization’s Final Frontier Steve Riley Technical Director, Office of the CTO Riverbed Technology steve.riley@riverbed.com http://blog.riverbed.com

2. Abstractions We’ve Seen

3. virtual memory

4. virtual disk volumes

5. virtual machines

6.  the illusion of a thing

7. abstraction

8. no re-programming

9. sometimes is disruptive

10. PM-1PM-2 VM-1 VM-2 VM-3 VM-4 VM-1 VM-2 VM-3

11. meets needs

12. provisioning

13. moving

14. snapshotting

15. roll back

16. New?

17. crude 1.A1.B1.C 2.A2.B2.C

18. less crude 1.A1.B1.C 2.A2.B2.C

19. less crude 1.A1.B1.C 2.A2.B2.C 1.D2.D

20. limitations

21. n < ∞

22. topology

23. static

24. interesting 10.M 1.A1.B1.C

25. interesting + 10.M 1.A1.B1.C 2.A2.B2.C

26. interesting +? 10.M 1.A1.B1.C 2.A2.B2.C

27. interesting +?? 10.M 1.A1.B1.C 2.A2.B2.C 1.D2.D

28. interesting +!!! 10.M 1.A1.B1.C 2.A2.B2.C 1.D2.D 10.N 1.E1.F 2.E2.F2.G 1.G2.H 2.I

29. insane ;) 10.M 1.A1.B1.C 2.A2.B2.C 1.D2.D 10.N 1.E1.F 2.E2.F2.G 1.G2.H 2.I

30. limitations

31. as before

32. + not cloudable

33. operational abstractions aren’t useful

34. PM-1PM-2 VM-1 VM-2 VM-3 VM-4 VM-1 VM-2 VM-3 MAC? IP? ACL? state?

35. control forwardingforwarding

36. limitations

37. topology mandates/constraints

38. no overlapped addresses

39. sloooooow to change

40. + not cloudable

41. requirements

42. decouple V from P

43. V looks like P

44. V allows units of operation

45. Software Defined Networking (*) * One popular, but not necessarily universal, definition

46. control forwardingforwarding

47. forwardingforwarding

48. application network application tier network tier

49. application tier control plane forwarding plane OpenFlow control platform

50. forwarding plane

51. relatively “dumb”

52. does what it’s told

53. R.I.P., RIP OSPF IS-IS &c.

54. control plane

55. centralized

56. end-t0-end view (not hop-by-hop)

57. programmable

58. naturally multitenant

59. maintains state

60. that’s it?

61. virtual server ≠ virtual network

62. DatapathConsistency Virtual serverCPU memory device I/O nanosecond operation self-contained Virtual networkaddress contextsall-port knowledge N instances of N states consistency on all paths timely distribution

63. DatapathConsistency Virtual serverCPU memory device I/O nanosecond operation = complexity at speed self-contained Virtual networkaddress contextsall-port knowledge N instances of N states consistency on all paths timely distribution = complexity at scale

64. The Virtual Network

65. decoupled from h/w

66. independent from others

67. delegated control

68. ephemeral

69. SDN (*) is a useful tool * As defined previously

70. control plane forwarding plane OpenFlow API x86 API VXLAN NVGRE NVP OTV STT

71. (

72. is SDN (*) a requirement? * As defined previously

73. control plane forwarding plane API x86 API VXLAN NVGRE OpenFlow multicast

74. )

75. How does Alice talk to Bob? API x86 vAPI : “I need a virtual L2-L3 network with these properties…” vSWITCHes in x86 boxes determine optimal path OPENFLOW: “Hardware, plumb the following…”

76. x86 Alice VM PM-A Bob VM PM-B

77. E V I L

78. ThroughputRecv CPUSend CPU Linux bridge9.3 Gbps85%75% OVS bridge9.4 Gbps82%70% OVS-STT9.5 Gbps70% OVS-GRE2.3 Gbps75%97% one flow, two VMs, separate hypervisors ThroughputCPU OVS bridge18.4 Gbps150% OVS-STT18.5 Gbps120% OVS-GRE2.3 Gbps150% aggregate, four VMs, two hypervisors http://networkheresy.com/2012/06/08/the-overhead-of-software-tunneling/

79. possibilities

80. security application

81. QoS application

82. WAN op application (*) * hard: distributed cache and symbol vocabulary

83. on-demand VPN/C

84. infrastructure  code

85. network  code

86. decoupled and delegated

87. physical L2-L3

88. logical L2-L3 L4-L7 services x86

89. x86, really?

90. complex  much CPU

91. FW/LB use CPU at flow start

92. optimized stacks  performance

93.  upgrade certainty

94. distinct security forwarding shaping priority …

95. outcomes

96. working multitenancy

97. isolated addressing

98. programmable

99. independent and ephemeral

100. VM “ ”

101. virtual IP virtual MAC

102. route my packets/frames without collisions

103. move v-net without changes

104. tear down when finished

105. separately alter physical and virtual topologies

106. consider: on-demand HA/DR

107. consider: on-demand HA DR

108. SDN (*) manages state * As defined previously

109. VM “ ”

110. “ ”

111. “ ”

112. abstractional consistency

113. (mature orchestration?)

114. servers = disposable horsepower

115. networks = disposable pathways

116. DatapathConsistency Virtual serverCPU memory device I/O nanosecond operation = complexity at speed self-contained Virtual networkaddress contextsall-port knowledge N instances of N states consistency on all paths timely distribution = complexity at scale

117. DatapathConsistency Virtual serverCPU memory device I/O nanosecond operation = complexity at speed self-contained Virtual networkaddress contextsall-port knowledge N instances of N states consistency on all paths timely distribution = complexity at scale

118. easy familiar  point solution ideas

119. TaggingSegmentation, not isolation Same address in “both” worlds Hardware has to understand No mobility

120. TaggingSegmentation, not isolation Same address in “both” worlds Hardware has to understand No mobility Address mapping Like NAT: update address in place Multiplex large space into small: how? Virtual-to-virtual: physical “punch”

121. TaggingSegmentation, not isolation Same address in “both” worlds Hardware has to understand No mobility Address mapping Like NAT: update address in place Multiplex large space into small: how? Virtual-to-virtual: physical “punch” EncapsulationOr tunnels, or overlays (sigh) Worlds can be totally distinct Different forwarding for V and P Strong isolation: no V on P w/o bridge PA demux VA payload

122. DatapathConsistency Virtual serverCPU memory device I/O nanosecond operation = complexity at speed self-contained Virtual networkaddress contextsall-port knowledge N instances of N states consistency on all paths timely distribution = complexity at scale programmability and cloudability

123. hard scary  innovative advancements

124. Resources

125. networkheresy.com packetpushers.net blog.ioshints.con sdncentral.com

126. Thanks for coming! Steve Riley Technical Director, Office of the CTO Riverbed Technology steve.riley@riverbed.com http://blog.riverbed.com