Session 1, Paper 3: PGA: Using graphs to express and automatically reconcile network policies

Authors: Chaithan Prakash (University of Wisconsin-Madison), Jeongkeun Lee (HP Labs), Yoshio Turner (Banyan), Joon-Myung Kang (HP Labs), Aditya Akella (University of Wisconsin-Madison), Sujata Banerjee (HP Labs), Charles Clark (HP Labs), Yadi Ma (HP Labs), Puneet Sharma (HP Labs), Ying Zhang (HP Labs)

Presenter: Chaithan Prakash from HB Labs

Paper: http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p29.pdf

Public Review: http://conferences.sigcomm.org/sigcomm/2015/pdf/reviews/346pr.pdf

PGA stands for Policy Graph Abstraction
It aims at providing an intuitive & simple API in which network operators can express and combine network policies. PGA is close to the kind of graph-based representations network operators would draw on a white board.

Network policy management is a challenge:
Different types of policies by different stakeholders have to be combined into a single coherent, well-formed policy that satisfies the constraints imposed by the individual policies.
In practice, this "intent-composition" is usually performed manually by network operators.
-> not scalable, error prone, low-level

High level languages such as Pyretic, NetKAT, ... provide composition operators; but they are not sufficient (?) to compose high-level policies.

PGA aims to provide:
* Simple, inutuitive abstractions
* portable policies (decoupled from network specifics)
* automatic policy composition

Model:
Nodes represent groups of end-points (EPG) that satisfy a certain membership predicate
Directed edges represent allowed communication
Edge attributes: classifiers/service chains/network functions, for example what port, byte counting, through load balancer
Labels: capture endpoint attributes: tenant, location, security status (logical labels)
Several graphs are composed into single graph by composition algorithm.

The authors have implemented a prototype in Python. It provides a GUI to input graphs, and uses one of the following two backends to deploy the resulting policies:
  * Pox controller in reactive mode -> OpenFlow
  * OpenStack Neutron

The runtime overhead (for executing policies) is in the sub-ms area.
Compilation scales:
  (a) <10 min, < 1.2 GB for a graph with 1 million edges, but no network functions
  (b) <14mins, < 20 GB when randomly inserting network functions into the graph.

There will be a live demo of the prototype tomorrow.



Questions (incomplete & paraphrased)
Q1: Complex policies combination, how do you know it's right?
A: Intuitive framework; no absolute guarantees. System raises flag if well-formed composition is impossible.