Evaluating use cases for white box deployment

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.

My account (log-in)

© Implied Logic Limited

Contact | Downloads | Core team and advisory board