REN SDN Use Cases With OpenFlow and P4 status TNC2016 Curt Beckmann beckmann@brocade.com Chair of Open Datapath Working Group, ONF Chief Technology Architect for EMEA

Agenda SDN Perspective from 50 km SDN Deployments for REN OpenFlow deployment: Challenges (what you see) OpenFlow standards progress (what is being done) “Next Generation” SDN activity © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION

SDN: Perspective from 50km Customer driven movement Traditional SDN / OpenFlow ONF “technical” definition of SDN “Control physically separated from Data Plane” Real customer desire “Control and Data are VENDOR separated” That means “Ecosystem”-ouch! Oh, and key customers (SPs) also want NFV- yikes! How to “bootstrap” an ecosystem? Add OpenFlow to legacy boxes (done) Converge on small # of controllers (done) Common NB APIs (In process) Find buyers content with *one* ecosystem (in process) Sell “open vertical” solutions (in process) Controller Control Plane (software) APIs Router Router Control Plane (software) Control Plane (software) Data Plane (hardware) Data Plane (hardware) Hybrid © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION

SDN: Perspective from 50km Customer driven movement Traditional SDN / OpenFlow ONF “technical” definition of SDN “Control physically separated from Data Plane” Real customer desire “Control and Data are VENDOR separated” That means “Ecosystem”-ouch! Oh, and key customers (SPs) also want NFV- yikes! How to “bootstrap” an ecosystem? Add OpenFlow to legacy boxes (done) Converge on small # of controllers (done) Common NB APIs (In process) Find buyers content with *one* ecosystem (in process) Sell “open vertical” solutions (in process) Controller Control Plane (software) APIs Router Router Control Plane (software) Control Plane (software) Data Plane (hardware) Data Plane (hardware) Hybrid © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION

SDN Deployments for REN

SDN Use Cases Control Automation Visibility [Add Presentation Title: Insert tab > Header & Footer > Notes and Handouts] 4/28/2017 SDN Use Cases Control Automation Visibility Volumetric Attack Mitigation Elephant Flow Management Firewall Bypass Policy Based Flow Forwarding Botnet Attack Mitigation Campus Access Management SDN Based MPLS Traffic Engineering Bandwidth Scheduler Packet-Optical Integration WAN Network Virtualization Flow Metering SDN Based Wiretap VXLAN Monitoring © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION 6 © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY PROPRIETARY INFORMATION

SDN Use Cases… popular in REN context [Add Presentation Title: Insert tab > Header & Footer > Notes and Handouts] 4/28/2017 SDN Use Cases… popular in REN context Control Automation Visibility Volumetric Attack Mitigation Elephant Flow Management Firewall Bypass Policy Based Flow Forwarding Botnet Attack Mitigation Campus Access Management SDN Based MPLS Traffic Engineering Bandwidth Scheduler Packet-Optical Integration WAN Network Virtualization Flow Metering SDN Based Wiretap VXLAN Monitoring © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION 7 © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY PROPRIETARY INFORMATION

SDN for Policy-Based Firewall Insertion / Bypass Course Number Module Name SDN for Policy-Based Firewall Insertion / Bypass Operator or sFlow driven policy enforcement for large trusted flows Evaluating: Indiana U, CERN REN DC X REN DC Y One-armed Firewall Inline Firewall WAN SDN Controller SDN App Default Traffic Flow Internet Trusted Traffic Flow © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. INTERNAL USE ONLY

SDN-based Education Campus Access [Add Presentation Title: Insert tab > Header & Footer > Notes and Handouts] 4/28/2017 In Planning for v1.1 Shipping SDN-based Education Campus Access Dynamic policy for flexible network access control and security Programmable Access Control via Northbound API Path Explorer Policy Developing: ASU Evaluating: Cornell Flow Policy Visual Engine I’m consultant for project Y. Can I access the RED network? OF rule OF 1.3 Matching Normal Forward IPsec Tunnel to Secure Resources Guest How many Enterprises (Commercial, Public Sector or REN) wonder what is running on their network (Apps, users, content)? Quite a few. Or, almost all. Thanks to Netflix, Facebook, Mobile etc. which have boosted the consumption of content on web/Internet. How many of them actually know what’s running on their network? Not many, but there are quite a few, who use 3rd-party sFlow collector. How many of them are able to apply this analytics to improve network utilization and reliability? Very few. Why? Because of lack of high performance and non-disruptive tools and solutions …. With upcoming “sflow Analyzer with DDOS Mitigation App” (trials: Dec 2014; GA: April 2015) and MLXe innovation of SDN “Normal Forwarding” customers can for the first time, create an “inline” (highly cost effective), wirespeed (10G/40G/100G) and non disruptive (no impact to routing and forwarding) solution, to improve utilization and reliability of network. Similar to that “Accounting” is critical for ISP(s) and CSP(s) also, to monetize growing context services like Internet video, Internet voice, Data traffic, DR, CDN traffic, XaaS traffic etc.. Current accounting mechanisms force change in network architecture to use VLAN, QinQ, port mirroring etc. just to be able to account for services and create innovative service plans. Well the good news is that, with new SDN feature in 5.8, these ISP/CSP customers can get some relief and reduce the operational/architectural complexity. The ISP/CSP can de- couple accounting and forwarding, and create innovative “network enforceable” SDN based accounting services and plans. NOTES: MLXE is in production (DC, SP, Campus); doing normal IPv4/v6 forwarding based on existing protocols sFlow samples provide visibility into user and app traffic patterns Operations requires analytics/visibility into a application flow Analytics app determines which flow(s) to collect stats on Traffic management app on ODL determines OF rules ODL pushes OF rule to MLXe OF rules “monitor” interesting flow(s) to collect byte & packet statistics Option to apply metering (rate-limit, drop, remark) Normal forwarding of the flows will not be interrupted by this operation Use cases Internet/Mobile traffic analysis: Facebook, Youtube, Netflix, … Business/Residential Customer Internet Accounting/Intelligence Big Data analysis Campus Visibility, Accounting and Traffic Management Troubleshooting analysis Re-direct GRE Tunnel to Guest Network Campus / DC Drop MLXe (Placeholder imagery: will update) Access based on MAC / IP addresses Suitable for consultants, mobile workers for short-term network access Redirect to IPsec, GRE or MPLS tunnel © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. INTERNAL USE ONLY © 2010 Brocade Communications Systems, Inc. CONFIDENTIAL—For Internal Use Only

