1 / 7

YANG Background and Discussion: Why we need a new language for NETCONF configuration modeling

The YANG Gang IETF 70 Vancouver, Canada. YANG Background and Discussion: Why we need a new language for NETCONF configuration modeling. NETCONF: how we got here. NETCONF base protocol defined in RFC4741 Defines RPC mechanism and operations Leaves content and data models for future work

dallon
Download Presentation

YANG Background and Discussion: Why we need a new language for NETCONF configuration modeling

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. The YANG Gang IETF 70 Vancouver, Canada YANG Background and Discussion:Why we need a new language for NETCONF configuration modeling

  2. NETCONF: how we got here • NETCONF base protocol defined in RFC4741 • Defines RPC mechanism and operations • Leaves content and data models for future work • <get>, <get-config> and <edit-config> allow any XML • No data modeling language == no data models

  3. YANG • Immediate need for a NETCONF DML • Allow interoperability • Be able to consume models from everyone, use tools from anywhere • Multi-vendor design group • Leverage experience gained from multiple implementations • Meeting over the past 7 months • Building blocks to write NETCONF “MIBs” • Configuration, RPCs, notifications • Formal syntax for automation • Generate XSD or RelaxNG for manager/application • Tools available today on yang-central.org

  4. NETCONF-specific Issues • Expressing default values, config data vs state data, integrity constraints • Protocol operations effects on models (e.g., coupling to <edit-config> • Key constructs • Instance naming • “augment” extends existing models • NETCONF error messages

  5. Why not an XML schema language? • Schema languages describe syntax of a document • YANG models the semantics of a database • Constraints on the finished product • Commit time • Operations guided by the model • Semantics drive the syntax • Simple XML validation is not sufficient • Example: Mandatory fields must appear in all instances • But don't appear in every RPC (“delete”)

  6. Extended Subset Syndrome • Need to limit XML schema languages • Limit content for NETCONF integration • Avoid inappropriate constructs • Need to allow semantic information • Add extensions for NETCONF-specific information • What are you left with? • Knowing the schema language isn’t sufficient • Tools can’t enforce constraints • SMI’s use of ASN.1 is a famous example • Extended subset of ASN.1 1987 • Standard tools cannot be used

  7. YANG hits the mark • Readability Rules • Simple, direct, extensible • Email, patch, and RFC friendly • Didn't boil the ocean • Limited scope • But maximize utility within that scope • Based on three proprietary DMLs • Years of experience within multiple vendors • Quality draft backed by running code • Usable in current form • Download the code and use it today

More Related