1. Eric Osborne ARNOG 2016 NFV (and SDN)

2. Introduction About me: 20+ years in Internet networking: startup, Cisco, Level(3) Currently a principal architect for Level(3)’s Internet network About this talk: Very brief introduction to NFV, and SDN along with it Oversimplification, simplification, complication This talk is not negative This talk is not about Level(3), it is about how to think about NFV and SDN The right answer for me may not be the right answer for you. 2

3. But first, some history 3 NFV SDN Two independent things Started around the same time Inseparable, often confused for each other Started to discuss them separately …but maybe they’re not?

4. Three stages of explanation Oversimplification Simplification Complication 4

5. Oversimplification NFV: “Network Function Virtualization” (or “Network Functions Virtualisation”) SDN: “Software Defined Networking” OK, great. What do they mean? What do they do? What do they not do? 5

6. Simplification: NFV Separating hardware from software. Run homegrown or commercial software on vendor-independent hardware Virtualize to get the most out of that hardware Take what worked for computing and use it for the network 6

7. Simplification: SDN SDN: Control devices programmatically – focus on what the device is supposed to do, not the magic words to make it work Program the network through an Application Programming Interface (API), just like you program a computer Take what worked for computing and use it for the network 7

8. Complication: NFV Define Network Function: IP router? Firewall? NAT? WAN accelerator? Session Border Controller? Content Distribution Network host? Domain Name System resolver? Web server? What’s the difference between a ‘network function’ and a ‘host function’? 8

9. Complication: NFV Define Virtualization (1/2) Is it always Virtual Machines? What about the performance overhead? Can it be Docker containers? What about vendors with their own kernels? What about multi-tenant software on bare metal? 9

10. Complication: NFV Define Virtualization (2/2) Does it have to be commodity hardware? Can you get the performance you need? Crypto? WAN acceleration? 10

11. Complication: NFV If it’s specialized ASICs + multiple vendors with the same Docker kernel, where’s the freedom? “Bare metal multi-tenant OS with solution-targeted hardware” == what you buy today from an integrated vendor Is it just a pricing game? 11

12. Complication: NFV What do you virtualize? Core? Not many off the shelf multi-terabit switches Provider Edge? That’s where all the complex hardware and software goes. BGP, QoS, security, Netflow, and so on. How many choices do you really have? Customer Edge (CPE)? Sounds good at first, but… 12

13. Complication: NFV How do you virtualize? Data center hardware is designed to fail. CPE, not so much. Now you have to build HW/SW redundancy. N:1 (1:1)? How long can you be down? O(10ms? O(10**5)ms? Fail open (WAN acceleration)? Fail closed (firewall)? 13

14. Complication: NFV Physical CPE Set of devices at customer site Four services? Four boxes. ‘Service chaining’: Ethernet cable Virtual CPE Hosted in your POP. Who pays for power and cooling? Four services? Four VMs, one box. Economies of scale if you do it right. ‘Service chaining’: logical overlay built by central controller. More complex than cables. 14

15. Complication: SDN “Control devices programmatically” – but what do you control? Control forwarding: this is OpenFlow. An Ethernet-centric mixup of static routes, static bridging, and policy routing. Control configuration: this is NETCONF+YANG. Good stuff, but now you need a model before you can do anything. Do you write your own? Do you wait for the vendors to agree? 15

16. Complication: SDN 16 “Control devices programmatically” – but how? Controller Network Flawless magic

17. Complication: SDN SDN requires a central controller to …decide what to do …configure the network …audit to ensure compliance The lower you go in the TCP reference model, the harder this is 17

18. Complication: SDN 18 Offline Online Pick the right spot for you. Don’t pick the wrong one. ?

19. Conclusion NFV and SDN have some real uses Virtual services may be a better fit than virtual (commodity) forwarding They’re not magic, they’re not free Different isn’t always better (except when it is!) There is real value in what you can do with NFV and SDN Find the parts that work for you and do them. Just think carefully about what you’re doing before you do it 19