Subject: [netmod] New Version Notification for draft-wilton-netmod-opstate-yang-00.txt

From: Robert Wilton <[email-masked]>
Date: Thu, 3 Sep 2015 21:40:58 +0100

Hi,

I've posted a new experimental draft, that proposes a potential 
different solution for handling applied configuration, for possible 
discussion at next week's interim meeting on opstate.

Comments before hand are welcome.

Thanks,
Rob

-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-wilton-netmod-opstate-yang-00.txt
Date: 	Thu, 3 Sep 2015 13:31:00 -0700
From: 	[email-masked]
To: 	Robert Wilton <[email-masked]>, Robert Wilton <[email-masked]>

A new version of I-D, draft-wilton-netmod-opstate-yang-00.txt
has been successfully submitted by Robert Wilton and posted to the
IETF repository.

Name:		draft-wilton-netmod-opstate-yang
Revision:	00
Title:		"With-config-state" Capability for NETCONF/RESTCONF
Document date:	2015-09-03
Group:		Individual Submission
Pages:		22
URL:            https://www.ietf.org/internet-drafts/draft-wilton-netmod-opstate-yang-00.txt
Status:         https://datatracker.ietf.org/doc/draft-wilton-netmod-opstate-yang/
Htmlized:       https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-00

Abstract:
    This document proposes a possible alternative solution for handling
    applied configuration state in YANG as described in draft-openconfig-
    netmod-opstate-01.  The proposed solution, roughly modelled on the
    with-defaults NETCONF/RESTCONF capability, aims to meet the key
    requirements set out in draft-openconfig-netmod-opstate-01 without
    the need for YANG module authors to explicitly duplicate
    configuration nodes in both configuration and operational containers.
    This draft does not address the issue of co-location of configuration
    and operational state for interfaces, nor does it provide a NETCONF
    mechanism to retrieve operational data separately from configuration
    data.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Andy Bierman <[email-masked]>
Date: Thu, 3 Sep 2015 14:50:35 -0700

On Thu, Sep 3, 2015 at 1:40 PM, Robert Wilton <[email-masked]> wrote:

> Hi,
>
> I've posted a new experimental draft, that proposes a potential different
> solution for handling applied configuration, for possible discussion at
> next week's interim meeting on opstate.
>
This is better than the "config" and "state" containers at least.
Multiple schema nodes to represent the same object in different states
doubles the complexity of the module. Considering 97% + of devices
don't need this stuff, that's just not worth 2X the cost.

However, it is important that the schema be stable.
The way an <rpc-reply> is parsed cannot really depend on an <rpc> that
was sent earlier.  But a leaf like <mtu> will either be represented as a
leaf
or as a container in the <rpc-reply>, depending on
the <with-config-state> parameter that was sent in the <rpc>.

I appreciate sec. 7. It is good to relate the solution back to
the requirements (even if that list seems to be growing every week).

I have not personally seen the problems in the requirements list.
The delay between intended and applied is usually milliseconds, sometimes
seconds.
I don't agree that we need to diagnose line cards that are not plugged in.
The operator should figure this out some other way (e.g. entity-mib).

It is not clear how long this data will indicate 'in progress'.
Most of the time, <cfg-intended> and <cfg-actual> will be the same.
(This basically triples the size of a <get-config> response)
I don't see why any enum other than 'diff-cfg-only' would be used.
This is how I would also expect the <get-state> operation to work in Kent's
draft.

It would really help if you included the YANG module you want to
standardize.  There are a couple examples but no formal definition.

Thanks,
> Rob

Andy

>
>
> -------- Forwarded Message -------- Subject: New Version Notification for
> draft-wilton-netmod-opstate-yang-00.txt Date: Thu, 3 Sep 2015 13:31:00
> -0700 From: [email-masked] To: Robert Wilton <[email-masked]>
> <[email-masked]>, Robert Wilton <[email-masked]> <[email-masked]>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 4 Sep 2015 09:38:34 +0200

Hm. Adding a parameter to get-config() that changes the encoding of
data very fundamentally is somehow difficult to fall in love with.

