Wikis > Software-Defined Wide Area Network (WAN) Use Case Working Group Wiki

Notice: The views and opinions expressed here are collective derived from the members of this ONUG working group and are not the express opinion of any individual or company. 

SPRING 2016

ONUG Use Case Working Groups Schedule: Software Defined WAN
Date Time
December 18, 2015 3:00-4:00pm ET Conference Call  
January 15, 2016 3:00-4:00pm ET Conference Call  
February 19, 2016 3:00-4:00pm ET Conference Call  
March 18, 2016 3:00-4:00pm ET Conference Call  
April 15, 2016 3:00-4:00pm ET Conference Call  
May 9-11, 2016 TBD ONUG Spring 2016 – Face-to-Face
Working Group Chairman
Conrad Menezes (Bank of America)
Members
Wade Hindell American Express
Howard Wang Bank of America
Vijay Balasubramanian Bank of America
Andrew Kulawiak Bank of America
Andrew Gurbaxani Benevis
Neal Secher BNY Mellon
Mike Elmore Cigna
Payman Samadi Columbia University
Zoran Kostic Columbia University
Elio Salvadori CREATE-NET
Bryan Larish DoD
Amiri Gonzalez Express Scripts
Daniel Steyn Facebook
Aryo Kresnadi FedEx
David Laundre FedEx
Ryan Pena FedEx
Snehal Patel Gap
Jongwon Kim GIST
Pete Kwon Legacy Texas Bank
Ray Ng Luetschine Consulting LLC
Bob Natale MITRE
Hailu Meng Monsanto
Brian Ong Navy Federal Credit Union
Gerold Furler Novartis
Nelson Tai Pfizer
Scott Smith PNC Bank
Nick Feamster Princeton
Mark DeFilippis Promark Data
Shradha Sharma PwC Advisory Services
John Hoffman Salesforce
Azharul Mannan Standard Chartered Bank
Scott Kline State Farm Insurance
Dan Riedner State Farm Insurance
Cameron Foster Tesla Motors
Mahesh Desai Tesla Motors
Sumanth Bopanna Thomson Reuters
Christina Dube UNH
Lincoln Lavoie UNH-IOL
Chris Parchinski Unilever
Scot Clark Unilever
Mehrdad Moradi University of Michigan
Rahul Godha University of Wisconsin-Madison
Zakir Mohideen Visa
Phil Hattwick Wellington Management
John Feuerherd Wells Fargo
Zahid Kalwar XL Global Services
Charlie Gero Akamai
Tamar Pinto Akamai
Robert Bays Brocade
Aziz Abdul Cisco
Liad Ofek Cisco
Steve Wood Cisco
Michael Kowal Cisco
Scott Van de Houten Cisco
Nagendra Kumar Nainar Cisco
Sumanth Kakraparthi Cisco
Gopinath Durairaj Citrix
Marco Murgia Citrix
Mukhtiar Shaikh CloudGenix
Anita Pandey Cybera
Sanch Datta FatPipe
Matt Gwyther FatPipe
Jeff Gray Glue Networks
Stefan Dietrich Glue Networks
Mike Haugh Glue Networks
Melissa He HPE
Hui Liu HPE
Wade Shu HPE
David Chen HPE
Aravind Sukumar NEC
Nabil Bitar Nuage Networks
Alastair Johnson Nuage Networks
Toshal Dudhwala Nuage Networks
Rotem Salomonovitch Nuage Networks
Kevin Glavin Riverbed
Akshay Kakar Riverbed
Damon Ennis SilverPeak
Rolf Muralt SilverPeak
Siddharth Ekbote SilverPeak
Parag Thakore VeloCloud
Steve Woo VeloCloud
Prashant Gupta Verizon
Apurva Mehta Versa Networks
Anusha Vaidyanathan Versa Networks
Mark Weiner Versa Networks
David Klebanov Viptela
Ramesh Prabagaran Viptela
Manan Shah Viptela
Lloyd Noronha Viptela

March 23, 2016 Meeting – Current State Document


FALL 2015

