Subject: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

From: Nadeau Thomas <[email-masked]>
Date: Wed, 16 Dec 2015 19:10:03 -0500

This is a WG Last Call on draft-ietf-netmod-opstate-reqs-01.
Please post comments on this draft by Wednesday, December 30, 2015
at 9AM EST.

	Tom/Kent

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Dec 2015 16:21:16 -0800

Hi,

I have asked repeatedly for some indication of scope in these requirements.
There is an assumption all possible YANG-based platforms have intended
and applied state that can be different for a long enough interval such
that retrieving
the differences is operationally useful.

For devices that converge in milli-seconds or even as long as 5 seconds,
I do not see the point of implementing solutions for these requirements.
I would prefer that this draft specify some sort of objective
metric for determining the solution applicability.

Andy

On Wed, Dec 16, 2015 at 4:10 PM, Nadeau Thomas <[email-masked]>
wrote:

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 17 Dec 2015 02:18:42 +0000

[as a contributor]

Hi Andy,

I’m struggling a bit to understand what is motivating you to ask this question.    That is, as a tool vendor, I wouldn’t think that any decision made here would affect you immediately.   My expectations are that any impact to YANG/NETCONF/RESTCONF would be backwards compatible, such that implementations would only opt-in when needed - a pay as you grow strategy.   But herein perhaps lies an unstated requirement, that the impact to YANG/NETCONF/RESTCONF needs to be backwards compatible with respect to existing deployments.  Did we miss it or is it too obvious?

I agree that supporting these requirements will be unnecessary for many platforms.  After all, we’ve gone decades without needing such visibility, and that’s not going to change for many platforms for some time, if ever.

You ask for objective metrics for determining solution applicability.  My thinking is to just let the market decide - is it not good enough?   If I tried to quantify it, I might say that its only useful for networking devices (as their operational state somehow matters more?) and that it’s only useful when there is no guarantee that the intended config will become operational (i.e. applied) in some bounded amount of time.   Just throwing out ideas here, but I like best letting the market decide.

Kent

From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, December 16, 2015 at 7:21 PM
To: Thomas Nadeau <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

Hi,

I have asked repeatedly for some indication of scope in these requirements.
There is an assumption all possible YANG-based platforms have intended
and applied state that can be different for a long enough interval such that retrieving
the differences is operationally useful.

Andy

On Wed, Dec 16, 2015 at 4:10 PM, Nadeau Thomas <[email-masked]<mailto:[email-masked]>> wrote:

        Tom/Kent

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Dec 2015 19:12:56 -0800

On Wed, Dec 16, 2015 at 6:18 PM, Kent Watsen <[email-masked]> wrote:

>
> [as a contributor]
>
> Hi Andy,
>
> I’m struggling a bit to understand what is motivating you to ask this
> question.    That is, as a tool vendor, I wouldn’t think that any decision
> made here would affect you immediately.   My expectations are that any
> impact to YANG/NETCONF/RESTCONF would be backwards compatible, such that
> implementations would only opt-in when needed - a pay as you grow strategy.
>   But herein perhaps lies an unstated requirement, that the impact to
> YANG/NETCONF/RESTCONF needs to be backwards compatible with respect to
> existing deployments.  Did we miss it or is it too obvious?
>
> I agree that supporting these requirements will be unnecessary for many
> platforms.  After all, we’ve gone decades without needing such visibility,
> and that’s not going to change for many platforms for some time, if ever.
>
> You ask for objective metrics for determining solution applicability.  My
> thinking is to just let the market decide - is it not good enough?   If I
> tried to quantify it, I might say that its only useful for networking
> devices (as their operational state somehow matters more?) and that it’s
> only useful when there is no guarantee that the intended config will become
> operational (i.e. applied) in some bounded amount of time.   Just throwing
> out ideas here, but I like best letting the market decide.
>
>

There seemed to be agreement that most devices will apply intended config
within 5 seconds (not counting the 'waiting for line card' corner-case).
We usually see exec. times way under 1 sec., but if others are having
a problem with delays, I guess they will find this work useful.

Andy

>
>
> From: netmod <[email-masked]> on behalf of Andy Bierman <
> [email-masked]>
> To: Thomas Nadeau <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Dec 2015 08:17:28 +0100

> I’m struggling a bit to understand what is motivating you to ask this question.    That is, as a tool vendor, I wouldn’t think that any decision made here would affect you immediately.   My expecta…

It may be obvious for many of us but for the sake of completeness I
prefer to have this backwards compatibility assumption explicitely
stated.

/js

-- 
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/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 17 Dec 2015 08:42:10 +0100

> On 17 Dec 2015, at 08:17, Juergen Schoenwaelder <[email-masked]> wrote:
> 

+1

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Nadeau Thomas <[email-masked]>
Date: Thu, 17 Dec 2015 07:07:29 -0500

As you know, after much discussion, the Co-chairs declared these requirements to be in scope and 
having consensus to proceed forward at one of the recent interim meetings, and on the mailing list to confirm.

	—Tom

