Re: [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !!

This case is another reason why the intended config should not be touched by the server. Juergen is right that there are lots of different implementations. It is the implementer¹s choice where to put configuration state. Typically if a server supports rollback, the state is stored in a database, o

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

-02 17:38, "Juergen Schoenwaelder" wrote: >On Mon, Feb 08, 2016 at 02:53:57PM +, Gert Grammel wrote: >> >> >> >This is not what is being proposed. We always had >> > >> >[candidate] -> [running] -> operational state >> > >&

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

On 2016-05-02 18:34, "netmod on behalf of Juergen Schoenwaelder" wrote: >On Fri, Feb 05, 2016 at 05:22:03PM +, Robert Wilton wrote: >> >> 2. Personally, for a datastore solution, I would prefer if the new >> datastore was for the intended configuration, and that the applied >> configuratio

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

Hi Kent, On P.7 the current draft says: "Any rollback that may occur will restore both the intended and the applied configurations to their previous states." It is not clear to me to which phase of the configuration this statement refers to. In draft-ietf-netmod-opstate-reqs-04, Asynchronous oper

Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt

On 2016-18-01 10:47, "netmod on behalf of Robert Wilton" wrote: > > >On 16/01/2016 10:39, Juergen Schoenwaelder wrote: >> On Fri, Jan 15, 2016 at 11:15:47PM +, Kent Watsen wrote: This direction of the relationship might in some cases be a relatively trivial and predictable 1:1 rel

Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt

See below .. On 2016-15-01 18:24, "netmod on behalf of Robert Wilton" wrote: >Hi Kent, > >On 11/01/2016 20:59, Kent Watsen wrote: >> Hi Benoit, >> >> >>> You use MUST, SHOULD, MAY, and you refer to RFC 2119. Fine. >>> However, it might be beneficial to say something such as in RFC 7698 >>> >>>

Re: [netmod] Summary of "applied configuration and system-controlled entries" discussions

Rob, Thank you for the effort, it¹s really useful. Gert On 2016-15-01 19:21, "netmod on behalf of Robert Wilton" wrote: >Hi, > >Over the last week or so there has been quite a lot of discussion and >longs threads regarding applied configuration and system-controlled >entries. > >To try and bri

Re: [netmod] applied configuration and system-controlled entries

ied please so that we can focus on that. > >Thanks, >Rob > > >On 13/01/2016 11:33, Gert Grammel wrote: >> >> On 2016-12-01 18:36, "Robert Wilton" wrote: >> >>> >>> On 12/01/2016 16:02, Gert Grammel wrote: >>>> On 2016-12-01 15:

Re: [netmod] applied configuration and system-controlled entries

On 2016-12-01 18:36, "Robert Wilton" wrote: > > >On 12/01/2016 16:02, Gert Grammel wrote: >> >> On 2016-12-01 15:04, "Robert Wilton" wrote: >> >>> >>> On 12/01/2016 10:42, Gert Grammel wrote: >>>> On 2016-12-01 11:

Re: [netmod] applied configuration and system-controlled entries

On 2016-12-01 15:04, "Robert Wilton" wrote: > > >On 12/01/2016 10:42, Gert Grammel wrote: >> >> On 2016-12-01 11:12, "netmod on behalf of Robert Wilton" >> wrote: >> >>> >>> On 12/01/2016 09:05, Ladislav Lhotka

Re: [netmod] applied configuration and system-controlled entries

;>> >>>>> >>>>> >>>>> On 11/01/2016 14:27, Ladislav Lhotka wrote: >>>>>>> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder >>>>>>> wrote: >>>>>>> >>>>>>

Re: [netmod] applied configuration and system-controlled entries

day 12 January 2016 10:23 To: Gert Grammel mailto:ggram...@juniper.net>>, Robert Wilton mailto:rwil...@cisco.com>> Cc: "netmod@ietf.org<mailto:netmod@ietf.org>" mailto:netmod@ietf.org>> Subject: RE: [netmod] applied configuration and system-controlled entries

Re: [netmod] applied configuration and system-controlled entries

ly this is not the norm, but rather an exception. In any event, the difference between intended and applied is temporary. --Gert >-Original Message- >From: Robert Wilton [mailto:rwil...@cisco.com] >Sent: 11 January 2016 17:58 >To: Gert Grammel; Ladislav Lhotka >Cc: net

Re: [netmod] applied configuration and system-controlled entries

2016, at 15:58, Robert Wilton wrote: >> >> >> >> On 11/01/2016 14:27, Ladislav Lhotka wrote: >>>> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder > wrote: >>>> >>>> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote: >&g

Re: [netmod] applied configuration and system-controlled entries

Lada, The requirement says: D. When a configuration change for any intended configuration node has been successfully applied to the server (e.g. not failed, nor deferred due to absent hardware) then the existence and value of the corresponding applied

Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)

