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

From: Andy Bierman <[email-masked]>
Date: Sat, 8 Sep 2012 19:57:17 -0700

FYI,

I wrote this draft to address NETCONF data retrieval deficiencies.
It is related to operational data, but not limited in scope to
operational data.

Andy

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Sat, Sep 8, 2012 at 7:53 PM
Subject: I-D Action: draft-bierman-netconf-get2-00.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-00.txt
        Pages           : 26
        Date            : 2012-09-08

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

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: "Bert Wijnen (IETF)" <[email-masked]>
Date: Mon, 10 Sep 2012 12:02:37 +0200

Thanks Andy!
This is constructive.

First I would like to ask people to specifically read the
problem statement sections and post comments on that.
Specifically, do you agree with the problems listed and
that we (WG) need to work on a solution.
Do you see any other problems that are not yet listed
and that must be solved by the WG.

Of course you can discuss Andy's solution paragraphs too.
But for the WG to decide if we want to work on this, we
need to get agreement on the problem statement/problem space.

Bert

On 9/9/12 4:57 AM, Andy Bierman wrote:
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 14 Sep 2012 13:32:34 +0200 (CEST)

Hi,

> problem statement sections and post comments on that.

Ok, here are my comments on this section.  I have not reviewed the
entire document yet.

1.1.1.  Too Much Data Returned

  I agree that it is probably a bug that <get> returns both the
  running config and the operational state.  However, the reason is
  not that you get too much data; the problem is that you get wrong
  data.

1.1.2.  No Last-Modified Indication or Time Filtering

  This would be nice to solve, but not very high prio.

1.1.3.  No Simple Instance Discovery Mechanism

  I think subtree filtering works fine for this purpose.  In fact, we
  rely on this heavily in our prodcuts.

1.1.4.  No Subtree Depth Control

  I agree that this is a real problem, and I would like to see a
  solution.  I would label this as "Too Much Data Returned".

  An example is how you check if a P-container exists or not, without
  returning the entire subtree under the P-container.   This is
  non-trivial today.

1.1.5.  Content Filter Specification is not Extensible

  This is a nice to have, imo.

1.1.6.  Subtree Filtering is Mandatory

  I guess this goes back to the discussion about NC/Lite.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 14 Sep 2012 08:35:50 -0700

>   not that you get too much data; the problem is that you get wrong

It is all unwanted data adding to the size of the response.

>   This would be nice to solve, but not very high prio.

IMO high priority because large configs take real resources to process.

>   rely on this heavily in our prodcuts.

It is complicated to construct all the subtree filters in an app,
and every list has to be known to the application.
Simply asking the server for <keys-only /> is 100 times easier.

>   I guess this goes back to the discussion about NC/Lite.

That discussion was subtree vs. nothing.
This is a different discussion because <depth> is mandatory
and 'operational' is a separate datastore.  There are also other
optional types of filtering that are much less expensive
to implement than subtree filtering.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Fri, 14 Sep 2012 09:37:11 -0700

>  not that you get too much data; the problem is that you get wrong

Martin, can you say some more about how wrong data is returned?

I think the first question needs to be if there is any value in keeping
<get> in any form.  If it not possible to prevent wrong data from being
returned, then maybe it should go away completely.

All the NETCONF servers I know return operational data via RPCs only,
perhaps an indication that putting operational data in the tree is not
what vendors want to do

Is there a limit to how much operational state can be put into the tree?
It seems reasonable to have a flag indicating if an interface is up/down,
but what about interface statistics or a routing table?  Of course it's
possible to put these things into the tree, but it seems that they would
always be leaf-nodes and would always be selected by themselves, at which
point they're no different than RPCsŠ

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Fri, 14 Sep 2012 10:06:31 -0700

> returned, then maybe it should go away completely.

You mean 'deprecated' for a couple years, then 'obsolete'?
That might be OK.

> perhaps an indication that putting operational data in the tree is not

Many servers are capable of supporting <get>.

But there does seem to be a strong tendency not to
mix config=true and config=false nodes in the same YANG modules.
Keeping all the data separate duplicates all the 'framing' nodes
and keys.