> On Dec 16, 2015:7:21 PM, at 7:21 PM, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
> On Wed, Dec 16, 2015 at 4:10 PM, Nadeau Thomas <[email-masked] <mailto:[email-masked]>> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 17 Dec 2015 14:36:08 +0000

>> prefer to have this backwards compatibility assumption explicitely

[as a chair]

As last call comment, there seems to be support for adding a requirement to the opstate-reqs draft to state that solutions supporting said requirements MUST be backwards compatible with respect to existing deployments.  Do we have WG consensus to add this as a requirement to this draft?  Are there any objections? Please voice your opinion before the last call cutoff date (Dec 30).

[as a contributor]

I’m unsure if it makes sense to call it out in this draft, in that it seems universally applicable, but I don’t see any harm in it either and thus do not object.

Kent

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Dec 2015 07:45:38 -0800

> and on the mailing list to confirm.
I did not say any of the requirements are not in scope.
Apparently what is not in scope is any concept of an Applicability Statement
for this problem and its solution(s).

Andy

---

From: Nadeau Thomas <[email-masked]>
Date: Thu, 17 Dec 2015 10:52:13 -0500

> On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen <[email-masked]> wrote:
> 
> 
> 
> 
> 
> 

	[As Co-chair]

	Given the tall hill we climbed to get to this point on the requirements, I
want to be clear that there needs to be very significant support to change the requirements
in any significant way. We went round and round the drain on settling on these requirements, and 
people had a whole host of reasonable opportunities to add this during those times. I want to point out that while this statement may seem subtle, slipping this in at the last minute could have a profound impact on solutions built from these requirements, so I want to be sure everyone involved has through through this kind of change.

	—Tom

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Dec 2015 08:06:10 -0800

Hi,

I agree with Juergen that this should be clear.
It was discussed several times.  All existing protocol
functionality for NETCONF and RESTCONF MUST continue to work
for clients which do not choose to examine the differences between
intended config and applied config.

Andy

On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen <[email-masked]> wrote:

> implementations would only opt-in when needed - a pay as you grow
> strategy.   But herein perhaps lies an unstated requirement, that the
> impact to YANG/NETCONF/RESTCONF needs to be backwards compatible with
> respect to existing deployments.  Did we miss it or is it too obvious?
> >>>
> >>
> As last call comment, there seems to be support for adding a requirement
> to the opstate-reqs draft to state that solutions supporting said
> requirements MUST be backwards compatible with respect to existing
> deployments.  Do we have WG consensus to add this as a requirement to this
> draft?  Are there any objections? Please voice your opinion before the last
> call cutoff date (Dec 30).
>
>
> [as a contributor]
>
>
> I’m unsure if it makes sense to call it out in this draft, in that it
> seems universally applicable, but I don’t see any harm in it either and
> thus do not object.
>
>
> Kent
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 17 Dec 2015 17:09:55 +0100 (CET)

Nadeau Thomas <[email-masked]> wrote:
> >>>> question.  That is, as a tool vendor, I wouldn’t think that any
> >>>> decision made here would affect you immediately.  My expectations are
> >>>> that any impact to YANG/NETCONF/RESTCONF would be backwards
> >>>> compatible, such that implementations would only opt-in when needed -
> >>>> a pay as you grow strategy.  But herein perhaps lies an unstated
> >>>> requirement, that the impact to YANG/NETCONF/RESTCONF needs to be
> >>>> backwards compatible with respect to existing deployments.  Did we
> >>>> miss it or is it too obvious?
> >>>> 
> >>> 
> > As last call comment, there seems to be support for adding a
> > requirement to the opstate-reqs draft to state that solutions
> > supporting said requirements MUST be backwards compatible with respect
> > to existing deployments.  Do we have WG consensus to add this as a
> > requirement to this draft?  Are there any objections? Please voice
> > your opinion before the last call cutoff date (Dec 30).
> > 
> > 
> > [as a contributor]
> > 
> > 
> > seems universally applicable, but I don’t see any harm in it either
> > and thus do not object.
> > 
> > 
> > Kent
> 
> 	[As Co-chair]
> 
> people had a whole host of reasonable opportunities to add this during
> those times. I want to point out that while this statement may seem
> subtle, slipping this in at the last minute could have a profound
> impact on solutions built from these requirements, so I want to be
> sure everyone involved has through through this kind of change.

I think this has been taken for granted.  As such, it is not really a
completely new, last minute, requirement, and I think it makes sense
to explicitly state it.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Dec 2015 18:29:31 +0100

> people had a whole host of reasonable opportunities to add this during those times. I want to point out that while this statement may seem subtle, slipping this in at the last minute could have a p…

Tom,

I think Andy is talking about applicability - to which kind of servers
do these requirements apply. For example, if it takes more time on a
certain class of devices to retrieve the difference between applied
and intended config than it takes to turn intended config into applied
config, then these requirements may not be applicable (since by the
time you have finished retrieving the difference it has vanished).

