Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo

[Martin Bjorklund <[e-mail]>]

Alexander Clemm <[e-mail]> 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:[e-mail]] 
> Sent: Wednesday, February 15, 2017 12:12 AM
> To: Alexander Clemm <[e-mail]>
> Cc: [e-mail]; [e-mail]
> 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:node-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>
>  
>