Your SlideShare is downloading. ×
0
Moberg   Keynote - Network Automatio, Paris, 2010
Moberg   Keynote - Network Automatio, Paris, 2010
Moberg   Keynote - Network Automatio, Paris, 2010
Moberg   Keynote - Network Automatio, Paris, 2010
Moberg   Keynote - Network Automatio, Paris, 2010
Moberg   Keynote - Network Automatio, Paris, 2010
Moberg   Keynote - Network Automatio, Paris, 2010
Moberg   Keynote - Network Automatio, Paris, 2010
Moberg   Keynote - Network Automatio, Paris, 2010
Moberg   Keynote - Network Automatio, Paris, 2010
Moberg   Keynote - Network Automatio, Paris, 2010
Moberg   Keynote - Network Automatio, Paris, 2010
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Moberg Keynote - Network Automatio, Paris, 2010

767

Published 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

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

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

×