In relationship to that the discussion about can or can't the model mix operational state there are a couple of sentences in "draft-ietf-i2rs-yang-l3-topology-00.txt" thats seems crucial to this and I guess should be reworked.
" There are several reasons to choose YANG to define the data model. Data defined using YANG can be exposed by a server to client applications and controllers via Netconf [RFC6241] or via a ReST Interface [I-D.draft-ietf-netconf-restconf] [I-D.draft-ietf-netmod-yang-json]. The fact that it can be used with different protocols and interfaces provides for a degree of "future- proofing" of model implementations. Also, YANG can serve as the basis for model-driven toolchains, such as used in the Open Daylight project. " I would suggest to explain a bit what is a model-driven tool chain instead of citing a tool that is based on a such. Or just put a reference to draft-ietf-i2rs-yang-network-topo where the topic is explained much better. In that one could also be added the suggestions of Martin on different approaches on handling dynamic operational state with static config state. This in particular was always an issue for me as a network service fulfillment guy. It is a big debate in network services provisioning should I consider the configuration as a guideline or the current state and how to match those well especially in heterogeneous networks. I always boils down to matching config with a bunch of state data coming from SNMP which is typically a horrible stuff. Hope i2rs to solve me that kind of an issues :) Also in that direction in OSS people typically use SID for modeling networks, resources (logical or physical) and the services provided by them. Did anybody considered any kind of a mapping between the yang models and the SID kind of models? Nikolay On Fri, Oct 23, 2015 at 10:21 AM, Martin Bjorklund <[email protected]> wrote: > "Alexander Clemm (alex)" <[email protected]> wrote: > > Hi Martin, > > > > Agree, we need to add text for this. Good catch. > > > > The reality is that the integrity of the links between overlay and > > underlay will be broken. The fact that those links will be > > invalidated is something that ultimately needs to be indicated. > > But then they cannot be normal leafrefs. You can use the new YANG 1.1 > statement "require-instance false" to handle this. > > > Since the interface analogy was brought up, this problem is actually > > faced by layered interfaces that are user controlled as as well. What > > is the solution that is applied there? (I guess it is basically left > > up to the application, correct?) > > There is no generic model for this in RFC 7223, but there are three > options: (i) use YANG 1.1 require-instance false (ii) require the > underlying interface to be configured (even if it is > system-controlled) or (iii) use an implicit reference. > > > > /martin > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > -- BR, Nikolay Milovanov Network Engineer Email: [email protected]
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