Andy, did I get this right?

/js

---

From: Robert Wilton <[email-masked]>
Date: Thu, 17 Dec 2015 17:29:43 +0000

Hi Andy,

Please can you let me know whether you think that any of the three 
proposed solutions wouldn't meet this backwards compatibility requirement?

draft-kwatsen-netmod-opstate-00 has some features that might be 
generally useful to NETCONF, like adding <get-state> support as defined 
in section 5.1, that I would expect could just be added to a future 
version of NETCONF.  Would a requirement that the solution is backwards 
compatible with existing implementations require that support for 
<get-state> must always be optional? Or could a new version of the 
NETCONF protocol require that support for <get-state> is required?

Thanks,
Rob

On 17/12/2015 16:06, Andy Bierman wrote:
> On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>
>
>
>     >>>I’m struggling a bit to understand what is motivating you to
>     ask this question.    That is, as a tool vendor, I wouldn’t think
>     that any decision made here would affect you immediately.   My
>     expectations are that any impact to YANG/NETCONF/RESTCONF would be
>     backwards compatible, such that implementations would only opt-in
>     when needed - a pay as you grow strategy.  But herein perhaps lies
>     an unstated requirement, that the impact to YANG/NETCONF/RESTCONF
>     needs to be backwards compatible with respect to existing
>     deployments.  Did we miss it or is it too obvious?
>     >>>
>     >>
>     supporting said requirements MUST be backwards compatible with
>     respect to existing deployments.  Do we have WG consensus to add
>     this as a requirement to this draft?  Are there any objections?
>     Please voice your opinion before the last call cutoff date (Dec 30).
>
>
>     [as a contributor]
>
>
>     I’m unsure if it makes sense to call it out in this draft, in that
>     it seems universally applicable, but I don’t see any harm in it
>     either and thus do not object.
>
>
>     Kent
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Dec 2015 09:33:34 -0800

Hi,

I am not commenting on the solution proposals.
The document being discussed is the requirements document.
I agree with Juergen that backward compatibility needs to be an
explicit requirement.  Are you objecting to such a requirement?

Andy

On Thu, Dec 17, 2015 at 9:29 AM, Robert Wilton <[email-masked]> wrote:

> draft-kwatsen-netmod-opstate-00 has some features that might be generally
> useful to NETCONF, like adding <get-state> support as defined in section
> 5.1, that I would expect could just be added to a future version of
> NETCONF.  Would a requirement that the solution is backwards compatible
> with existing implementations require that support for <get-state> must
> always be optional?  Or could a new version of the NETCONF protocol require
> that support for <get-state> is required?
>
> Thanks,
> Rob
>
>
> netmod mailing [email-masked]://www.ietf.org/mailman/listinfo/netmod
>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Dec 2015 09:41:48 -0800

On Thu, Dec 17, 2015 at 9:29 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > >>>> I’m struggling a bit to understand what is motivating you to ask
> this question.    That is, as a tool vendor, I wouldn’t think that any
> decision made here would affect you immediately.   My expectations are that
> any impact to YANG/NETCONF/RESTCONF would be backwards compatible, such
> that implementations would only opt-in when needed - a pay as you grow
> requirement to the opstate-reqs draft to state that solutions supporting
> said requirements MUST be backwards compatible with respect to existing
> those times. I want to point out that while this statement may seem subtle,
> slipping this in at the last minute could have a profound impact on
> solutions built from these requirements, so I want to be sure everyone
> involved has through through this kind of change.
> >
> >       —Tom
>
> Tom,
>

pretty much.

I can see how the time delay is subjective and depends on the use-case
and the operator preferences.  In 1 deployment a delay of 5 seconds
is not a concern, and in another it is a concern.

The solution does not have to polling.
The server can send 1 indication when intended == applied for the entire
datastore,
or it can answer a million individual "are you done yet?" queries from the
client.
Both could be considered solutions to the same problem.

Andy

---

From: Robert Wilton <[email-masked]>
Date: Thu, 17 Dec 2015 18:18:10 +0000

Hi Andy,

Please can you state the specific text that is being proposed to be 
added as a new requirement?

Thanks,
Rob