SDWAN SDN Backbone Longterm deployment: Internet2 Evaluating: AARNET Title Goes Here 4/28/2017 SDWAN SDN Backbone Longterm deployment: Internet2 Evaluating: AARNET So, what does this look like? Well, right now, as we’ve said, networks are very device centric with operation taking place on a device-by-device basis. Further, each device is not just the Innovation is limited both by Architecture because most changes need to happen across silos Economics because there’s limited incentive to fix things if you’re locked into a silo Also talk about cost: capex/opex (Placeholder imagery: will update) © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION © 2015 Brocade Communications Systems, Inc. CONFIDENTIAL—For Internal Use Only

OpenFlow Deployment: Challenges (1 of 2) Not to “insult” OpenFlow, but show ONF is aware of the challenges Two categories of implementation Well-deployed traditional “Fixed Function” (e.g. ASIC) platforms Flexible / programmable platforms (NPUs, etc), often from start-ups OpenFlow Applicability Challenge OF1.x (x > 0) too flexible for ASICs, not enough for NPUs Lack of “pipeline config” step assumes all boxes do all things API Challenges Hardware independence tricky  no common stable northbound APIs Even OpenFlow itself has not insisted on backward compatibility © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY PROPRIETARY INFORMATION

OpenFlow Deployment: Challenges (2 of 2) Not “OpenFlow bashing”, but to show ONF is aware of challenges Interoperability challenge (close to API challenge) Apps coded for specific devices Extensions often required Conformance testing challenges Lack of config step, 2 categories of device with many subcategories OF1.3 basic test defined, no long term support (LTS) for OF1.4 & OF1.5 Pipeline config mechanism: “Table Type Patterns” (TTP) v1.0 Upside: Designed to address most OpenFlow challenges Challenges: limited examples, “machine consumability”, YANG issues © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY PROPRIETARY INFORMATION

OpenFlow standards progress OF1.6 coming late 2016, with long term support, more modular LTS and modularity will help adoption, simplify extensions Optical / wireless expanding OF down OSI stack, beyond packet processing Increased market adoption of TTPs: e.g. China Mobile SPTN use case More interest in TTP-based interoperability testing TTP v1.1 syntax is ready, English language spec in process “machine” / YANG friendly, better Extension support, 1.0  1.1 converter More examples, TTP Validation & mapping tools planned or in development Stage set for abstract, human oriented language (Jsonnet?) on top of TTP This abstract language will include Library support for even more re-use © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION

OpenFlow reassessment OpenFlow was created as an L2/L3 control language It mostly assumed an “implicit” network device feature set / pipeline “flexible” vs “limited” platform not reconciled architecturally (no config phase) Too many options, lack of conformance tests, lack of stable NBAPIs: both platforms held back Consensus on need for multiple device “profiles” (TTPs) came slowly TTPs (pipeline profiles) work for both platforms and support a “config phase” Allow the industry / market / customers to develop, evolve the profiles Growing collection of TTPs will provide the needed context for: Well-defined, hardware-independent (abstraction-based) NBAPIs for app development A basis for interoperability and a collection of conformance tests © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION

“Next Generation” SDN activity NG SDN activity emerged from as OpenFlow issues recognized One element of wisdom: deeper validation is needed “prelaunch” Despite strong interest and demonstrations, a recognition that gaps remain Persistent challenge: A truly platform independent “Intermediate Representation” is elusive P4 is the dominant next-gen effort OpenFlow and P4 communities have significant overlap Focuses on “pipeline definition”, recognizes need for “config phase” P4 does not define the control protocol As a result, P4 is complementary to (not competitive with) OpenFlow OpenFlow will need some adjustments, which ODWG is prepared to address P4 is packet centric, will need augmentation for non-packet devices OpenFlow transport extensions will offer that augmentation © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION

(2nd slide on P4) Additional P4 information from meetings coming in next 2 weeks © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION

Conclusions (P4 items tentative, will revise) Low level control protocol is important to SDN OpenFlow is still the only open control protocol OpenFlow has faced challenges, and is evolving to address them Patient investment in P4 is underway More tools and examples and “ecosystem readiness” will be needed OpenFlow compatibility likely © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION