ONF Connect 2019

To use a fully-programmable switch chip, one has to describe the switch pipeline using P4. However, Google, like most of the industry, still relies on fixed-function switch chips in our infrastructure. This will continue for years to come. We believe that using a single contract to specify forwarding behavior across our entire infrastructure has huge value, beyond the benefits of dynamic switch reconfiguration in a subset of the fabric:

First, having a P4 program that clearly describes the semantics of our switches enables automated validation. Second, making our requirements use-case-centric, rather than based on switch capability, simplifies portability across vendors. Our P4 programs model what we need from the switch in a particular role, not what the switch provides. Third, many fixed function switch chips have some programmable parts. We have a compiler that inspects our P4 programs, and generates the appropriate switch configuration for these.

In this talk we will explain how we leveraged P4 to automatically validate a switch against the desired specification, expressed as a P4 program. We employ a range of techniques to validate both the dataplane and controlplane interfaces of a switch:
- Fuzzing the controlplane (through P4Runtime) by randomly generating flows, groups and members;
- Automatically generating interesting input packets that validate the packet forwarding behavior of the switch. We define a notion of “test coverage” for testing the dataplane and show that our approach automatically achieves 100% coverage.
- Validating table counters, meters, and other aspects of the forwarding pipeline.