• Like

Moberg Keynote - Network Automatio, Paris, 2010

  • 700 views
Uploaded on

Carl Moberg, VP Engineering Tail-f Systems presented at Network Automation Conference on Dynamic Service Configuration and Automated Network Configuration with NETCONF and YANG. …

Carl Moberg, VP Engineering Tail-f Systems presented at Network Automation Conference on Dynamic Service Configuration and Automated Network Configuration with NETCONF and YANG.

http://www.tail-f.com

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
700
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
15
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Dynamic Service Configuration and Automated Network Configuration with NETCONF and YANG Carl Moberg VP of Engineering, Tail-f Systems <calle@tail-f.com> @cmoberg on twitter
  • 2. Introducing Myself
    • VP Engineering at Tail-f Systems with background in Network Operations (AS1299 and AS3301)
    • Have had head under the hood of many network products with recurring nightmares from what I’ve seen:
      • “ We didn’t really think about a ‘show config’ command”
      • “ So what you’re saying is that operators normally expects a CLI on the box?”
    • On-device OAM is more often than not an afterthought in terms of resources and timing…
    • … which is the main contribution to our current situation.
  • 3. The Problem
    • The problem is: historically no standard (formal or informal) for configuration management
    • It is a problem because: impedance between service and infrastructure domains can only be solved by large amounts of manual labor, code and risk
  • 4. How bad is it?
    • Things that one would expect be possible:
      • “ I’d like to apply this change across two or more boxes and automatically roll both back if one fails”
      • “ I’d like to back up configuration from one box and store it for later rollback”
    • Ways to address this:
      • Make changes manually using expert resources (opex)
      • Develop and maintain abstraction in house (direct capex)
      • Third party to develop and maintain abstraction (indirect capex)
  • 5. Current Service Automation
    • Network-oriented services are increasingly:
      • Complex
      • High frequency
      • Costly to fail
      • Scaling up
    • Examples network-oriented services:
      • Enterprise VPNs - network order failures delay customer access
      • Mobile Backhaul - delay in provisioning impacts cell opex
      • VLAN provisioning for virtualized workloads - just won’t work
  • 6. Impact on Service Automation
    • Service Quality
      • High failure rates
      • Network inconsistencies
    • Provisioning Software
      • Heavy, expensive device abstractions
      • Least common denominator-features
    • Operational Staff
      • Commonly part of the automation loop
      • Vendor-specific expertise for common tasks
  • 7. Introducing a Solution
    • Operators told the IETF in 2001 that they saw no developments addressing their configuration management protocols
    • This is documented in RFC 3535
    • Document work timeline:
      • 2002 – Network Management Workshops
      • 2006 – NETCONF base RFC published
      • Now – YANG standard document in final phase
  • 8. NETCONF and YANG Highlights
    • The NETCONF Protocol:
      • Distinction between configuration and state data
      • Change validations
      • Multi-box Transactions
      • Selective data retrieval
      • Extensible RPCs
    • The YANG Language:
      • Human readable
      • Formal constraints
      • Hierarchical
      • Extensibility through augmentation
  • 9. Impact on Service Automation
    • Before
    • Service Quality
      • High failure rates
      • Network inconsistencies
    • Provisioning Software
      • Heavy, expensive device abstractions
      • Least common denominator features
    • Operational Staff
      • Commonly part of the automation loop
      • Vendor-specific expertise for common tasks
    • After
    • Service Quality
      • Validated changes
      • Transactions
    • Provisioning Software
      • Device abstractions is inherent to protocol
      • Focus on value-added features
    • Operational Staff
      • Tasks that can be, will be, automated
      • Vendor-specific expertise for vendor specific features
  • 10. Looking Ahead
    • We are climbing a giant, heading for shoulders:
      • The network as a schema-driven database?
      • How dynamic do we want the network to be?
      • Next useful layer of abstraction?
    • Thoughts on industry impact:
      • How open will vendors want to be? Can they?
      • New breed of third party automation vendors?
      • Impact on standards?
  • 11. Conclusions
    • Current state of industry is legacy, proprietary (or both) and not good enough
    • Everything possible with programming but cost and risk remains
    • NETCONF and YANG is a solution with focus on the core of the problem
    • Interesting times ahead
  • 12. Thank You www.tail-f.com [email_address]