ONUG Use Case Working Groups Schedule: Software Defined WAN
Date Time
July 17, 2015 2:00-3:00pm ET Conference Call  
August 21, 2015 2:00-3:00pm ET Conference Call  
September 18, 2015 2:00-3:00pm ET Conference Call  
October 16, 2015 2:00-3:00pm ET Conference Call  
November 3-5, 2015 TBD ONUG Fall 2015 – Face-to-Face
Working Group Chairman
Conrad Menezes – Central Time Zone
Conference Bridge # ONUG Webex
Members
Wade Hindell American Express
Daldy Rustichel Youbou Biagha Association Congolaise pour le Developpement Agricole
Howard Wang Bank of America
Vijay Balasubramanian Bank of America
Andrew Kulawiak Bank of America
Neal Secher BNY Mellon
Mike Elmore Cigna
Payman Samadi Columbia University
Zoran Kostic Columbia University
Elio Salvadori CREATE-NET
Bryan Larish DoD
Matthew Clark F.Hoffman-LaRoche
Daniel Steyn Facebook
Aryo Kresnadi FedEx
David Laundre FedEx
Ryan Pena FedEx
David White Institute of Technology Tallaght Dublin
Ray Ng Luetschine Consulting LLC
Bob Natale MITRE
Gerold Furler Novartis
Nelson Tai Pfizer
Nick Feamster Princeton
Shradha Sharma PwC Advisory Services
Dave Greenfield STAnalytics
Sumanth Bopanna Thomson Reuters
Christina Dube UNH
Lincoln Lavoie UNH-IOL
Scot Clark Unilever
Zakir Mohideen Visa
Phil Hattwick Wellington Management
John Feuerherd Wells Fargo
Michael Kowal Cisco
Steve Wood Cisco
Marty Ma Cisco
Liad Ofek Cisco
Gopinath Durairaj Citrix
Marco Murgia Citrix
Mukhtiar Shaikh CloudGenix
Mukhtiar Shaikh CloudGenix
Sanch Datta FatPipe
Matt Gwyther FatPipe
Jeff Gray Glue Networks
Stefan Dietrich Glue Networks
David Chen HP/Aruba
Prince Jose HP/Aruba
Jay Gill Infinera
Srini Seetharaman Infinera
Michael Githens Ixia
Pierre Lynch Ixia
Alastair Johnson Nuage Networks
Rotem Salomonovitch Nuage Networks
Toshal Dudhwala Nuage Networks
Kevin Glavin Riverbed
Ali Moein Silver Peak
Damon Ennis Silver Peak
Rolf Muralt Silver Peak
Siddharth Ekbote Silver Peak
Adam Schultz Talari
Keith Gillum Talari
Alex Ratcliffe Talari
Parag Thakore VeloCloud
Anusha Vaidyanathan Versa Networks
Apurva Mehta Versa Networks
Mark Weiner Versa Networks
David Klebanov Viptela
Lloyd Noronha Viptela
Manan Shah Viptela
Rameshbabu Prabagaran Viptela

 

July 17, 2015 Meeting Notes

  • ONUG Spring 2015 summary update, SD-WAN Poll Results and feedback
  • Potential ONUG FALL 2015 SD-WAN live Demonstrations suggested by chair –
    • Interoperability – support for APIs, open standards protocols, open source code.
    • How does Open flow, SD-WAN and virtualization come together
    • Network Extensibility, Service chaining – firewalls, load balancers, proxies,…
    • Integration with existing enterprise net tools such as OPNet, NetQos, SEV1,…others
    • Performance at scale – tad hard to do due to space limitations
  • Note: SD-WAN WG vendor demos would be live, without any power point slides other than supporting the live demo being performed.
  • Reached consensus that WG members would submit live demo recommendations which would be discussed on next WG call.

August 21, 2015 Meeting Notes

  • Demo Themes received from the below participants prior to the call-
    • Versa Networks – Anusha Vaidyanathan
    • VeloCloud – Parag Thakore
    • Viptela – David Klebanov
  • Based on suggestions by above WG members and subsequent discussion that followed, there were four themes that emerged as potential live demo candidates for fall 2015-
  • Network Connectivity – hybrid WAN, DC, vDC/Cloud,..
  • Security – Network & Application Security, Service Chaining – Firewall + IPS/IDS,…
  • Application Services – Policy, Performance, SLA, load balancing, L4-L7,…
  • Service/Cloud Service Provider – MSP SD-WAN, rich content delivery Cloud Service/s,…
  • Reached consensus that all WG participants were going to send specific demo suggestions encompassing the above themes based on which a demo plan could be formulated spanning both days at next summit.

ONUG Software-Defined WAN Use Case DRAFT

Two side bars:

Definition of Open Networking 

Open networking is a suite of interoperable software and/or hardware that delivers choice and design options to IT business leaders, service and cloud providers. At its core, open networking is the separation or decoupling of specialized network hardware and software – all in an effort to give IT architects options in the way in which they choose to design, provision, and manage their networks. These technologies must be based on industry standards. The standards can be de-facto as adopted by a large consortium of the vendor community, open in the sense that they are community based, or defined as standards by the prevailing standards bodies. Open networking hopes to deliver on two promises:

