Subject: [Netconf] Fwd: I-D Action: draft-bierman-netconf-get2-02.txt

From: Andy Bierman <[email-masked]>
Date: Tue, 9 Oct 2012 14:34:46 -0700

FYI,

I updated the <get2> draft to include support
for operational data sources.  The <config-source>
parameters were removed from ietf-system.yang because
a general solution was going to replace it.
The draft now addresses that issue.

Andy

---------- Forwarded message ----------
From: <[email-masked]>
Date: Tue, Oct 9, 2012 at 2:32 PM
Subject: I-D Action: draft-bierman-netconf-get2-02.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : The NETCONF <get2> Operation
        Author(s)       : Andy Bierman
        Filename        : draft-bierman-netconf-get2-02.txt
        Pages           : 38
        Date            : 2012-10-09

Abstract:
   This document describes NETCONF protocol enhancements to improve data
   retrieval capabilities.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bierman-netconf-get2

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bierman-netconf-get2-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-bierman-netconf-get2-02

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Oct 2012 22:36:34 +0200

Hi,

I read the draft, I think it contains a number of useful improvements over the existing <get> and <get-config> methods. Here are my comments:

1. The operational datastore contains some "config true" container and list nodes, which may lead to a situation where the operational and running datastores get out of sync. For example, what happens if an <edit-config> removes a list entry that's also present in the operational datastore? Two scenarios seem to make sense, and both can be in fact applicable to different entries of the same list: either the entry stays in the op. datastore or it is also deleted. The draft should address this.

2. Besides the "depth" parameter, a "length" parameter might be useful for limiting the number of returned list entries, such as routes. A related convenient feature would be some kind of paging.

3. Maybe "data-source" needs finer granularity because potentially it may result in huge output even if the client is only interested in the data source for one or few nodes. One way can be to allow the client to ask for or suppress data source info as a part of the filter, e.g.,

         <subtree-filter>
           <system xmlns="urn:ietf:params:xml:ns:yang:ietf-system"
                   ds:data-source="false"> <!-- suppress for subtree -->
             <clock>
               <!-- override - enable for one node -->
               <current-datetime ds:data-source="true"/>
             </clock>
           </system>
         </subtree-filter>

Lada
  
Andy Bierman <[email-masked]> writes:

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

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Oct 2012 19:40:09 -0700

On Wed, Oct 10, 2012 at 1:36 PM, Ladislav Lhotka <[email-masked]> wrote:

> Hi,
>
> I read the draft, I think it contains a number of useful improvements over
> the existing <get> and <get-config> methods. Here are my comments:
>
> 1. The operational datastore contains some "config true" container and
> list nodes, which may lead to a situation where the operational and running
> datastores get out of sync. For example, what happens if an <edit-config>
> removes a list entry that's also present in the operational datastore? Two
> scenarios seem to make sense, and both can be in fact applicable to
> different entries of the same list: either the entry stays in the op.
> datastore or it is also deleted. The draft should address this.
>

How can they get out of sync?  You mean by skew from the polling
implementation?
The operational datastore needs to be consistent with the ancestor nodes
and key leafs
that provide context.  Not a NETCONF-specific issue meaning any protocol
that
accesses both the config and operational datastores has this potential
problem.

>
> 2. Besides the "depth" parameter, a "length" parameter might be useful for
> limiting the number of returned list entries, such as routes. A related
> convenient feature would be some kind of paging.
>
>
I've talked to a couple NMS lead engineers who call this feature
"Iterators".
They really wanted it in NETCONF.

You need a start index and a max-number of entries.
Another approach is the Range from HTTP (borrowed in YANG-API).
It can get complicated, so I left it out of <get2>.
It probably needs its own draft. I agree it is a useful feature.

3. Maybe "data-source" needs finer granularity because potentially it may
> result in huge output even if the client is only interested in the data
> source for one or few nodes. One way can be to allow the client to ask for
> or suppress data source info as a part of the filter, e.g.,
>
>          <subtree-filter>
IMO, having the client set individual attributes in the request
and forcing the server to parse all the many combinations (just like
the operation and insert attributes) is too complicated.

You can limit the data returned with a subtree filter.
This example would only return 3 possible data-source attributes.
Only 1 YANG extension is used so only 1 attribute is sent.

IMO the data-source extension should only be used if there
is a demonstrated reason for the operator to care about the
data source identifier for that node.

Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 11 Oct 2012 07:58:57 +0200

On Oct 11, 2012, at 4:40 AM, Andy Bierman <[email-masked]> wrote:

> How can they get out of sync?  You mean by skew from the polling implementation?

For an interface, we will have an entry /if:interfaces/if:interface[if:name='X'] in both "running" and "operational", one with config=true and the other with config=false data, if I understand it correctly.
Now, if the client uses <edit-config> on "running" and deletes this entry, what happens to the entry in "operational"? If X is a physical interface, it should stay there, but if it is a configured tunnel, it should be removed, too.

Lada  

> The operational datastore needs to be consistent with the ancestor nodes and key leafs
> that provide context.  Not a NETCONF-specific issue meaning any protocol that
> accesses both the config and operational datastores has this potential problem.
> 
>  
> 
> I've talked to a couple NMS lead engineers who call this feature "Iterators".