Evaluating use cases for white box deployment

31 July 2015

Implied Logic has been developing a number of potential modelling scenarios for the workshop sessions on white-box deployment and implementation at the forthcoming STEM User Group Meeting in October 2015. All of these involve software-defined networking (SDN) on bare-metal switches (white-boxes) in a variety of contexts, and one also envisages network function virtualisation (NFV) for a metro edge router.

Partly to provide more of an insight into the likely proceedings, but also as a gentle introduction for anyone who has so far failed to connect a real-life situation with the hype, here are working outlines of the three specific use-cases we are considering so far.

As you will see, many details remain to be clarified. Any comments or contributions will be gratefully received.

1. Enabling OpenFlow in a campus network

A local network comprises five buildings, each with its own internal wiring. One building is the central node with connection to the carrier’s multi-service gateway/router. Other buildings are connected in a fibre ring or star configuration with a conventional router at each location switching between local building sub-nets and the campus core network.

There is a desire to add SDN features such as liquid bandwidth, dynamic VPNs, and policy-driven networking (which may be essential for some new applications).

Figure 1: Options for enabling OpenFlow in a campus network

Organisational governance may prevent removal of existing traditional L2/L3 routing, or insist on a ‘bedding in’ period of at least one year. Therefore, the aim will be to implement an ‘overlay’ solution which somehow leaves the existing network in place. If it is not possible to run SDN functions on an existing proprietary router, then one alternative is to run a bare-metal switch alongside the original router, together with suitable software to provide both the SDN capabilities and the necessary L2/L3 interworking.

Note: we are still researching the connectivity implications, i.e., whether new services would be available to the whole sub-net via the original router, or only into bare-metal ports.

1.1 Comparative costs – and revenues?

As for any STEM model, we will consider the capex and opex implications of the new solution alongside the opex for the existing network.

  • In principle, the new capex will be modest as a combination of unbranded boxes and open-source software will be used. However, there will be one-off engineering costs for the initial deployment project and some uncertainty as to whether the simpler code base will be mature enough to deliver the promised lower maintenance overhead.
  • The opex for the existing network will include estimates for repairs, maintenance, operations and power.

We can consider the quantitative benefits of new SDN functions, perhaps modelled as a potential reduction in engineering staff as some capabilities move to a self-service model. However, it would miss the point entirely not to capture the perceived qualitative benefits too, perhaps modelled as bonus ‘revenues’ associated with certain qualities:

  • e.g., What would you pay to have self-service configuration?
  • these could be model inputs or even questions to an audience or board.

1.2 Scenarios

A model serves to evaluate a range of possibilities and we use scenarios to compare several possible future journeys for the organisation:

  • Do nothing: cost-minimising organisation has no appetite or perceived requirement for new networking capabilities
  • Governance buster: plans to use seasonal down-time as window for testing total replacement bare-metal switch OpenFlow solution
  • Temporary overlay: deploy parallel white-box solution, but reel in conventional router maintenance contracts within 1–3 years
  • Overlay till end-of-life: add parallel white-box solution, but wait for SDN to mature in remaining lifetime before full switch to bare metal.

2. Bespoke networking for a leaner data centre

Traffic patterns in public cloud data centres have changed from north–south (client-to-server) to east–west (server-to-server). In parallel, network architectures have shifted from three-tiers of switching to flatter, scale-out fabrics which better facilitate scalable, non-blocking, any-to-any connectivity (better performance). The industry is converging on ‘spine-and-leaf’ network designs.

Figure 2: Any-to-any connectivity in a modern data centre

However, there is a concern that conventional, all-purpose switches are over-featured:

  • too expensive
  • over complicated
  • more to go wrong.

So there is an opportunity to re-think such designs with commodity white-box switches:

  • leaner operation (avoid over-complex software, fewer patches when reach maturity, simpler and faster reaction when bugs do show up)
  • less re-routing/re-programming effort on changing demand
  • reduced downtime.

Note: it would be more convincing to tie these implementations to an underlying demand-driven model, but this could quickly get out of hand in terms of complexity and comprehension where the focus could easily drift to the services rather than the fabric.

2.1 Scenarios

This technology is of immediate interest for a greenfield build, but we perceive a much larger audience of existing data centre owners eager to assess their strategic options. So our intention is to model some kind of transition between the two designs:

  • Do nothing: if it ain’t broke, don’t fix it (and risk annoying customers)
  • New customers only: deploy new footprint alongside current design, use for new customers and offer to existing customers who ask while deferring wider roll-out
  • Migrate for competitive advantage: plan for aggressive/phased update with significant write-down to ride next wave of services
  • Plan for next hardware refresh: risk losing market share and new revenues but also benefit from more mature solution