result is intended != applied and Client+Server have to deal with it in a meaningful manner. Gert From: Robert Wilton [mailto:rwil...@cisco.com] Sent: 06 January 2016 17:49 To: Kent Watsen; Gert Grammel Cc: netmod@ietf.org Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback

Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)

Kent, I would agree that the discussion doesn’t affect the requirements draft in its current state. The solutions draft would be a better place probably. Gert From: Kent Watsen Sent: 06 January 2016 17:43 To: Gert Grammel; Robert Wilton Cc: netmod@ietf.org Subject: Re: [netmod] netmod-opstate

Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)

Hi Rob, See below ... --Gert From: Robert Wilton [mailto:rwil...@cisco.com] Sent: 05 January 2016 16:05 To: Gert Grammel Cc: netmod@ietf.org Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error) Hi Gert, Considering a rollback-on-error request that failed: If

Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)

from my Apple ][ On 23 Dec 2015, at 22:25, Robert Wilton mailto:robert.pub...@wilton.org.uk>> wrote: Hi Gert, Please see one comment inline ... On 23/12/2015 10:24, Gert Grammel wrote: Rob, Kent, Adding to Rob's comments: From: netmod <<mailto:netmod-boun...@ietf.org>

Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)

Rob, Kent, Adding to Rob’s comments: From: netmod mailto:netmod-boun...@ietf.org>> on behalf of Robert Wilton mailto:robert.pub...@wilton.org.uk>> Date: Wednesday 23 December 2015 09:28 To: Kent Watsen mailto:kwat...@juniper.net>>, "netmod@ietf.org" mailto:netmod@iet

Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)

on-error” and “stop-on-error” in the sense that unless any error has been reported, the client still needs to wait for the ‘validated’ state before it can reliably assume the config was applied. From: Robert Wilton mailto:rwil...@cisco.com>> Date: Monday 21 December 2015 19:55 To: Gert

Re: [netmod] IPR Check: draft-ietf-netmod-opstate-reqs-01

I am not aware of any IPR - Gert as a contributor From: netmod mailto:netmod-boun...@ietf.org>> on behalf of Thomas Nadeau mailto:tnad...@lucidvision.com>> Date: Wednesday 16 December 2015 14:13 To: "netmod@ietf.org" mailto:netmod@ietf.org>> Cc: "netmod-cha...@tools.i

Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft

+1 From: netmod mailto:netmod-boun...@ietf.org>> on behalf of Kent Watsen mailto:kwat...@juniper.net>> Date: Tuesday 15 December 2015 17:48 To: "netmod@ietf.org" mailto:netmod@ietf.org>> Subject: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as N

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

n From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Gert Grammel Sent: Monday, October 19, 2015 9:15 To: Robert Wilton Cc: netmod@ietf.org<mailto:netmod@ietf.org> Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)

Jason, A synchronous config basically contains two pieces of information in the commit: 1) the intended configuration is valid (i.e. is syntactically correct) and 2) the intended config has been applied Any error that would affect the config before the commit could be rolled back

Re: [netmod] Opstate draft comments

Balazs, Let me try to respond to a few of your questions. See below ... From: netmod mailto:netmod-boun...@ietf.org>> on behalf of Balazs Lengyel mailto:balazs.leng...@ericsson.com>> Date: Thursday 22 October 2015 18:01 To: "netmod@ietf.org" mailto:netmod@ietf.org>> Su

Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D"

