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

["Xufeng Liu" <[e-mail]>]

> -----Original Message-----
> From: i2rs [mailto:[e-mail]] On Behalf Of Martin Bjorklund
> Sent: Wednesday, February 15, 2017 1:41 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo
> 
> 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.
> 

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

> 
> /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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs