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

2. 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

3. 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

4. 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

5. SDN Deployments for REN

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. “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

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

17. 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