Dynamic Service Configuration and Automated Network Configuration with NETCONF and YANG Carl Moberg VP of Engineering, Tai...
Introducing Myself <ul><li>VP Engineering at Tail-f Systems with background in Network Operations (AS1299 and AS3301) </li...
The Problem <ul><li>The problem is: historically no standard (formal or informal) for configuration management </li></ul><...
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 acr...
Current Service Automation <ul><li>Network-oriented services are increasingly: </li></ul><ul><ul><li>Complex </li></ul></u...
Impact on Service Automation <ul><li>Service Quality </li></ul><ul><ul><li>High failure rates </li></ul></ul><ul><ul><li>N...
Introducing a Solution <ul><li>Operators told the IETF in 2001 that they saw no developments addressing their configuratio...
NETCONF and YANG Highlights <ul><li>The NETCONF Protocol: </li></ul><ul><ul><li>Distinction between configuration and stat...
Impact on Service Automation <ul><li>Before </li></ul><ul><li>Service Quality </li></ul><ul><ul><li>High failure rates </l...
Looking Ahead <ul><li>We are climbing a giant, heading for shoulders: </li></ul><ul><ul><li>The network as a schema-driven...
Conclusions <ul><li>Current state of industry is legacy, proprietary (or both) and not good enough </li></ul><ul><li>Every...
Thank You www.tail-f.com [email_address]
Upcoming SlideShare
Loading in …5
×

Moberg Keynote - Network Automatio, Paris, 2010

1,126 views

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.

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
1,126
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
55
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Moberg Keynote - Network Automatio, Paris, 2010

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 12. Thank You www.tail-f.com [email_address]

×