PC, or a separate configuration file that defines that mapping, is used. In the example below, we have a container for the "vpn" that is used for the create-vpn RPC from the service model. In the complete network model, there is another container for "vpn-pe" that maps to the RPC from "attach-to-vpn" RPC message in the service model. The intent of a network model and in particular, a container in a network model (e.g., the virtual compute and storage environment in which the network function runs), is that once all the "leafs" have been assigned (implicitly completing all engineering rules for each resource to be assigned and for the resulting container) then the network state can be changed. In the network controller, the process of filling out the leaves in the network data model is performed by the DG logic. That logic uses the data items in the network data model as the "context" data storage blob that needs to be filled out for the RPC event message being processed. One of the advantages or uses of the network YANG model is the definition of the data items that will be stored in the database repository for the customer service. Class libraries and helper functions can be autogenerated from the YANG model, but the most important aspect from a devel- opment cycle time standpoint is that the YANG model will be used to autogenerate the context structure and persistent storage structures. Building the Network of the Future module vpn-network { namespace "urn: opendaylight:vpn" prefix vpn; import ietf-inet-types {prefix inet;} revision "2014-06-03" description "Example VPN Network Module"; container vpn { leaf resource-vpn-id { type uint32; // <allocate type="vpn-id" saveAs="$vpn-id" 1> leaf cust-id{ type uint32; leaf vpn-name { type string; leaf topology { type string; // hub&spoke; any-to-any -> could do as ENUM container vpn-pe leaf ref-resource-vpn-id { type uint32; list pe { key "equipment-clli" leaf equipment-clli { type string; leaf network-type{ type string; leaf resource-route-target-any { type uint32; //