1. Automatic network configuration: Position presentation Cristel Pelsser WODNAFO, Feb. 2010

2. Objectives of automatic network configuration Reduce configuration errors Speed-up configuration changes Improve response time in case of unexpected events

3. What are we looking for? A high level language/representation of a network – Should be able to verify a set of network properties (avoid errors) – Should be innovation friendly – Should be easily readable/modifiable for fast problem resolution

4. How to reach that goal? Model network concepts with entity-relationship model – Automatic generation of a matching database – Population of the database from current configuration or simple GUI – Associate router vendor configuration code for each entity and relation Deal with different router configuration syntax !?! Provide high level vendor independent API for router configuration – Follow the relations and configure elements as you go Evolvable

5. Need to agree on routing functionalities Adjacencies (IP addresses) Link weight assignment – With/without IP FRR, TE, … eBGP sessions BGP policies – Customer-provider, peer-peer, backup, blackhole… other interesting policies (Tim?) iBGP topology configuration (RR, iBGP sessions) – Choice of design algorithm Outgoing TE – % of traffic on each inter-AS link with accepted deviation Incoming TE? …

6. Required features Changes tracking Roll back Transaction based update of a network device Automatic generation of network configuration documentation – Javadoc style – Graphical representation Network monitoring and failure reporting – Alerts and network status visualization – Debugging Check points (across layers), similar to breakpoints in programming languages Correctness check of configuration (before committing) – Emulate, simulate, deploy and test on virtual infrastructure (Shadow VNets, A. Wundsam, A. Mehmood, A. Feldmann et al.), static check? Cost?