On 17/12/2015 17:33, Andy Bierman wrote:
> On Thu, Dec 17, 2015 at 9:29 AM, Robert Wilton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Andy,
>
>     generally useful to NETCONF, like adding <get-state> support as
>     defined in section 5.1, that I would expect could just be added to
>     a future version of NETCONF.  Would a requirement that the
>     solution is backwards compatible with existing implementations
>     require that support for <get-state> must always be optional?  Or
>     could a new version of the NETCONF protocol require that support
>     for <get-state> is required?
>
>     Thanks,
>     Rob
>
>
>>         >>>I’m struggling a bit to understand what is motivating you
>>         to ask this question.   That is, as a tool vendor, I wouldn’t
>>         think that any decision made here would affect you
>>         immediately.   My expectations are that any impact to
>>         YANG/NETCONF/RESTCONF would be backwards compatible, such
>>         that implementations would only opt-in when needed - a pay as
>>         you grow strategy.   But herein perhaps lies an unstated
>>         requirement, that the impact to YANG/NETCONF/RESTCONF needs
>>         to be backwards compatible with respect to existing
>>         supporting said requirements MUST be backwards compatible
>>         with respect to existing deployments.  Do we have WG
>>         consensus to add this as a requirement to this draft?  Are
>>         there any objections? Please voice your opinion before the
>>         last call cutoff date (Dec 30).
>>
>>
>>         [as a contributor]
>>
>>
>>         I’m unsure if it makes sense to call it out in this draft, in
>>         that it seems universally applicable, but I don’t see any
>>         harm in it either and thus do not object.
>>
>>
>>         Kent
>>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Dec 2015 10:26:55 -0800

Hi,

I already did that:

 All existing protocol
> intended config and applied config.
Another way to put it:

  The client MUST choose to participate (opt-in).

An example of a solution that meets this requirement

  - The client adds a <wait-until-applied /> flag to an edit-config request
which causes the server to wait until the edit is applied before returning
<rpc-reply>.
This requires the server to opt-in for the wait, and it is not forced on
the client.

Andy

On Thu, Dec 17, 2015 at 10:18 AM, Robert Wilton <[email-masked]> wrote:

> Hi Andy,
>
> Please can you state the specific text that is being proposed to be added
> as a new requirement?
>
> Thanks,
> Rob
>
>
>> On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen < <[email-masked]>
>> [email-masked]> wrote:
>>
>>>
>>>
>>>
>>>
>>>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 17 Dec 2015 21:12:58 +0000

Hi Andy,

Thanks for resending and apologies for missing it earlier.

Your requirement is a bit too strong for my liking.

To paraphrase your requirement text, it is forcing that all compliant 
NETCONF/RESTCONF servers MUST support any clients that do not want to 
differentiate between intended config and applied config.

However, this requires all opstate aware servers:
  - To handle a mix of clients, some of which are opstate aware, and 
some that are not.
  - To potentially handle a mix of requests, some of which are opstate 
aware requests, and some are not.

It also prevents:
  - Having a server that is implemented to only support opstate aware 
clients.
  - Having a server side configuration knob to control the behaviour 
(since it would affect the semantics for all clients).

Personally, I think that the best solutions will likely meet your 
proposed requirement below, but I don't agree that it should be 
mandated, even though I agree that it is something that the solution 
should aim for.

Changing the MUST to SHOULD would make the requirement fine with me ...

Finally, regarding your example below, I didn't think that the existing 
NETCONF protocol semantics specify exactly when the server is required 
to respond to the client, and hence blocking the client until the 
configuration has been applied would be a valid edit-config 
implementation under the existing NETCONF specification.

Thanks,
Rob

On 17/12/2015 18:26, Andy Bierman wrote:
> which causes the server to wait until the edit is applied before 
> returning <rpc-reply>.
> This requires the server to opt-in for the wait, and it is not forced 
> on the client.
>
>
> Andy
>
>
> On Thu, Dec 17, 2015 at 10:18 AM, Robert Wilton <[email-masked] 
>     Please can you state the specific text that is being proposed to
>     be added as a new requirement?
>
>     Thanks,
>     Rob
>
>
>>         Please can you let me know whether you think that any of the
>>         three proposed solutions wouldn't meet this backwards
>>         compatibility requirement?
>>
>>         draft-kwatsen-netmod-opstate-00 has some features that might
>>         be generally useful to NETCONF, like adding <get-state>
>>         support as defined in section 5.1, that I would expect could
>>         just be added to a future version of NETCONF.  Would a
>>         requirement that the solution is backwards compatible with
>>         existing implementations require that support for <get-state>
>>         must always be optional?  Or could a new version of the
>>>         On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>             >>>I’m struggling a bit to understand what is motivating
>>>             you to ask this question.    That is, as a tool vendor,
>>>             I wouldn’t think that any decision made here would
>>>             affect you immediately.   My expectations are that any
>>>             impact to YANG/NETCONF/RESTCONF would be backwards
>>>             compatible, such that implementations would only opt-in
>>>             when needed - a pay as you grow strategy.   But herein
>>>             perhaps lies an unstated requirement, that the impact to
>>>             YANG/NETCONF/RESTCONF needs to be backwards compatible
>>>             with respect to existing deployments.  Did we miss it or
>>>             is it too obvious?
>>>             >>>
>>>             >>
>>>             As last call comment, there seems to be support for
>>>             adding a requirement to the opstate-reqs draft to state
>>>             that solutions supporting said requirements MUST be
>>>             backwards compatible with respect to existing
>>>             deployments.  Do we have WG consensus to add this as a
>>>             requirement to this draft?  Are there any objections?
>>>             I’m unsure if it makes sense to call it out in this
>>>             draft, in that it seems universally applicable, but I
>>>             don’t see any harm in it either and thus do not object.
>>>
>>>
>>>             Kent
>>>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Dec 2015 13:52:23 -0800

