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: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>
>
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