If you would have used meta-data, things would likely easier to like,
e.g., instead of

     <mtu>
       <cfg-intended>9000</cfg-intended>
       <cfg-status>waiting</cfg-status>
       <cfg-status-reason>Linecard 1 is not available</cfg-status-reason>
     </mtu>

using something like this

     <mtu status="waiting" status-reason="Linecard 1 is not available">
       9000
     </mtu>

would have made more sense to me from an encoding point of view. There
might be issues with carrying actual config values in metadata in XML,
I guess I like the actual datastore approach still a bit more (but
perhaps having standard meta-data annotations providing additional
information might actually be useful.

/js

On Thu, Sep 03, 2015 at 09:40:58PM +0100, Robert Wilton wrote:
> URL:            
> https://www.ietf.org/internet-drafts/draft-wilton-netmod-opstate-yang-00.txt
> Status:         
> https://datatracker.ietf.org/doc/draft-wilton-netmod-opstate-yang/
> Htmlized:       
> https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-00
> 
> 
> Abstract:

-- 
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: Robert Wilton <[email-masked]>
Date: Fri, 4 Sep 2015 11:11:14 +0100

Hi Andy,

Thanks for the review and comments, please see inline ...

On 03/09/2015 22:50, Andy Bierman wrote:
>
>
> On Thu, Sep 3, 2015 at 1:40 PM, Robert Wilton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     different solution for handling applied configuration, for
>     possible discussion at next week's interim meeting on opstate.
>

> doubles the complexity of the module.
Agreed.

> Considering 97% + of devices

Not sure that I agree with the the 97% figure, but I don't have any 
concrete data to go on ...

> was sent earlier.  But a leaf like <mtu> will either be represented as 
> a leaf
Generally, I would prefer it if an <rpc-reply> could be processed 
independently of the <rpc> request (e.g. perhaps by embedding the 
request data in the response).

However, it seems to me that you already need to know the context of the 
request to be able to semantically process the reply.
E.g. I would expect that you would need to know what the request is, 
what filters are in effect, when any of the get-default options are in 
effect (since that changes the meaning of the data returned for some 
config nodes).

So, I appreciate that if can't be a generic parser cannot be used, then 
a client would need to perform a lookup of the request context before 
parsing the reply.  But it doesn't feel like this is a particularly hard 
problem.

> I have not personally seen the problems in the requirements list.
Some Cisco devices (that I haven't directly worked with) use an eventual 
consistency configuration model, and would probably more naturally fit 
into a split intended/applied config model proposed by the Open Config 
group.  Further, I suspect that more of the new developed devices may 
adopt this approach in future.

> The delay between intended and applied is usually milliseconds, 
> sometimes seconds.
For many of the smaller config changes that I agree that they might only 
take a second or two.

But for large scale config changes (e.g. 1M+ lines of config) then it 
can take 1-30 minutes to apply the configuration and ensure that all of 
the hardware is programmed.  For these systems, I can see that there is 
a benefit to be able to see exactly what configuration is in effect at a 
given point in time.

I suspect that one of the reasons that the global Internet works so well 
is because the routing protocols adopt an eventual consistency model, 
e.g. the global routing table being in constant flux.  So I can also 
certainly see the appeal of adopting an asynchronous eventual 
consistency configuration model where 10,000's of devices are being 
managed and the network is being constantly dynamically optimized for 
the demands being placed on it.

> The operator should figure this out some other way (e.g. entity-mib).
OK, what about a linecard that has crashed, or failed to boot, or 
suffered a hardware failure?

Ultimately, the operator (which in this scenario will probably be a 
machine) needs to able to correlate a failure back to the operation that 
it was trying to achieve in the first place.  The related-state 
statement in Kent's draft helps here, but for an asynchronous 
configuration model there needs to be a way to indicate errors in 
applying that configuration that previously could have been returned as 
<rpc-error>'s in the <rpc-reply> of the original <edit-config> request.

> Most of the time, <cfg-intended> and <cfg-actual> will be the same.
Agreed.

> I don't see why any enum other than 'diff-cfg-only' would be used.
OK.

> This is how I would also expect the <get-state> operation to work in 
> Kent's draft.
I may be misunderstanding Kent's draft (I'll send comments on it 
separately), but I read the <get-state> operation as only returning 
"config false" nodes and hence doesn't help with the intended config vs 
applied config problem.

> standardize.  There are a couple examples but no formal definition.
OK.  I'll try and also write that up.  My excuse is that I spent quite a 
lot of August on PTO and hence have only had a couple of days to write 
this idea up.

Thanks again for the comments,
Rob

>     From: 	[email-masked] <mailto:[email-masked]>
>     To: 	Robert Wilton <[email-masked]> <mailto:[email-masked]>,
>     Robert Wilton <[email-masked]> <mailto:[email-masked]>
>
>
>
>     URL:https://www.ietf.org/internet-drafts/draft-wilton-netmod-opstate-yang-00.txt
>     Status:https://datatracker.ietf.org/doc/draft-wilton-netmod-opstate-yang/
>     Htmlized:https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-00
>
>
>     Abstract:
>     until the htmlized version and diff are available attools.ietf.org <http://tools.ietf.org>.
>
>     The IETF Secretariat
>
>
>
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Robert Wilton <[email-masked]>
Date: Fri, 4 Sep 2015 11:33:27 +0100

Hi Juergen,

Thanks for the review and comments.

Yes, when I originally thought of this idea I intended using XML 
attributes, but after discussion with a couple of colleagues, we saw a 
couple of issue with using them:

1) One of the desired requirements in draft-openconfig-netmod-opstate-01 
(section 4.5 last paragraph) is to have a unique path to identify the 
intended cfg node vs the applied cfg node.  I couldn't see how this 
could be solved with attributes.  I'm also not sure whether the separate 
applied config data store solves this problem, although presumably a NMS 
could store all paths as a (datastore, path) pairing.