Hi,

I think the current operations need to continue to work.
With the current <edit-config> or <commit> the client does
not know if the server applied the config or just accepted the request.

With the new solution, I expect that a client that does not explicitly ask
for "wait until applied" will get the old (unspecified) behavior.

Andy

On Thu, Dec 17, 2015 at 1:12 PM, Robert Wilton <[email-masked]> wrote:

>  - To handle a mix of clients, some of which are opstate aware, and some
> that are not.
>  - Having a server side configuration knob to control the behaviour (since
> it would affect the semantics for all clients).
>
>
> Personally, I think that the best solutions will likely meet your proposed
> requirement below, but I don't agree that it should be mandated, even
> though I agree that it is something that the solution should aim for.
>
> NETCONF protocol semantics specify exactly when the server is required to
> respond to the client, and hence blocking the client until the
> configuration has been applied would be a valid edit-config implementation
> under the existing NETCONF specification.
>
> Thanks,
> Rob
>
>
>> On Thu, Dec 17, 2015 at 9:29 AM, Robert Wilton < <[email-masked]>
>> [email-masked]> wrote:
>>
>>> Hi Andy,
>>>
>>> generally useful to NETCONF, like adding <get-state> support as defined in
>>> section 5.1, that I would expect could just be added to a future version of

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Dec 2015 14:14:41 -0800

>> aware requests, and some are not.

This is simple to achieve by adding optional parameters that a new client
will set
and an old client will not know about.

>> (since it would affect the semantics for all clients).

Not true, since the current RFC behavior is undefined.
A server vendor can choose right now to only return <rpc-reply> after
all intended is applied.

The new feature will be that a client can explicitly request this behavior
and a compliant server will support it.  If the client does not request it,
then
there is a chance that operations will time out that did not use to time
out.
This will be very visible and disruptive to operators, and perceived as a
bug.

>> proposed requirement below, but I don't agree that it should be mandated,
>> even though I agree that it is something that the solution should aim for.
>>

Yes it would be valid, but it might generate unhappy customers with broken
client applications just the same.

Andy

---

From: Robert Wilton <[email-masked]>
Date: Thu, 17 Dec 2015 23:15:02 +0000

Hi Andy,

On 17/12/2015 22:14, Andy Bierman wrote:
>
>
> On Thu, Dec 17, 2015 at 1:52 PM, Andy Bierman <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     On Thu, Dec 17, 2015 at 1:12 PM, Robert Wilton <[email-masked]
>         To paraphrase your requirement text, it is forcing that all
>         compliant NETCONF/RESTCONF servers MUST support any clients
>         that do not want to differentiate between intended config and
>         applied config.
>
>          - To handle a mix of clients, some of which are opstate
>         aware, and some that are not.
>          - To potentially handle a mix of requests, some of which are
>         opstate aware requests, and some are not.
>
>
>
> This is simple to achieve by adding optional parameters that a new 
> client will set

My point is really that it may be harder for servers to support clients 
using a mix of semantics.

It still feels to me that at this stage of just considering/comparing 
solutions we shouldn't rule out a server potentially being able to 
declare that it only supports/implements opstate-aware semantics, which 
I think that your requirement would. For some devices, if all customers 
are only asking for opstate-aware semantics, then do we really also have 
to support the non opstate-aware semantics as well?

>
>         It also prevents:
>          - Having a server that is implemented to only support opstate
>         aware clients.
>          - Having a server side configuration knob to control the
>         behaviour (since it would affect the semantics for all clients).
>
>
>
> and a compliant server will support it.  If the client does not 
> request it, then
> there is a chance that operations will time out that did not use to 
> time out.
> This will be very visible and disruptive to operators, and perceived 
> as a bug.

Technically the bug would be in the client rather than the server here, 
but I don't deny that the client operator would necessarily perceive it 
the same way.  But shouldn't this be up to the implementer to weight up 
the benefits of a potentially simpler server solution vs the impacts to 
existing clients?

>
>
>
>
>         Personally, I think that the best solutions will likely meet
>         your proposed requirement below, but I don't agree that it
>         should be mandated, even though I agree that it is something
>         that the solution should aim for.
>
>         Finally, regarding your example below, I didn't think that the
>         existing NETCONF protocol semantics specify exactly when the
>         server is required to respond to the client, and hence
>         blocking the client until the configuration has been applied
>         would be a valid edit-config implementation under the existing
>         NETCONF specification.
>
>
>
It still doesn't feel like a good requirement that states that an 
opstate-aware server must preserve support for some existing, but 
unspecified, behaviour.  If the new more tightly defined behaviour is 
compliant with the existing unspecified behaviour then it feels like 
that should be a valid implementation choice to treat both of them the 
same way.

Thanks,
Rob

