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

Kent, Alex, and Martin: 

These are clarifying question regarding the future when revised data stores
is deployed:  

1)      If I2RS topology model and L3 Topology models are generic model in
the configuration data store,  . 

a.       is disabling validation using the require-instance false path in
configuration is the best mechanism you can obtain for the configuration not
being there?  

b.      Is get-state the appropriate information to determine what is the
applied data store? 

c.       Can notifications operate on changes in operational state in the
applied data store?  That is, if the server-supplied information is updated
can notifications provide the signaling of the topology node being added to
the operational state? 

2)      If I2RS topology model and L3 Topology model are models in the
ephemeral data store? 

a.       Can the long-term solution Kent proposed in
https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html

                      be supported by the basic get-data
<datastore-ephemeral>,  write-data <datastore-ephemeral> (or your
equivalent) 

                     get-state <applied-state> and notification services?  

Sue Hares 

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Kent Watsen
Sent: Wednesday, February 15, 2017 2:28 PM
To: Alexander Clemm; Martin Bjorklund
Cc: i2rs@ietf.org
Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo

> So, the suggested solution would be to not have validation of 

> information, but simply have misconfigured stuff that violates 

> integrity constraints never show up in the state tree.

A leafref with require-instance false, even if pointing to a path in the
configuration, effectively disables validation.  Still, I think a leafref is
better than just a description statement.

> Perhaps this is the best that YANG can support today, although I still 

> find this not very satisfying.  At a minimum, it would be good if the 

> framework would support an indication whether the configured topology 

> information went into effect or not.

The revised-datastore solution is intended to provide a way to show this.
See draft-ietf-netmod-opstate-reqs.

> The implication is that a client will need to achieve this now by 

> retrieving the corresponding state tree after each configuration 

> operation (and if the configuration would not show correspondingly in 

> the state tree, troubleshoot to see

> what's wrong).   So, if this is taken as design pattern, it

> would be good to introduce operations to support that.

See draft-ietf-netmod-opstate-reqs.

> Likewise, it would be good to have a "diffing" operation in which 

> state tree and configuration tree are checked for differences and 

> discrepancies are reported (e.g. config not in state, and possibly 

> vice versa).

See opstate-reqs, requirement 2-C.

> These should probably

> be added as requirements for I2Rs and the next revision of 

> the overall YANG+associated protocols framework.    

Sure, but I don't think this is needed, as we already have the opstate-reqs
draft.

Kent

_______________________________________________

i2rs mailing list

 <mailto:i2rs@ietf.org> i2rs@ietf.org

 <https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs