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

"Xufeng Liu" <xufeng.liu.ietf@gmail.com> wrote:
> 
> 
> > -----Original Message-----
> > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin Bjorklund
> > Sent: Wednesday, February 15, 2017 1:41 PM
> > To: alexander.clemm@huawei.com
> > Cc: i2rs@ietf.org; kwatsen@juniper.net
> > Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo
> > 
> > Alexander Clemm <alexander.clemm@huawei.com> 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:mbj@tail-f.com]
> > > Sent: Wednesday, February 15, 2017 12:12 AM
> > > To: Alexander Clemm <alexander.clemm@huawei.com>
> > > Cc: kwatsen@juniper.net; i2rs@ietf.org
> > > 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.
> > 
> 
> [Xufeng] Does the leafref point to the "state tree" only? If we do so, we
> will miss the other half - the possible dependency to the config tree. If we
> let the leafref point to both, we will get the unmanageable complications.

The idea was that the leafref would point to state only.  You will not
really miss the dependency to the config tree; see my description
above.

/martin

> 
> > 
> > /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
> > i2rs@ietf.org
> > https://www.ietf.org/mailman/listinfo/i2rs
> 