So, the suggested solution would be to not have validation of information, but simply have misconfigured stuff that violates integrity constraints never show up in the state tree.
Perhaps this is the best that YANG can support today, although I still find this not very satisfying. At a minimum, it would be good if the framework would support an indication whether the configured topology information went into effect or not. The implication is that a client will need to achieve this now by retrieving the corresponding state tree after each configuration operation (and if the configuration would not show correspondingly in the state tree, troubleshoot to see what's wrong). So, if this is taken as design pattern, it would be good to introduce operations to support that. Likewise, it would be good to have a "diffing" operation in which state tree and configuration tree are checked for differences and discrepancies are reported (e.g. config not in state, and possibly vice versa). These should probably be added as requirements for I2Rs and the next revision of the overall YANG+associated protocols framework. --- Alex -----Original Message----- From: Martin Bjorklund [mailto:[email protected]] Sent: Wednesday, February 15, 2017 10:41 AM To: Alexander Clemm <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo Alexander Clemm <[email protected]> wrote: > Hello Martin, > Thank you. Your first explanation is clear. Regarding the expression > of constraints, see inline, below (thread is pruned for clarity) > --- Alex > > -----Original Message----- > From: Martin Bjorklund [mailto:[email protected]] > Sent: Wednesday, February 15, 2017 12:12 AM > To: Alexander Clemm <[email protected]> > Cc: [email protected]; [email protected] > Subject: Re: [i2rs] modeling options for > draft-ietf-i2rs-yang-network-topo > > > <snip> > ................. > I mean that the server will consider a configured item, and decide if > it can be used or not. If the configured item has a reference to > something that doesn't (yet) exist (weak reference; require-instance > false), the server leaves the item in the config, and moves on. At > some later time, suppose the weak reference is fulfilled; at this > point the server decides that the configured item can be used, and it > instantiates the item in the /-state list. Once it is there, maybe > some other configured item has a reference to this one, and it can > also be instantiated etc. > > And it goes the other way as well; suppose a server provided item is > removed by the server; at this point the server would also remove > items in the state list that originated in the configuration - however > they are not removed from the config, just the state. > (Server provided items would only show up in the state in this > solution). > > The state subtree works exactly like the operational-state datastore > in draft-ietf-netmod-revised-datastores. > > <ALEX> > Thank you, this clarifies the earlier statement </ALEX> > > > One of the issues that we are facing is that a configured topology > > might refer to a configured topology or a server-provided topology, > > and we would like to avoid making a case distinction as to which > > category we are referring to. > > I believe my proposed solution handles this. > > > At the same time, we are making use of leafrefs to express a number > > of integrity constraints which are part of the model: as a node is > > part of a topology, and a topology has an underlay topology, we make > > sure that the underlay node is part of the underlay topology (and > > not just any arbitrary node). > > Can you point me to the place in the model where this is specified? > > Or did you mean that today you have to mention this in plain text, but > it would be nice if it could be captured formally in the model? > > <ALEX> It is covered in the model today. E.g.: Ok. Here the model uses require-instance false, so if these ponts to the state tree instead, you'd get the same effect. /martin > > In networks/network/node/supporting-node > leaf network-ref { > type leafref { > path "../../../supporting-network/network-ref"; > require-instance false; > } > (supporting node is contained in supporting network) > > Supporting link: > +--rw supporting-link* [network-ref link-ref] > +--rw network-ref -> ../../../nd:supporting-network/network-ref > +--rw link-ref -> > > /nd:networks/network[nd:network-id=current()/../network-ref]/link/link > -id > > (supporting link is a link contained in the supporting network) > > Supporting termination point: > +--rw supporting-termination-point* [network-ref node-ref tp-ref] > +--rw network-ref -> ../../../nd:supporting-node/network-ref > +--rw node-ref -> ../../../nd:supporting-node/node-ref > +--rw tp-ref -> > > /nd:networks/network[nd:network-id=current()/../network-ref]/node[nd:n > ode-id=current()/../node-ref]/termination-point/tp-id > > (supporting termination point is contained in supporting network and > supporting node) > > It is those leafrefs whose transposition in the split subtree model > (where we encounter alternative paths) I am concerned will be > problematic. > > </ALEX> > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