>>         which causes the server to wait until the edit is applied
>>         before returning <rpc-reply>.
>>         This requires the server to opt-in for the wait, and it is
>>         not forced on the client.
>>
>>
>>         Andy
>>
>>
>>         On Thu, Dec 17, 2015 at 10:18 AM, Robert Wilton
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>             Hi Andy,
>>
>>             Please can you state the specific text that is being
>>             proposed to be added as a new requirement?
>>
>>             Thanks,
>>             Rob
>>
>>
>>>             On Thu, Dec 17, 2015 at 9:29 AM, Robert Wilton
>>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>                 Hi Andy,
>>>
>>>                 Please can you let me know whether you think that
>>>                 any of the three proposed solutions wouldn't meet
>>>                 this backwards compatibility requirement?
>>>
>>>                 draft-kwatsen-netmod-opstate-00 has some features
>>>                 that might be generally useful to NETCONF, like
>>>                 adding <get-state> support as defined in section
>>>                 5.1, that I would expect could just be added to a
>>>                 future version of NETCONF.  Would a requirement that
>>>                 the solution is backwards compatible with existing
>>>                 implementations require that support for <get-state>
>>>                 must always be optional?  Or could a new version of
>>>                 the NETCONF protocol require that support for
>>>                 <get-state> is required?
>>>
>>>                 Thanks,
>>>                 Rob
>>>
>>>
>>>>                     >>>I’m struggling a bit to understand what is
>>>>                     motivating you to ask this question.    That
>>>>                     is, as a tool vendor, I wouldn’t think that any
>>>>                     decision made here would affect you
>>>>                     immediately.   My expectations are that any
>>>>                     impact to YANG/NETCONF/RESTCONF would be
>>>>                     backwards compatible, such that implementations
>>>>                     would only opt-in when needed - a pay as you
>>>>                     grow strategy.   But herein perhaps lies an
>>>>                     unstated requirement, that the impact to
>>>>                     YANG/NETCONF/RESTCONF needs to be backwards
>>>>                     compatible with respect to existing
>>>>                     As last call comment, there seems to be support
>>>>                     for adding a requirement to the opstate-reqs
>>>>                     draft to state that solutions supporting said
>>>>                     requirements MUST be backwards compatible with
>>>>                     respect to existing deployments.  Do we have WG
>>>>                     consensus to add this as a requirement to this
>>>>                     draft?  Are there any objections? Please voice
>>>>                     I’m unsure if it makes sense to call it out in
>>>>                     this draft, in that it seems universally
>>>>                     applicable, but I don’t see any harm in it

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Dec 2015 14:55:37 +0100

> time you have finished retrieving the difference it has vanished).

I think it is not only matter of synchronisation delays between intended
and applied configuration. I have serious troubles understanding how
these concepts map to the class of devices I am mainly interested in.

Let me give you an example: An OpenWRT router runs a NETCONF/RESTCONF
server that supports intended and applied config. Assume the server
implements modules of the acl-model family so that firewall rules can be
configured through NETCONF/RESTCONF. Great.

Now an admin runs "iptables" to manipulate netfilter rules in the
kernel. How does it affect the applied and intended configurations?

A. The change isn't reflected in applied configuration. Then applied
   configuration is no more "…, the configuration state which is
   currently being used by server components (e.g., control plane
   daemons, operating system kernels, line cards)."

B. The change is reflected in applied but not in intended
   configuration. This violates requirement 1 sub D, and also it may be
   impossible to map the kernel changes back to the configuration.

For sure, these problems exist also with the good old "running", but I
think the migration to intended-applied would just make things worse.

Lada

---

From: Nadeau Thomas <[email-masked]>
Date: Mon, 21 Dec 2015 09:20:43 -0500

> On Dec 21, 2015:8:55 AM, at 8:55 AM, Ladislav Lhotka <[email-masked]> wrote:
> 

	My note above was not concerned with technical details, but rather
procedural. As I noted, we spend numerous hours getting that document
and the agreements around that to the point where it is at by meeting with
a lot of people. Those changes are then the result (and consensus) of those
many meetings and peoples’ inputs. It is one thing to be making minor/editorial
changes, but an entirely other to be making substantive technical changes
at the last minute without everyones' buy-in.

	—Tom

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Dec 2015 15:38:03 +0100

> On 21 Dec 2015, at 15:20, Nadeau Thomas <[email-masked]> wrote:
> 
>> 

I did ask these questions previously but only got hand-waving or procedural answers (like yours). Therefore, I want to make sure that this intended-applied thing isn't the only way that will be supported from now on. That's all.

Thanks, Lada

---

From: Robert Wilton <[email-masked]>
Date: Mon, 21 Dec 2015 15:05:28 +0000

Hi Lada,

> think the migration to intended-applied would just make things worse.
If I understand your example correctly, then the complexity in your 
scenario is that what is actually written in the hardware is controlled 
by two independent management entities.  Is that right?

If so I think that your scenario is outside what could be reasonably 
expected to be defined by a standards specification.