1) Decoupling of network hardware and software which mitigates vendor lock-in and shifts network architecture structure options to users

2) Significant reduction of the total cost of ownership model, especially operational expense

Open Networking User Group (ONUG) 

ONUG is one of the largest industry user groups in the networking and storage sectors. Its board is made up exclusively of IT business leaders, with representation from Fidelity Investments, FedEx, Bank of America, UBS, Cigna, Pfizer, JPMorgan Chase, Citigroup, Credit Suisse, Gap, Inc., and Symantec. The ONUG mission is to guide and accelerate the adoption of open networking solutions that meet user requirements as defined through use cases, proof of concepts, hackathons, and deployment examples to ensure open networking promises are kept.

The ONUG community is led by IT business leaders and aims to drive industry dialogue to set the technology direction and agenda with vendors. To that end, ONUG hosts two major conferences per year where use cases are defined and members vote to establish a prioritized list of early adopter, open networking projects that communicate propensity to buy and budget development. The vendor community stages proof of concepts based upon ONUG Use Cases, while standards and open source organizations prioritize their initiatives and investments based upon them. ONUG also hosts user summits and smaller, regional user-focused Fireside Chat Meet-Ups through the year.

ONUG defines six architectural areas that will open the networking industry and deliver choice and design options. To enable an open networking ecosystem, a common multivendor approach is necessary for the following six architecture components:

1) Device discovery, provisioning, and asset registration for physical and virtual devices

2) Automated “no hands on keyboards” configuration and change management tools that align DevOps and NetOps

3) A common controller and control protocol for both physical and virtual devices

4) A baseline policy manager that communicates to the common controller for enforcement

5) A mechanism for sharing (communicating or consuming) network state and a unified network state database that collects, at a minimum, MAC and IP address forwarding tables automatically

6) Integrated monitoring of overlays and underlays

(To be formatted after editorial review – see descriptions in ONUG white paper)

 

Scope

The scope of this document is to provide a set of tactical and strategic requirements that may help guide enterprises in their selection of Software Defined Networking – Wide Area Network (SDN-WAN) vendor solutions. The current set of WAN problems are highlighted and SDN-WAN implications to be considered within enterprise wide area networks as designed and operated by in house teams and/or managed service providers.

While the impacts discussed are commensurate with an ITIL service delivery model, enterprises can leverage the information for an RFI and adapt to scale and suit their current or planned organizational support delivery and maturity capabilities.

 

Executive Summary

This document is comprised of five major focus areas surrounding Enterprise SDN-WANs.

I.                  The problem statement as experienced in today’s enterprise wide area networks.

 

II.                  The WAN architectural models prevalent and proposed within most enterprises.

 

III.                  The desired SDN-WAN enterprise product features & functionality.

 

IV.                  Risks and Dependencies

 

V.                  SDN-WAN implications to Service Management support tools & delivery processes

 

NOTE: VI.                 Terminology / Acronyms / Definitions – Determine where this should go later

 

The expected outcome for SDN-WAN enterprise adoption and usage can be summarized but not limited to meeting the below set of business requirements:

i)               Ability for business applications to leverage different remote site/branch transport access links of varying bandwidth through multiple carrier networks (internet/MPLS) effecting carrier agnostic and/or newer end-point/application capabilities between remote site/branch and cloud/data center, at cost and quality that meet and/or exceed business expectations. Revised Recommendation: Ability for business applications to leverage remote site and/or branch transport access and cpe in a commodity fashion with a fully agnostic framework

 

ii)              A secure wide area architecture that auto detects and responds around link/network degradations/failures state changes while prioritizing application transport based on a centralized corporate policy and real time application consumption visibility, thus enabling the business to roll out new products/applications to sites with agility.

Revised Recommendation: A secure wide area architecture that results in auto-detection and repair triggered by faulty and/or degraded state changes within the network.

Re-revised Recommendation: A secure wide area network architecture that results in traffic auto re-routing per policy and based on auto-detection of transport layer degradation and/or network state changes.

 

iii)            Revised Recommendation: Prioritization and real-time visibility of business applications aligned with security and corporate governing policies

 

iv)             An uninterrupted high quality customer experience at remote site/branches facilitated by the wide area network.

Revised Recommendation: A highly available and resilient WAN environment resulting in an optimal user (customer and/or application) experience

 

     I.         The Problem Statement