+1 Gert Sent from my Apple ][ > On 19 Oct 2015, at 18:10, Kent Watsen wrote: > > > All, > > This issue somewhat dropped from our radar - we didn't discuss it during > the interim or since. Nonetheless, my interpretation of the below thread > is that Robert's proposal was accepted. So I'm g

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

Rob, The current text of 3a works for me although it looks a bit complex. So we converged. Gert Sent from my Apple ][ On 19 Oct 2015, at 16:01, Robert Wilton mailto:rwil...@cisco.com>> wrote: Hi Gert, On 19/10/2015 14:37, Gert Grammel wrote: Hi Kent, Here my proposals 3. Suppo

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

Hi Kent, Here my proposals 3. Support for both synchronous and asynchronous configuration operations (see terms) A. A server may only support synchronous configuration operations, or may only support asynchronous configuration operations, or may support sync

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

^ this is when "block" would return From: Robert Wilton mailto:rwil...@cisco.com>> Date: Monday 19 October 2015 14:57 To: Gert Grammel mailto:ggram...@juniper.net>>, Martin Bjorklund mailto:m...@tail-f.com&

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

Hi Rob, From: Robert Wilton mailto:rwil...@cisco.com>> Date: Monday 19 October 2015 14:25 To: Gert Grammel mailto:ggram...@juniper.net>> Cc: Kent Watsen mailto:kwat...@juniper.net>>, Martin Bjorklund mailto:m...@tail-f.com>>, "netmod@ietf.org<mailto:netmod@ie

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

Martin, Attempting to apply a config appears to me as a process, not a state. So in my mind the little drawing should look like this then: receive updated Attempting to intended intended apply intendedapplied operational configconfig configcon

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

+1 From: netmod mailto:netmod-boun...@ietf.org>> on behalf of Robert Wilton mailto:rwil...@cisco.com>> Date: Monday 19 October 2015 12:14 To: Kent Watsen mailto:kwat...@juniper.net>>, Martin Bjorklund mailto:m...@tail-f.com>> Cc: "netmod@ietf.org" mailto:netmod@ietf.org>>

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

Rob, I think we are describing the same problem from a little different perspective: Sent from my Apple ][ > On 16 Oct 2015, at 20:50, Robert Wilton wrote: > > Hi Gert, > >> On 16/10/2015 18:14, Gert Grammel wrote: >> Rob, >> >> Current implementations

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

Rob, Current implementations are incomplete asynchronous, because they didn't verify the config as operational and applied. What is frequently done is to perform additional checks on the intended config that go beyond a syntax check. That is fine, but I have a hard time to consider this to be

Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

appens via requests like and PATCH. The intended (running) config gets updated first and then config is distributed to internal components, ultimately updated the applied config. Kent // as a contributor From: Gert Grammel mailto:ggram...@juniper.net>> Date: Friday, October 1

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

it has to clean up the mess in the server or not. In that sense, I'd define a transaction as a configuration change that can be rolled back by the server. Gert Sent from my Apple ][ On 16 Oct 2015, at 15:59, Robert Wilton mailto:rwil...@cisco.com>> wrote: Hi Gert, On 16/10/2015

Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

Kent, The new one looks much better. However the last sentence is confusing with respect to intended config. Why is there a need to update the intended config? Proposal: The server MUST fully attempt to apply the configuration change to all impacted components in the server, updating the

Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

Juergen, Rob summarized the discussion well. Since I also have some strange feelings about transactions here, my proposal in the other thread was to define the state of the config at the time the client is notified. Gert Sent from my Apple ][ > On 16 Oct 2015, at 14:19, Robert Wilton wrote:

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

Hi Rob, The text looks good. With respect to D we probably need more wordsmithing: D. Support for best effort and rollback-on-error error handling semantics. The configuration protocol, or default server behavior, MUST specify whether the configuration is applied i

Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

k at it? BTW, do we still need to define the last two terms anymore? - they're not used elsewhere in the draft... Kent From: Gert Grammel mailto:ggram...@juniper.net>> Date: Thursday, October 15, 2015 at 10:35 AM To: Robert Wilton mailto:rwil...@cisco.com>>, Kent Watsen mail

Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

ver stays in funny-state forever. Gert From: Robert Wilton mailto:rwil...@cisco.com>> Date: Thursday 15 October 2015 15:59 To: Gert Grammel mailto:ggram...@juniper.net>>, Kent Watsen mailto:kwat...@juniper.net>>, "netmod@ietf.org<mailto:netmod@ietf.org>"

Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

Kent, Rob, Comparing the cases, the definition of the asynchronous case doesn’t look complete. The way it stands for the synchronous operation, the client knows that it's intended config was good AND it has been effected to the server. In the Asynchronous case, the client only knows that the in