Ideally, all of the related configuration would be managed by the same 
YANG data model, in which case I would expect that your problem would 
disappear.

Pragmatically, I suspect that you can't do that, in which case I would 
model the opstate requirements as only applying to the YANG part of the 
configuration.  I.e. the ACL model is in applied configuration applied 
if it is regarded as being a valid input to what is being programmed 
into the system.  What is actually programmed in the forwarding filter 
depends on both the accepted ACL YANG configuration and also the other 
independent configuration.

Thanks,
Rob

---

From: Christian Hopps <[email-masked]>
Date: Mon, 21 Dec 2015 10:07:04 -0500

> think the migration to intended-applied would just make things worse.

Perhaps I'm misunderstanding the example, but it seems you have a setup
where your netconf/restconf server isn't in sync with actual
configuration of the device, regardless of whether is implements these
requirements or not.

Why isn't this a non-starter? I mean it seems to me that you don't need
to worry about new operational state requirements until the most basic
functionality is working.

Thanks,
Chris.

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Dec 2015 17:05:43 +0100

> On 21 Dec 2015, at 16:05, Robert Wilton <[email-masked]> wrote:
> 
> Hi Lada,
> 
> If I understand your example correctly, then the complexity in your scenario is that what is actually written in the hardware is controlled by two independent management entities.  Is that right?

Right, and this is quite typical for systems where users have access to a standard Unix shell and/or can install software on their own.

> 
> If so I think that your scenario is outside what could be reasonably expected to be defined by a standards specification.

Why? Such systems could also benefit from NETCONF/RESTCONF and standard data models.

> 
> Ideally, all of the related configuration would be managed by the same YANG data model, in which case I would expect that your problem would disappear.

It can be managed by the same YANG models as other devices, one can just never think that what's in the configuration is also what the system uses. The only (reasonably) reliable source for the latter is the /proc filesystem, which actually comes close to the definition of applied configuration - only its data model is generally very different.   

> 
> Pragmatically, I suspect that you can't do that, in which case I would model the opstate requirements as only applying to the YANG 

Yes, it is not realistic.

> part of the configuration.  I.e. the ACL model is in applied configuration applied if it is regarded as being a valid input to what is being programmed into the system.  What is actually programmed in the forwarding filter depends on both the accepted ACL YANG configuration and also the other independent configuration.

Sure, but then applied configuration is of no use.

Lada

---

From: Robert Wilton <[email-masked]>
Date: Mon, 21 Dec 2015 16:42:37 +0000

Hi Lada,

> Why? Such systems could also benefit from NETCONF/RESTCONF and standard data models.
Sure.   But I don't see how you can standardize against a configuration 
system that probably isn't strongly specified itself.

> It can be managed by the same YANG models as other devices, one can just never think that what's in the configuration is also what the system uses. The only (reasonably) reliable source for the lat…
Personally, I would think that a device knowing what configuration it is 
actually running should be the desired and default expectation, and not 
being able to provide this is a deficiency.

Somehow the operator needs to be able to figure out whether a device is 
doing what it is supposed to be doing.  I don't think that it is really 
reasonable to just force this problem on to the operators and tell them 
that they need to figure it out themselves.  This would mean that each 
and every operator that needs to interact with that device either has to 
accept that either they don't know what it is actually doing, or they 
have to independently implement a similar solution to figure it out.

> Sure, but then applied configuration is of no use.
That's not entirely true.

The operator still knows that the system is actually acting on the 
configuration that the user intended, it just doesn't mean that it has 
necessarily been programmed into the forwarding plane.  That is subject 
to the other independent configuration allowing the ACL YANG 
configuration is in effect.

E.g. in the following ASCII Art diagram, then if A was the YANG config, 
then they would know that has been successfully applied, even though 
they don't know about your other configuration 'B', or what ends up in 
the forwarding plane (derived state) :

A ==\
      ===> Forwarding plane
B ==/

Without the applied configuration state, the operator knows less 
information.  I.e. if the forwarding plane hasn't been programmed 
correctly then that might be either because the ACL YANG configuration 
(A) hasn't been applied or because the independent configuration (B) 
interferes with it.

Thanks,
Rob

> .

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Dec 2015 21:17:30 +0100

> On 21 Dec 2015, at 17:42, Robert Wilton <[email-masked]> wrote:
> 
> Hi Lada,
> 
> Sure.   But I don't see how you can standardize against a configuration system that probably isn't strongly specified itself.
> 

Well, only if "strongly specified" means that the ways how the user is allowed to interact with the system are strictly controlled. Open-source system are usually fond of keeping the user empowered. We have to live with it.

> Personally, I would think that a device knowing what configuration it is actually running should be the desired and default expectation, and not being able to provide this is a deficiency.
> 
> Somehow the operator needs to be able to figure out whether a device is doing what it is supposed to be doing.  I don't think that it

