REN SDN Use Cases With Open Flow and

Agenda • SDN Perspective from 50 km • SDN Deployments for REN • Open.

SDN: Perspective from 50 km Customer driven movement Traditional • ONF “technical” definition of

SDN Use Cases CONTROL • • • Volumetric Attack Mitigation Elephant Flow Management Firewall

SDN Use Cases… popular in REN context CONTROL • • • Volumetric Attack Mitigation

SDN for Policy-Based Firewall Insertion / OPERATOR Bypass OR SFLOW DRIVEN POLICY ENFORCEMENT FOR

SDN-based Education Campus Access Shippingfor In Planning v 1. 1 Dynamic policy for flexible

SDWAN SDN BACKBONE Longterm deployment: Internet 2 Evaluating: AARNET (Placeholder imagery: will update) ©

Open. Flow Deployment: Challenges (1 of 2) Not to “insult” Open. Flow, but show

Open. Flow Deployment: Challenges (2 of 2) Not “Open. Flow bashing”, but to show

Open. Flow standards progress • OF 1. 6 coming late 2016, with long term

Open. Flow reassessment • Open. Flow was created as an L 2/L 3 control

“Next Generation” SDN activity • NG SDN activity emerged from as Open. Flow issues

(2 nd slide on P 4) • Additional P 4 information from meetings coming

Conclusions (P 4 items tentative, will revise) • Low level control protocol is important

Slides: 17

Download presentation

REN SDN Use Cases With Open. Flow and P 4 status TNC 2016 CURT 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 • Open. Flow deployment: Challenges (what you see) • Open. Flow standards progress (what is being done) • “Next Generation” SDN activity © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION 2

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

SDN Deployments for REN

SDN Use Cases CONTROL • • • Volumetric Attack Mitigation Elephant Flow Management Firewall Bypass Policy Based Flow Forwarding Botnet Attack Mitigation Campus Access Management AUTOMATION • SDN Based MPLS Traffic Engineering • Bandwidth Scheduler • Packet-Optical Integration VISIBILITY • • WAN Network Virtualization Flow Metering SDN Based Wiretap VXLAN Monitoring © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION 6

SDN Use Cases… popular in REN context CONTROL • • • Volumetric Attack Mitigation Elephant Flow Management Firewall Bypass Policy Based Flow Forwarding Botnet Attack Mitigation Campus Access Management AUTOMATION • SDN Based MPLS Traffic Engineering • Bandwidth Scheduler • Packet-Optical Integration VISIBILITY • • WAN Network Virtualization Flow Metering SDN Based Wiretap VXLAN Monitoring © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION 7

SDN for Policy-Based Firewall Insertion / OPERATOR Bypass 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 App Default Traffic Flow Trusted Traffic Flow SDN Controller Internet © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION

SDN-based Education Campus Access Shippingfor In Planning v 1. 1 Dynamic policy for flexible network access control and security Programmable Access Control via Northbound API Path Explorer Visual Engine Policy Developing: ASU Evaluating: Cornell Flow Policy I’m consultant for project Y. Can I access the RED network? OF rule OF 1. 3 Matching Normal Forward Re-direct Drop MLXe • Access based on MAC / IP addresses • Redirect to IPsec, GRE or MPLS tunnel IPsec Tunnel to Secure Resources Guest GRE Tunnel to Guest Network Campus / DC (Placeholder imagery: will update) • Suitable for consultants, mobile workers for short-term network access © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. INTERNAL USE ONLY

Open. Flow Deployment: Challenges (1 of 2) Not to “insult” Open. Flow, 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 • Open. Flow Applicability Challenge ‒ OF 1. 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 Open. Flow itself has not insisted on backward compatibility © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY PROPRIETARY INFORMATION

Open. Flow Deployment: Challenges (2 of 2) Not “Open. Flow 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 ‒ OF 1. 3 basic test defined, no long term support (LTS) for OF 1. 4 & OF 1. 5 • Pipeline config mechanism: “Table Type Patterns” (TTP) v 1. 0 ‒ Upside: Designed to address most Open. Flow challenges ‒ Challenges: limited examples, “machine consumability”, YANG issues © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY PROPRIETARY INFORMATION

Open. Flow standards progress • OF 1. 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 v 1. 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 13

Open. Flow reassessment • Open. Flow was created as an L 2/L 3 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 14

“Next Generation” SDN activity • NG SDN activity emerged from as Open. Flow 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 • P 4 is the dominant next-gen effort ‒ Open. Flow and P 4 communities have significant overlap ‒ Focuses on “pipeline definition”, recognizes need for “config phase” ‒ P 4 does not define the control protocol • As a result, P 4 is complementary to (not competitive with) Open. Flow • Open. Flow will need some adjustments, which ODWG is prepared to address ‒ P 4 is packet centric, will need augmentation for non-packet devices • Open. Flow transport extensions will offer that augmentation © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION 15

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

Related presentations