On a year over year basis, enterprise wide area networks have become increasingly complex and costly to manage and maintain. At the same time, businesses require 24 x 7 network uptime so enterprise network teams are faced with shrinking change windows often competing for the same time window set aside for application delivery and support teams. Production and efficiency at remote business sites/branches is adversely impacted by a number of traditional design and operational factors within the WAN that is called out here but not necessarily limited to the following.

i)               Provisioning Cycle Delays  to get Remote Site/Branch On Line: Revised Recommendation: Significant delays and cost in provisioning cycles of remote sites:

 

NOTE:  Let’s revisit the definition of “Remote Site/Branch” to ensure we align with the ONUG use-cases

Delays in carrier access layer provisioning at remote sites can take weeks to months.  Provisioning of a T1 MPLS circuit can still take anywhere from 30 – 90 days despite in many cases where expedited fees are paid by the customer. Provisioning of higher speed, higher cost MPLS circuits (DS3 and above) take even longer stretching to a time frame of 6 months or longer, primarily driven in most cases by absence of fiber to/at a remote site.  In many such instances that play out across enterprise customer networks, internet links at the same remote sites may be provided via terrestrial cable/DSL access as well as via 4G LTE wireless access and have reasonably shorter provisioning cycles.

 

Businesses have an immediate need to start up operations at these remote sites without incurring prolonged delays and the availability of these internet access links present a viable transport alternative to delay prone legacy T1/n x T1 (bundled T1)MPLS links. Yet, enterprise IT is challenged with the complexity of configuration and security at the remote site/branch router via these T1/n X T1, internet links. An MSP or a carrier managed MPLS network not only requires additional levels of co-ordination across in house and carrier/MSP resources, it also requires linkages to enterprise service support and delivery processes which of course come at an additional cost and effort. Bottom line, efforts on a site by site basis is time consuming, costly and being manually intensive is prone to error.

 

ii)              Remote Site/Branch Router Link Access Configuration & Operational Complexity: Revised Recommendation: Operational and Management complexities resulting in provisioning and remediation inefficiencies

Varying bandwidth via multiple access links and networks connecting into the remote site/branch give rise to a complex router/s configuration in order to accommodate features such as link bundling (via MLPPP), Quality of Service, Multicast, IPSec and avoidance of asymmetric routing besides others.  This complexity not only impacts site turn up implementation of remote sites/branches but also post implementation operations monitoring and management of wide area networks.

 

Let’s take the case of bundled T1 links via a MLPPP layer 2 configuration.  It facilitates remote site/branch router Tx/Rx load balancing plus allowing for a single IP address across the n x T1 links, alleviating additional PE IP level configuration for MSPs/carriers and reducing the number of IP addresses to be tracked and monitored via the enterprise/carrier/MSP NOC.  However, since BGP operating at layer 3 has no visibility into the underlying layer 2 MLPPP protocol, failing/error degraded T1 circuits within a bundle go un-detected unless monitored on a per port basis. In an enterprise with several thousand sites/branches, this port level monitoring of remote bundled circuits can be a daunting task for any NOC. Since the NOC is left monitoring a single IP address, these individual link/s failures which at times are silent within a bundle cause severe transport degradation bringing application access to a crawl.

 

In cases where there is a second internet link, a situation arises wherein the internet link inherently has a higher Tx/Rx bandwidth than the lone working T1 remaining in the MLPPP bundle.  A considerable amount of time, effort, and resources from both the in-house team and carrier/MSP is wasted in protracted cycles of finger pointing, troubleshooting and manual re-configuration of site/branch routers are often done to selectively prioritize and re-route corporate and cloud applications traffic across the alternative link. This situation may well be compounded by the fact that the best effort internet link may have better round trip delay characteristics than the carrier provided MPLS circuit/s.

 

Bottom line, network teams are spending far more time trying to put out fires and restore site/branch link connectivity as opposed to having meaningful dialogue with their business partners on real time trending and reporting of application level network consumption and/or insight into new applications & devices rolled out.

 

 

iii)            Proliferation of network appliances at remote sites/branches: Revised Recommendation: The Proliferation of required network and security services has resulted in a 1:1 ratio mapping of multi-vendor appliances not optimal for remote sites. 

 NOTE: Lack of Application visibility needs to be called out here