The <get2> operation defines config=false + ancestor nodes + keys
to be the 'operational datastore'.  It is never mixed with config=true
nodes.

There are problems with 1000 different <get-foo> operations:
  - no input parameter consistency
  - less common code on the client
  - no common features like filtering
  - more complex access control rules; not sure
    what data is returned in each <get-foo>
 - there is no standard mechanism to associate
   a <get-foo> operation with any config=true data

> Is there a limit to how much operational state can be put into the tree?

This seems like an implementation detail.
There is no limit -- it is up to the server.

> point they're no different than RPCsŠ

I don't see any problem with mixing config=true and config=false
in the same conceptual tree.  The counters themselves do not
have to be stored in "the tree" -- another implementation detail.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 14 Sep 2012 22:09:40 +0200 (CEST)

> Martin, can you say some more about how wrong data is returned?

Actually, there will be draft around this RSN.  So let us get back to
this when we're done with that draft.

> perhaps an indication that putting operational data in the tree is not

All NETCONF servers I know, except Junos, put the operational data in
the tree.  This is also how SNMP does it.

> Is there a limit to how much operational state can be put into the tree?

No.  The tree is conceptual.  Noone pushes all counters into a db as
they are incremented.  They are typically fetched upon request.  Just
like your typical SNMP agent.

> point they're no different than RPCs.

I agree 100% with Andy's reply to this.  I can add that with
different RPCs it also becomes more tricky to do aggregation on a
higher level (reading a value here and a value there and combine
them).

/martin

---

From: Carl Moberg <[email-masked]>
Date: Fri, 14 Sep 2012 19:24:19 -0700

> perhaps an indication that putting operational data in the tree is not

 The two widely available server implementations I know of does not have this arbitrary limitation. I also know of at least 10 products shipping without the limitation and several more hitting the market over the coming quarters.

 I don't see that indication.

--
Carl Moberg
mailto:[email-masked]
twitter: @cmoberg
http://www.tail-f.com/
 
Tail-f Developer Days Silicon Valley is coming up:
 http://www.tail-f.com/tail-f-developer-days-silicon-valley

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 20 Sep 2012 11:57:40 +0200

Hello,
I like your draft, it is interesting, should become a WG item.

1.1.2.  No Last-Modified Indication or Time Filtering -   Important

1.1.3.  No Simple Instance Discovery Mechanism -   Important

1.1.4.  No Subtree Depth Control - Most important

  1.1.5.  Content Filter Specification is not Extensible - We already 
have an own mechanism, but we can handle that internally

1.1.6.  Subtree Filtering is Mandatory  - unknown

We often also have a requirement, to be able to specify which leafs to 
return. We have lists with big numbers of leafs. Do others see this 
requirement?

-------------------------------------

  It seems strange that non-presence containers are not on a separate 
level. Why?

leaf names inside the filter-specshould be more expresive. A fileter 
called "filter"  is to generic -> subtree-filter

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 20 Sep 2012 12:35:21 +0200 (CEST)

Hi,

Balazs Lengyel <[email-masked]> wrote:
> return.

You can do this already with subtree filtering:

  <interface>
     <name>eth0</name>
     <mtu/>    <!-- selection node -->
     <speed/>  <!-- selection node -->
     ...
  </interface>

Or did you mean something else?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 20 Sep 2012 06:24:25 -0700

> I like your draft, it is interesting, should become a WG item.

thanks

>  1.1.5.  Content Filter Specification is not Extensible - We already have an
> own mechanism, but we can handle that internally
>

select leafs by name?  sub-tree filtering does that.
Filter by name prefix?  XPath can do that (starts-with(.) = 'foo')
Not sure this is a new requirement.

>  It seems strange that non-presence containers are not on a separate level.
> Why?

I was thinking that they should be ignored for layering because
they are transparent, but maybe that is too complicated and
not how NP containers should be retrieved.  It would be simpler
to treat every child node as the 'next layer'.

>
> leaf names inside the filter-specshould be more expresive. A fileter called
> "filter"  is to generic -> subtree-filter

OK

Andy