In this case, a bonus question you might ask would be, What would you pay to have your app migration done faster?

3. Streamlining the edge of a metro network

Consider a metro area network which connects multiple enterprise customers via 1GE or 10GE rings. Currently the network interface device (NID) is a managed edge router configured to present various services to the customer such as virtual private circuits and public Internet. High capex and dedicated engineer time are required to connect a new customer.

Figure 3: Migration to network virtualisation in a metro area network

The present conventional routers are expensive to buy and to maintain. Their typically over-featured capability may be replaced with a bare-metal switch with minimum required SDN feature set (as ‘dumb’ as possible, and potentially avoiding the necessity for on-site patching).

The same services can be delivered on virtual circuits from a carrier aggregation node running an OpenFlow virtual routing app for each customer. This results in an economy of scale (compared to distributed intelligence and processing) and offers the potential for orchestration in a central office compared to managing multiple remote devices.

3.1 Scenarios

Again we will model a number of alternative futures, enabling a carrier to determine whether and when this is for them, subject to suitable customisation of the assumptions and inputs:

  • Do nothing: if it ain’t broke, don’t fix it (and risk annoying customers)
  • Test site: deploy new solution at an internal test site for one year, and then flat roll-out to customers over next two years (pain with slow gain)
  • Beta test: offer 1-year discount to 10% of customers to try out new solution before roll-out to the other 90% (solve problems sooner)
  • Phased introduction: minimal lab test period then S-curve roll-out (hire extra customer service agents and take it on the chin).

In this case, a bonus question you might ask would be, What would you pay to halve the lead time for a new customer?

4. Work in progress

As you can see, these outlines are still at a formative stage. We look forward to your input as we start to build the models for each of these cases. The climax of the exercise will be the point when we work through the details with the assembled experts from various vendors and operators at the STEM User Group Meeting in October 2015.

Visual modelling of complex business structures

A STEM model is flexible by design, just like the SDN technology being modelled: if the drivers or assumptions prove to be suspect, we will re-work the models visually there and then. This agility is a defining characteristic of the software and facilitates keen audience participation at the user group event, as well as the commercial modelling workshops we run for our clients.

Free subscription when we review your business model

How well do you understand your business? It may be profitable now, but how prepared are you for this to change? We have a track record of analysing individual services or entire businesses in an interactive workshop style that engages and informs. Our visual software enables multi-disciplinary dialogue about the business you thought you knew and the more uncertain future ahead.

Read the article

STEM User Group Meeting 2017 proceedings

Our most recent customer event was held on 27–28 September 2017 at King’s College, Cambridge. The modelling track explored three growth models for a start-up business, from unconstrained to measured to driven. The remainder of the event covered the forthcoming STEM version 8.0, the revised business model for Implied Logic, and two guest presentations.

Read the article

A freshly baked model of a start-up

We examine Michaela’s Best Bread Direct service, from her first unconstrained vision, through a more realistic measured phase and finally to a more ambitious, customer-driven approach. We demonstrate how STEM can be applied to almost any business topic and always delivers a systematic and reliable treatment of time and money.

Read the article

Business-case design and training at your service

Ever wondered what we do at Implied Logic? We have recently posted a comprehensive update to our services portfolio online which is effectively a self-service proposal for everything from online training on-demand through to on-site business-modelling consulting and hosting services for business models on the web.

Read the article

Connecting elements to graphs and publishing online

In what is likely to be the final preview article for the forthcoming STEM version 8.0, we explore visual connections between individual icons and a related graph, as well as intuitive, interactive options for adding an element to an existing graph. We also explore new layout options for pushing a presentation of results in STEM to the web.

Read the article

Our latest help and training materials

Documentation is never regarded as a very exciting activity, but our comprehensive help and training materials are a vital element of the self-serve experience with STEM. In the last quarter we have posted two significant updates to our online help site which enhance both of these aspects.

Read the article

A radical re-think on STEM pricing

We announce a new freemium strategy for accessing the STEM software, including a free and fully-functional demo system for small projects and study as a taster for an innovative minimal-support subscription to the Conventional STEM (C-STEM) desktop solution at just GBP 330 p.a..

Read the article

Vision for the forthcoming STEM 8.0

As part of our vision for a more intuitive way of working that bridges previous mental leaps wherever possible, we preview another two features of the forthcoming STEM version 8.0 – direct-draw connect mode and more flexible user data – that form part of a joined-up approach to fulfilling this dream.

Read the article

© Implied Logic Limited