The intermediate between a LAN and a WAN at remote sites/branches is no longer a firewall and Ethernet cable connects. Providing optimally secure corporate and cloud application access from these sites have spawned a number of purpose built appliances that straddle the connection between the LAN and the WAN.  Besides the LAN switches, WAN router and firewalls, today’s remote site/branch may include an internet cable/DSL router, wide area network optimization appliances, packet capture & analysis appliances, IPS/IDS appliances, content caching engines/appliances, and Wi-Fi controllers amongst others.  All of these appliances require an element of configuration together with continuous lifecycle management while working on enabling or disabling specific functions linked to transitory traffic yet performing such functions totally independent of each other. It is obvious that more appliances at remote sites/branches adds to the complexity with multi-appliance configurations requiring either soft or hard moves adds & changes (MACs) while increasing annual operational costs.

Note: MAC acronym in technology refers to Media Access Control, can we use different or other standardized process terminology from ITIL? 

 

iv)             Security, Compliance & Controls: Revised Recommendation: Complexity and inefficiency for managing security and compliance controls

 

Enterprise information security policies in line with PCI regulatory compliance mandate usage of firewalls and encryption of data sent through the internet. In the absence of application level encryption, network layer IPSec encryption is normally deployed between the remote site/branch router and the head end corporate data center router.

There are several operational and security challenges with this traditional mode of IPSec deployment.  Inadequacies with scaling, efficiencies, resiliency and security compliance are experienced in large enterprises.

 

As demand for bandwidth increases at remote sites/branches, wide area network routers/interface cards and/or crypto engines performing the IPSec crypto function require scaling coupled with a cost multiplier factor relative to the number of remote site/branches to match this demand. Besides this, while DMVPN “NOTE: Remove DMVPN terminology and replace it with a more vendor agnostic term”  has facilitated site to site connectivity, head end hub scaling issues, scaling of routing protocols (EIGRP) and optimization of routing updates remain a challenge. Impact to application efficiencies in the form of reduced throughput can be caused by packet fragmentation resulting from an increase in size of packets due to the addition of the IPSec header, nested and/or chained IPSec tunnels. One fundamental issue with the IPSec mode of encryption in transit is that the routing engine does not talk to the encryption engine and vice-versa. So, any routing failures can result in black holing/dropping of traffic which in most cases is overcome to a degree by duality of crypto engines and routers, adding to the operational cost and complexity.

 

Typical enterprise implementations of IPSec use symmetric encryption.  With symmetric encryption both sites use a shared secret key.  Given the potential overhead of manual key management across thousands of sites, large enterprises normally use the same pre-shared keys across all sites/branches, which means that if any site/branch is compromised the network is as well.  Furthermore, most implementations resort to utilizing the same secret key indefinitely (with mitigating controls around router/crypto-engine access/authentication) since changing the key can be manually intensive, business disruptive and furthermore prone to human error.

 

v)              Cost and Control of the Wide Area Network: Revised Recommendation: High cost and Low control of the Wide Area Network

 

Enterprise wide area networks have evolved over the years, from a mix of point to point leased line circuits in a mesh model to SMDS to frame relay to ATM to current deployments of carrier MPLS.  Through all of these enterprise production deployments reliance on the carrier has increased as have the capex and opex costs to build, support and run these large networks. While MPLS promised and delivered on the separation of data forwarding and control plane, the increased usage of enterprise feature sets at remote sites/branches such as Quality of Service, Multicast, Encryption,.. come at additional cost and complexity.  While complexity is a given, the one-time per WAN device/appliance charges coupled with the additional MRC (maintenance, monitoring) to run these feature sets, not including volume based carrier/MSP charges for soft/hard MACs, the costs have simply stacked up. So enterprises are totally reliant on the carriers and/or MSPs for every little change in the context of their wide area network.

Note: MRC acronym refers to what? Is this standardized process terminology from ITIL?

At the same time, business internet access to remote sites on a global basis have become increasingly viable due to their ease of availability, shorter provisioning cycles, and most importantly lower cost at much higher levels of bandwidth. In an aggregated format, both cable and DSL connections lower the capex and opex operating networking model when compared to carrier based MPLS networks.  This together with the above control & cost issues have compelled enterprises to review SDN-WAN as a means of securely incorporating the internet into their corporate network while taking back control through centralized policy management and gaining application level visibility through what appears to be a reasonably automated & appropriate SDN-WAN solution aligned with their WAN architecture.

 

 

     II.         WAN Architecture Models

NOTE: Current and Proposed

NOTE: This section appears to capture transport level network architecture models.  Do we want to consider Service, Application, and/or Management architecture models? 

