1 / 11

Network Automation

Network Automation. Albert Greenberg, Nick Feamster, Richard Mortier, Mark Poepping, Lun Li, Sharad Agarwal, Changhoon Kim, Ramveer Chandra,  et al. What is network automation?. The performance of the following network tasks with minimal human involvement: Provisioning Detection Diagnosis

rhannah
Download Presentation

Network Automation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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? • No…it’s more about automating folklore? • Care costs >> Ops costs, so self-help >> 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 don’t 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 away…sort 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 there’s 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 don’t 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? • Coke’s network vs Pepsi’s 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 isn’t 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”)

More Related