Re: [i2rs] Ephemeral State Requirements discussion

["Susan Hares" <[e-mail]>]

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:[e-mail]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, June 07, 2016 10:22 AM
To: Susan Hares
Cc: 'Jeffrey Haas'; [e-mail]; '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:[e-mail]]
> Sent: Monday, June 06, 2016 4:04 PM
> To: Susan Hares
> Cc: 'Jeffrey Haas'; [e-mail]; '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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>

_______________________________________________
i2rs mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i2rs