The below WAN architecture models are typical in today’s enterprise networks.  Today most all businesses expect 24 x 7 WAN availability. Together with high availability, ensuring a best case customer experience regardless of application or end user device at remote sites/branches requires consistent deterministic levels of jitter, packet delay/loss, and quality of service amongst others. Direct internet access is also increasingly becoming a staple for remote sites/branches, as a means of providing direct access to e-commerce and cloud based applications without the long haul transit to and from the data center.  These shifting traffic flow patterns mandate a robust routing schema together with an adaptive security model. While there may be variations in the number of access circuits and WAN Transport providers for MPLS/Cable/DSL/4G LTE WAN; understanding the SDN-WAN product feature set applicability and it’s linkages with underlying service delivery & management processes will be key for enterprises regardless of whether or not they have an in-house support model or an MSP support structure.

 

It is expected that the SDN-WAN product be capable and /or evolve and mature to support any of these production WAN implementations. The enterprise customer base will want to understand the application, networking, and security feature sets supported across their own and/or intended WAN implementation.

 

Many of the real world issues pertinent to today’s WAN implementations are discussed within the problem statement. Empowering the enterprise customer to take back control of their network while allowing the carrier/MSP to accommodate their needs will make for an appropriate SDN-WAN migration and implementation.

 

 

figure 1

Figure 1. WAN Model 1 – Traditional MPLS WAN with internet back haul to DC

 

figure 2

 

Figure 2. WAN Model 2 – Dual MPLS Carrier WAN with internet back haul to DC

 

figure 3

Figure 3. WAN Model 3 – Traditional MPLS with Direct Internet Access / Secondary WAN

figure 4

 

Figure 4. WAN Model 4 – High Bandwidth (N X T1) MPLS with Direct Internet Access / Secondary WAN

 

figure 5 

Figure 5. WAN Model 5 – Cellular Direct Internet Access/Secondary WAN

 

figure 6 

Figure 6. WAN Model 6 – MPLS with Internet Data Center Direct Internet Access WAN

figure 7

Figure 7. WAN Model 7 – Regional Internet Exits at Colo facilities

 

NOTE: Proposed WAN Diagram: Review Nelson’s diagram as a starting point. 

 

   III.         SDN-WAN Product Requirements

NOTE: “SDN-WAN” is not a product you can go purchase from the marketplace.  It is an overall architecture composed of multi-vendor solutions based on open-standards and open interfaces.  These multi-vendor solutions (mix of hardware and software) are architected together with the Networking components from the Service Providers to build the SDN-WAN architecture.

Taking into account the different WAN models, the size and scale of the network not with-standing, enterprise customers will want to know the below product and component architecture and feature sets supported relative to the SDN-WAN product and pertinent to their current WAN model and/or future WAN implementation. While the below list is by no means exhaustive, it is meant to cover critical areas of an enterprise SDN-WAN solution while overcoming the issues listed earlier within the problem statement and widely encountered in today’s wide area networks.

NOTE: Would it be possible to separate out these requirements into vendor categories and service provider/operator categories?  For example, in the problem statement section there was discussion about it taking 90+ days to get a remote site connectivity.  These would seem to be a Service Provider requirement. 

Scalability

i)      Single/Dual and/or Clustered and/or Virtual Machine Controller configurations supported within a single DC, across dual and/or multiple DCs

ii)     Centralized or non-Centralized Controller/s Note: This requirement seems to be applicable or similar to the requirement above and could be incorporated into that requirement.

iii)   Given the limitations around speed of light and subsequent variable response times in a global geography, what configuration may be considered optimal for an enterprise customer that may have sites in multiple continents, where access to the cloud/internet is just as critical as access to the corporate data center.  Note: Is Fiber-optic technology the limiting factor here?  What is meant by “configurations”? Router configurations vs. Transport technologies vs. Topologies.  This is posed as a question instead of a requirement.

iv)    D/R options for the above, if any and as applicable NOTE: What does D/R stand for?

v)     Controller & Remote Site Device/Appliance – number and types of physically local interfaces supported

vi)    Controller & Remote Site Device/Appliance number and types of virtual/logical interfaces supported

vii)  Maximum number of remote sites/branches supported without any loss or degradation in efficiency, reliability, and security (0-1K, 1K-5K, 5K-10K, 10K+)

viii) Is the SDN-WAN solution IPv6 ready and capable, provide details and operating changes required to run both IP versions simultaneously

 

Efficiency

i)      List all L2 and L3 protocols supported for the SDN-WAN solution (list both, physically local and across the WAN between remote end and controller)

ii)     Proprietary L2, L3, other protocols, if any introduced by the SDN-WAN

