Network Automation

1
Network Automation

• Albert Greenberg, Nick Feamster, Richard Mortier,
  Mark Poepping, Lun Li, Sharad Agarwal, Changhoon
  Kim, Ramveer Chandra, et al.

2
What is network automation?

• The performance of the following network tasks
  with minimal human involvement
• Provisioning
• Detection
• Diagnosis
• Remediation
• Corollary Humans become involved with network
  operation at higher levels (i.e., not repeatedly
  doing the same painful tasks)

3
Some Questions

• Why automate?
• What to automate? (desired end states)
• How do we get there?
• Robotize current methodology, or rethink?
• Self-correction (like biological systems, e.g.,
  DNA)
• What are the roadblocks?
• Are our network element building blocks and their
  behavior fit for automation?
• Big guard rails?

4
Why Automate?

• Human cost
• Are we talking about making operators redundant?
• Noits more about automating folklore?
• Care costs gtgt Ops costs, so self-help gtgt
  self-managing?
• Reliability!!!
• Continuous high quality service very high
  availability
• Faster detection, remediation, etc.
• Scale!!!
• How else to keep up with feature creep?
• Every case is a special case (we dont really
  believe this)

5
What to Automate?

• Proactive Piece
• Is-ness spec driving automation?
• Reactive Piece
• Detection (See)
• Possible to monitor and detect network problems?
• What data sets are needed?
• How to do correlation of those datasets?
  (metadata)
• The role of detection vs. statistical analysis
• Diagnosis (Know)
• Again, what data needs to be collected to make
  this possible
• Stat based vs model based?
• Remediation (Restore)
• Do we want automated scripts

How far along this spectrum to go? (Many
answers.)
6
Vision

• Network operators plug in boxes, and walk
  awaysort of
• A small set of policies trigger programs which
  write programs which write programs which
  realizes the network
• A small set of probes provide all measurements
  and event collection/ correlation needed to
  support internal metrics and external SLAs
• Knowledge database
• Operators become specialists forensics, software
  development, etc. (operation at a higher level,
  less fire-fighting)
• Caveat there will always be a need for amazing
  people, but doing more introspective work
  (design, test, certification ... and automation
  over-ride when needed)

7
Roadblocks

• Cost
• Complexity
• Data
• Knowledge
• Human factors

8
Obstacle 1 Cost

• Automation costs money and time
• Worth detecting if theres nothing to do about
  it?
• Worth automating if the operation only happens
  once?
• Alternate solution 1 Monkeys
• At what point is it time to automate the corner
  case
• Alternate solution 2 Overprovision
• Perhaps we can ride out the storm (or expect
  failures and design low cost systems so that they
  dont really matter)
• Server community has seen that repeatable simple
  components software can provide both very low
  cost and resilient whole (e.g., Google switching
  and computing platform)

9
Obstacle 2 Complexity

• How to manage it?
• Dummy boxes and lots of wires/stitching
• Monolithic box with complexity in configuration
• Fewer types of boxes, templates, ways to do
  essentially the same thing?
• Cokes network vs Pepsis network?

10
Obstacle 3 Data

• Lots of inputs
• Topology
• Configuration
• Fault events (measured and logged)
• Performance events (e.g., active measurements)
• Version numbers
• Fiber mappings
• Metadata
• Crucial! Version numbers, gaps in data
  collection, collection method, staleness
• If this data goes inconsistent, big surprises!
• Challenges
• Correlation
• what to do when data isnt correlated?
• Privacy and sharing issues

11
Obstacle 4 Human Nature/Corner Cases

• Operators are used to touching routers
• Automation effectively adds a shim
• Humans will likely want a way to bypass the
  configuration database
• How to maintain consistency between human
  tweakage and the database?
• How to evolve the automation database? (when
  does a corner case become normal)