Juergen: You are correct that I2RS ephemeral validation !:== YANG config true validation (where !:== - means is not defined as). This is why we defined Ephemeral-REQ-03. Otherwise, we would not have added it to the list of requirements.
There is a range of state (static ----> virtual (configured/not existent) ---> LSPs). You may want to look at OSPF Yang to consider the virtual-links. IMHO, NETCONF is being provided with requirements to that suggest changes to constraint checking for Ephemeral Configuration State. In many messages, you asked for requirement and not design. In your discussions, I have not heard any suggestions regarding new text for the ephemeral state document. Did you have any specific suggestions? Sue -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Juergen Schoenwaelder Sent: Tuesday, June 07, 2016 10:22 AM To: Susan Hares Cc: 'Jeffrey Haas'; [email protected]; 'Joel M. Halpern' Subject: Re: [i2rs] Ephemeral State Requirements discussion Sue, Ephemeral-REQ-03 seems to be in conflict with what YANG validation rules expects. If I2RS validation depends on 'temporary operational state', then the validation result is only meaningful at a specific point in time; YANG validation specially avoids this in order to have the property that a configuration that is valid remains valid (and does not become invalid if 'temporary operational state' changes. Hence: I2RS ephemeral validation != YANG config true validation /js On Mon, Jun 06, 2016 at 07:05:15PM -0400, Susan Hares wrote: > Juergen: > > Thank you for the pointer, I am assuming you are referring to section > 8.3 on constraint enforcement (from RFC6020bis), and as a part of > constraint enforcement, the validation. > > I2RS ephemeral requirements 1-4 are: > Ephemeral-REQ-01: I2RS requires ephemeral configuration state; i.e. > state that does not persist > across reboots. If state must be restored, it should be done solely > by replay actions from the I2RS client via the I2RS agent. > > Ephemeral-REQ-02: Non-ephemeral state MUST NOT refer to ephemeral > state for constraint purposes; > it SHALL be considered a validation error if it does. > Ephemeral-REQ-03: Ephemeral state must be able to utilized > temporary operational state > (e.g. MPLS LSP-ID or a BGP IN-RIB) as a constraints. > Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state > for purposes of implementing constraints. > > I2RS uses the definition you do of constraint and validation. For > discussion purposes, let us consider "ephemeral state" in these > requirements as "ephemeral configuration state". > > What needs to be expanded for Ephemeral Configuration State is the > second paragraph of section 8.3.3 to include ephemeral state. In the > end, the ephemeral configuration parsing of rpc payloads, > <edit-config>, and validation MUST obey all validation constraints. > What we are discussing is "when" and "how" the I2RS constraint enforcement occurs, and "when" and > "how" validation occurs. > > Sue > > > ================ > For reference of I2RS list > > 8.3. NETCONF Constraint Enforcement Model > > For configuration data, there are three windows when constraints MUST > be enforced: > o during parsing of RPC payloads - > o during processing of the <edit-config> operation > o during validation > Each of these scenarios is considered in the following sections. > > > 8.3.3. Validation > > When datastore processing is complete, the final contents MUST obey > all validation constraints. This validation processing is performed > at differing times according to the datastore. > > If the datastore is "running" or "startup", these constraints MUST > be enforced at the end > of the <edit-config> or <copy-config> operation. If the datastore is > "candidate", the constraint enforcement is delayed until a <commit> > or <validate> operation. > > > > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:[email protected]] > Sent: Monday, June 06, 2016 4:04 PM > To: Susan Hares > Cc: 'Jeffrey Haas'; [email protected]; 'Joel M. Halpern' > Subject: Re: [i2rs] Ephemeral State Requirements discussion > > On Mon, Jun 06, 2016 at 03:07:13PM -0400, Susan Hares wrote: > > Juergen: > > > > Please start by defining validation for NETCONF configuration. > > Then, we can provide the additions for ephemeral configuration state > > that are not in ephemeral requirements. See the rest of the comments below. > > > > The validation of NETCONF configurations modelled in YANG 1.0 is > defined in RFC 6020 and for configurations modelled in YANG 1.1 it is > defined in draft-ietf-netmod-rfc6020bis-12. > > /js > > PS: Our communication is not effective, I drop out for now. > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