The operator (using a NETCONF/RESTCONF client) should be able to figure out what the device is doing by inspecting state data. That's why we have the separate *-state trees that often duplicate configuration data. 

>  is really reasonable to just force this problem on to the operators and tell them that they need to figure it out themselves.  This would mean that each and every operator that needs to interact with that device either has to accept that either they don't know what it is actually doing, or they have to independently implement a similar solution to figure it out.
> 
>> 
> The operator still knows that the system is actually acting on the configuration that the user intended, it just doesn't mean that it has necessarily been programmed into the forwarding plane. That is subject to the other independent configuration allowing the ACL YANG configuration is in effect.
> 
> E.g. in the following ASCII Art diagram, then if A was the YANG config, then they would know that has been successfully applied, even though they don't know about your other configuration 'B', or what ends up in the forwarding plane (derived state) :
> 
> A ==\
>     ===> Forwarding plane
> B ==/
> 
> 
> Without the applied configuration state, the operator knows less information.  I.e. if the forwarding plane hasn't been programmed correctly then that might be either because the ACL YANG configuration (A) hasn't been applied or because the independent configuration (B) interferes with it.

I think the substantial information is what parameters the system is currently using. If there is no guarantee that applied configuration has this information, then it is IMO much less interesting.

I understand that for some systems the intended-applied configuration may be the right thing to do, so it could perhaps be defined as an optional capability. I just don't agree that this concept is universally applicable to all systems.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Dec 2015 13:34:40 -0800

On Mon, Dec 21, 2015 at 12:17 PM, Ladislav Lhotka <[email-masked]> wrote:

> ask this question.    That is, as a tool vendor, I wouldn’t think that any
> it seems universally applicable, but I don’t see any harm in it either and
> thus do not object.
> >>>>>>>
> >>>>>>>
> >>>>>>> Kent
> >>>>>>  [As Co-chair]
> >>>>>>
> >>>>>> people had a whole host of reasonable opportunities to add this
> during those times. I want to point out that while this statement may seem
> subtle, slipping this in at the last minute could have a profound impact on
> scenario is that what is actually written in the hardware is controlled by
> two independent management entities.  Is that right?
> >> Right, and this is quite typical for systems where users have access to
> a standard Unix shell and/or can install software on their own.
> >>
> Well, only if "strongly specified" means that the ways how the user is
> allowed to interact with the system are strictly controlled. Open-source
> system are usually fond of keeping the user empowered. We have to live with
> it.
>
> >
> >>
> >> It can be managed by the same YANG models as other devices, one can
> just never think that what's in the configuration is also what the system
> uses. The only (reasonably) reliable source for the latter is the /proc
> filesystem, which actually comes close to the definition of applied
> configuration - only its data model is generally very different.
> doing what it is supposed to be doing.  I don't think that it
>
> The operator (using a NETCONF/RESTCONF client) should be able to figure
> out what the device is doing by inspecting state data. That's why we have
> the separate *-state trees that often duplicate configuration data.
>
> >  is really reasonable to just force this problem on to the operators and
> tell them that they need to figure it out themselves.  This would mean that
> each and every operator that needs to interact with that device either has
> to accept that either they don't know what it is actually doing, or they
> model the opstate requirements as only applying to the YANG
> >>> part of the configuration.  I.e. the ACL model is in applied
> configuration applied if it is regarded as being a valid input to what is
> being programmed into the system.  What is actually programmed in the
> forwarding filter depends on both the accepted ACL YANG configuration and
> also the other independent configuration.
> necessarily been programmed into the forwarding plane. That is subject to
> the other independent configuration allowing the ACL YANG configuration is
> in effect.
> >
> then they would know that has been successfully applied, even though they
> don't know about your other configuration 'B', or what ends up in the
> forwarding plane (derived state) :
> >
> > A ==\
> >     ===> Forwarding plane
> > B ==/
> >
> >
> information.  I.e. if the forwarding plane hasn't been programmed correctly
> then that might be either because the ACL YANG configuration (A) hasn't
> been applied or because the independent configuration (B) interferes with
> it.
>
> I think the substantial information is what parameters the system is
> currently using. If there is no guarantee that applied configuration has
> this information, then it is IMO much less interesting.
>
> I understand that for some systems the intended-applied configuration may
> be the right thing to do, so it could perhaps be defined as an optional
> capability. I just don't agree that this concept is universally applicable
> to all systems.
>
>

The concept is applicable to all systems.
There will be non-zero elapsed time on any system between
the time of the request and the time the config is applied.

The amount of time is purely an implementation detail.
Many servers accomplish this task in under 1 second for a typical edit.
Whether this elapsed time is an operational problem or not really depends
on the deployment.

Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 22 Dec 2015 09:49:25 +0100

> On 21 Dec 2015, at 22:34, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

Sure, but on some systems such as home routers this delay is of no interest, also because the admin edits the configuration and then has to apply it explicitly. This is how it works now (/etc/init.d/firewall reload), and NETCONF/RESTCONF just adds a solid remote operation.

Lada