2) I wanted to be able to represent config nodes for configuration that 
are in the process of being deleted (i.e. applied but not intended), and 
wasn't convinced that this could be achieved cleanly using attributes.

3) There doesn't seem to be any standard encoding for attributes in JSON 
... although of course this doesn't prevent attributes from being used 
in XML based encodings.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 4 Sep 2015 20:20:57 +0200

> could store all paths as a (datastore, path) pairing.

Yep, I do not agree with this requirement. Datastores are an
architectural concept in both NETCONF and YANG and hence an NMS needs
to understand what a datastore is.

> wasn't convinced that this could be achieved cleanly using attributes.

Yep. This may require some careful design.

> ... although of course this doesn't prevent attributes from being used 

See draft-ietf-netmod-yang-metadata-01 section 4.2 for the proposed
JSON encoding.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 4 Sep 2015 15:35:13 -0700

> to understand what a datastore is.
+1

IMO is is extremely important that the instance-identifier  for a data node
be
exactly the same in each datastore.  This is much easier to manage
than if the data is named differently, depending whether it is
intended or actual.

> Yep. This may require some careful design.

The same careful design is needed for pub/sub to identify deleted nodes
in the delta.

> See draft-ietf-netmod-yang-metadata-01 section 4.2 for the proposed
We have already implemented this draft, so if there are any problems
that require changes, it would be good to know about it ASAP

Andy

---

From: Robert Wilton <[email-masked]>
Date: Mon, 7 Sep 2015 09:36:06 +0100

On 04/09/2015 23:35, Andy Bierman wrote:
>
>
> On Fri, Sep 4, 2015 at 11:20 AM, Juergen Schoenwaelder 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> IMO is is extremely important that the instance-identifier  for a data 
> node be

If datastores are the right solution for intended vs actual, then I 
completely agree that they should have the same path in both.

> The same careful design is needed for pub/sub to identify deleted nodes
OOI, has any one proposed how this should be done yet, or is pub/sub not 
at that stage yet?

> that require changes, it would be good to know about it ASAP
I just wasn't aware of this draft.  I'll give it a read.

In particular, I was reading ietf-netconf-restconf-06, section 4.8.9 on 
with-defaults, particularly the report-all-tagged option.  I think that 
it might be helpful if the description of the "report-all-tagged" 
description also had a reference to draft-ietf-netmod-yang-metadata (or 
alternatively section 5.4) for the JSON encoding of the "default" attribute.

Thanks,
Rob