iii)   Centralized provisioning, policy management, security management and automation. Note: Move this to Manageability Section.

iv)    Real time visibility into cloud/internet, network and application centric management, linkages and/or dependencies if any to existing enterprise management tool/platforms. Note: Move this to Manageability Section.

v)    Are there predefined templates for bandwidth allocation based on ToS/DSCP or any other application base-lining/profiling and/or is it customizable based on business applications and usage?

vi)    Is bandwidth allocation and prioritization automatically effected based on centralized policy engine configuration and real time characteristics of WAN access links?

vii)  Given any of the WAN models, can the SDN-WAN solution work in a transparent pilot mode whereby routing, application level traffic flow and security intelligence is gleaned allowing networking teams time to familiarize themselves and iron out any issues before effecting actual production?

viii) What SDN-WAN feature sets will be supported initially out of the box versus over time, to ensure that purpose built appliances such as wide area network optimizers, packet capture & decode tools, firewalls/UTMs, etc.? Note: Sentence not reading correctly.

ix)    Will current routing between CE-PE change and will there be an opportunity to simplify routing across the wide area, given the overlay model with centralized control and distributed forwarding intelligence?

x)     What are the areas where cost savings can be achieved on a one time as well as a continuous run time operating model basis, and by how much?

 

Cost Economics: Topics and Thoughts:

                                               i.     Application-Based Cost Model

                                             ii.     Workload and/or Consumption based cost Model

                                            iii.     Support and/or Maintenance cost model

 

Reliability

i)      For the WAN models inclusive of the different types of access networks, how is the overall resiliency of the solution achieved – list any and all dependencies on – remote site/branch device, hosted/corporate data center head end device, local device adjacencies and LAN/WAN protocol interfacing.

ii)     Can the solution intelligently overcome asymmetric routing  to/from remote sites/branches.

iii)   While it is assumed that the SDN-WAN solution is an overlay design and that existing customer and/or carrier owned WAN routers (CE) / Access routers may remain on premises for some period of time into the future; all the same, how can enterprises  leverage the inherent traffic and application visibility and control within SDN-WAN to deliver business meaningful SLAs on site turn up and operations that go beyond the existing ones – i.e. per site business application and end user level consumption trend and reporting Note: This requirement needs expansion and clarification on what the current and future Business SLA requirements are.

Security

i)      How is AAA (Authentication, Authorization and Accounting) effected for the SDN-WAN solution?

ii)     Is Describe any there a level of integration with TACACS/+, RADIUS, LDAP, or AD, describe

iii)   Describe anyWhat are the cryptography options available for the control and forwarding plane – symmetric and/or asymmetric encryption., provide details as applicable?

iv)    For each type of encryption, list the cryptographic algorithms, key length supported, frequency of key change supported via automation and any disruptive impacts to network operations

v)     In the case of a PKI implementation, explain the CA, CA hierarchy and process for key generation, distribution, backup, recovery, revocation and overall key management. Call out if, where, and how automation without manual intervention is effected across the enterprise SDN-WAN. Note: How does the second sentence fit?

vi)    How are security threats such as spoofing, session hijacking, session playback, electronic eavesdropping/packet sniffing and man-in-the-middle attacks prevented?

vii)  Describe if and how the solution can Can the solution provide real time visibility and alert reporting into any extraneous routes and end points that would be foreign to a customer address space, if yes, provide details

viii) Describe if and how the solution canCan the solution provide secure logical separation for internal corporate traffic, cloud/internet traffic and business partner traffic, provide details?

ix)    Describe if and how the solution can provide Does the solution have any detection and mitigation capabilities for DoS/DDoS type of attacks experienced internally or through the cloud/internet, explain

x)     Does the solution have auto application level identifying capabilities beyond just the port / protocol level to assist with policy management and compliance

xi)    Can the solution through the remote site/branch appliance also provide stateful firewalling, eliminating the need for remote site/branch firewalls.

xii) Edit: Redundancy/Contingency plan: How does product/service work if compromised?

xiii) Edit: Any mention of RBAC/Tiered access with multitenancy?

xiv) Edit: Multi-tenant enforcement and protection?

Manageability

NOTE: Should we consider adding a section here to address those items discussed in the problem statement about user/customer quality of experience, proactively monitoring the Enterprise WAN for faults and performance, automating provisioning of remote sites, etc?

   IV.         Risks and Dependencies: Topics and Thoughts

–        Business Risks and Dependencies

  • Undefined cost-structure and model
  • Undefined Procurement at scale
  • Unknown business strategy (For example: Is the vendor looking to be acquired?)

