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

[Alexander Clemm <[e-mail]>]

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.:

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>