–        Technical Risks and Dependencies

  • Overlapping architectures during migration phase
  • As a result of bugs and added features, speed and quality of software release cycles
  • New skillsets required to manage, control and operate a software based network service
  • Global scale of WAN environment.
    • For example: For enterprises that are large in scale, how do we ensure a robust solution across a global WAN

 

    V.         Service Management Considerations

Product feature sets and capabilities will significantly influence existing service management processes within an enterprise.  Furthermore, the process linkages and dependencies will vary widely based on the current enterprise support model (in house network team, fully managed service provider/carrier) as well as the tools and platforms situated in-house versus MSP provided & supported.  Based on prevailing WAN support model and organizational service management maturity, enterprises will need to understand upfront all of the  linkages and dependencies so that a process unwind and/or a migratory path can be pursued, one that is not business disruptive and which facilitates the adoption and production implementation of SDN-WAN.

NOTE: Recommend we structure this section according to ITIL good practice areas.  Propose:

  • Service Strategy
    • IT Service Management
    • Service Portfolio Management
    • Financial Management for IT Services
    • Demand Management
    • Business Relationship Management
  • Service Design
    • Design Coordination
    • Service Catalogue Management
    • Service Level Management
    • Availability Management
    • Capacity Management
    • IT Service Continuity Management
    • Information Security Management System
    • Supplier Management
  • Service Transition
    • Transition Planning and Support
    • Change Management
    • Service Asset and Configuration Management
    • Release and Deployment Management
    • Service Validation and Testing
    • Change Evaluation
    • Knowledge Management
  • Service Operation
    • Event Management
    • Incident Management
    • Request Fulfillment
    • Problem Management
    • Identity Management
  • Continual Service Improvement

i)               Provisioning & Quality Management

Request for Service/Service Request Process

Business Performance Management

Benchmarking

Vendor Management

ii)              Systems Management

Change Management

Monitoring

Configuration Management

Release Management

iii)            Service Support

SLA Management

Help Desk

Incident & Problem Management

Patch Management

iv)             Operations Management & Security

Capacity Planning & Management

Financial Management

Infrastructure Performance Engineering

Information Protection & Security

Business Continuity & Disaster Recovery

Compliance & Controls

 

V.         Terminology and Acronyms

This section defines the terms used in this document.

Term Definition Reference
DSL Digital Subscriber Line (DSL) is a family of technologies that provide internet access by transmitting digital data using a local telephone network which uses the Public Switched Telephone Network (PSTN). TBD
LTE Long-Term Evolution (LTE), commonly marketed as 4G LTE, is a standard for wireless communication of high-speed data for mobile phones and data terminals. TBD
ITIL The Information Technology Infrastructure Library (ITIL) is a set of practices for IT service management that focuses on aligning IT services with the needs of business. ITIL
LAN A Local Area Network (LAN) is a computer network that interconnects computers within a limited area such as a home, school, computer laboratory, or office building, using network media. TBD
MPLS Multiprotocol Label Switching (MPLS) is a mechanism in high-performance telecommunications networks that directs data from one network node to the next based on short path labels rather than long network addresses, avoiding complex lookups in a routing table. TBD
MSP A Managed Service Provider (MSP) is a person or organization that accepts and provides managed services. Managed services are the practice of outsourcing day-to-day management responsibilities and functions as a strategic method for improving operations and cutting expenses. TBD
NOC A Network Operations Center (NOC) is one or more locations from which network monitoring and control, or network management, is exercised over a computer, telecommunication or satellite network. TBD
PCI Payment Card Industry (PCI) is … TBD
Remote Site A Remote Site can represent a broad array of assets intended to be “on” the corporate network. A remote site could be: assets in a cloud infrastructure, mobile assets (machines or employees) on a cellular network, branch offices, connectivity into a service bureau, or even represent transient connections to partners. TBD
RFI A Request for Information (RFI) is a standard business process whose purpose is to collect written information about the capabilities of various suppliers. TBD
SDN Software Defined Networking (SDN) is an approach to computer networking that allows network administrators to manage network services through abstraction of lower level functionality by decoupling the system that makes decisions about where traffic is sent (the control plane) from the underlying systems that forward traffic to the selected destination (the data plane). TBD
SDN-WAN A Software Defined Networking-Wide Area Network is … This document
WAN A Wide Area Network (WAN) is a network that covers a broad area (i.e., any telecommunications network that links across metropolitan, regional, national or international boundaries) using leased telecommunication lines. TBD

 

Tags: