Subject: [Netconf] time for a new NETCONF version?

From: Andy Bierman <[email-masked]>
Date: Sat, 9 Apr 2016 22:04:06 -0700

Hi,

There are many deficiencies in NETCONF 1.1 that should be addressed.
One in particular that keeps coming up at every IETF is the hard-wired
XML encoding or all NETCONF messages.

There is currently a YANG to JSON draft almost standardized
and a YANG to CBOR draft just started.  IMO it is time to
support a more advanced capabilities exchange so the client
can pick a different message encoding, and new encoding formats
can be added without republishing the protocol.

I already proposed a way to do this in NETCONF:
https://tools.ietf.org/html/draft-bierman-netconf-efficiency-extensions-01#section-1.3.2

A mechanism like this can be interoperable without the NETCONF WG
controlling every possible encoding that may be used with NETCONF.

Andy

---

From: Giles Heron <[email-masked]>
Date: Wed, 13 Apr 2016 16:25:40 +0100

Hi Andy,

Is there any great value in using a different encoding to XML when using NETCONF as the transport protocol?

that feels a bit like creating options for the sake of options - unless I’m missing something.

Re JSON of course we have RESTCONF transport (since web developers generally prefer JSON to XML there’s value in having JSON as an alternative encoding to XML).

Re CBOR the draft talks about constrained nodes/networks - where I’m guessing NETCONF won’t be the transport (at any rate the draft doesn’t include the word NETCONF).   I guess I2RS, YANG push etc. could potentially leverage CBOR too?  But either way I’m not sure NETCONF itself needs it - for configuration operations the “commit” is probably the bottleneck so more efficient message encoding may be a non-issue.

Giles

> On 10 Apr 2016, at 06:04, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
> https://tools.ietf.org/html/draft-bierman-netconf-efficiency-extensions-01#section-1.3.2 <https://tools.ietf.org/html/draft-bierman-netconf-efficiency-extensions-01#section-1.3.2>
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Apr 2016 08:39:07 -0700

> NETCONF as the transport protocol?
The only value is to get the same info exchanged between peers, but to use
50 - 90%
less bytes on the wire.

that feels a bit like creating options for the sake of options - unless I’m
> missing something.
>
> Re JSON of course we have RESTCONF transport (since web developers
> generally prefer JSON to XML there’s value in having JSON as an alternative
> encoding to XML).
>
> Re CBOR the draft talks about constrained nodes/networks - where I’m
> guessing NETCONF won’t be the transport (at any rate the draft doesn’t
> include the word NETCONF).   I guess I2RS, YANG push etc. could potentially
> leverage CBOR too?  But either way I’m not sure NETCONF itself needs it -
> for configuration operations the “commit” is probably the bottleneck so
> more efficient message encoding may be a non-issue.
>
>
OK, seems like commit is an implementation issue, not a protocol issue.
CORE WG will work on an efficient protocol using YANG.

Giles

Andy

---

From: Ashesh Mishra <[email-masked]>
Date: Wed, 13 Apr 2016 08:44:29 -0700

+1 for Andy's comment. 

For certain applications (telemetry is one such example) xml encoding is too large. 

I support at least investigating what v2 should address and what it will look like. 

--
Ashesh

Excuse brevity. Sent from mobile. 

> On Apr 13, 2016, at 8:39 AM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> The only value is to get the same info exchanged between peers, but to use 50 - 90%
> less bytes on the wire.
> 
>

---

From: Giles Heron <[email-masked]>
Date: Wed, 13 Apr 2016 16:46:03 +0100

> On 13 Apr 2016, at 16:44, Ashesh Mishra <[email-masked]> wrote:
> 
> +1 for Andy's comment. 
> 

agreed.  But I’m not sure NETCONF is the optimal transport for telemetry.

> On Apr 13, 2016, at 8:39 AM, Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> 
>> 
>> On Wed, Apr 13, 2016 at 8:25 AM, Giles Heron <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi Andy,
>> 
>>> On 10 Apr 2016, at 06:04, Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi,
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
> <Mail Attachment.txt>

---

From: Ashesh Mishra <[email-masked]>
Date: Wed, 13 Apr 2016 08:51:18 -0700

> On Apr 13, 2016, at 8:46 AM, Giles Heron <[email-masked]> wrote:
> 
> 

I'm on the fence with that. The proposed PUSH mechanism is pretty nifty. Also, if I'm interpreting it right, Andy is suggesting we fix the deficiencies of NETCONF in the new version (and the lack of flexibility in encoding bring one of the bigger issues at this time).

---

From: Giles Heron <[email-masked]>
Date: Wed, 13 Apr 2016 16:54:03 +0100

Hi Ashesh

> On 13 Apr 2016, at 16:51, Ashesh Mishra <[email-masked]> wrote:
> 
> 
> 
> On Apr 13, 2016, at 8:46 AM, Giles Heron <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> 
>>> On 13 Apr 2016, at 16:44, Ashesh Mishra <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> +1 for Andy's comment. 
>>> 

sure, PUSH is nifty.  But I’m not sure NETCONF is what you’d come up with if you started out with a clean sheet of paper to design a protocol for pushing telemetry data?

Giles

---

From: Ashesh Mishra <[email-masked]>
Date: Wed, 13 Apr 2016 09:09:43 -0700

> On Apr 13, 2016, at 8:54 AM, Giles Heron <[email-masked]> wrote:
> 
> Hi Ashesh
> 

I agree. But telemetry is just one of the applications. For a majority of uses, NC is pretty darn good. If it is possible to execute more functions using NC, I'm in support of reducing an extra system in network management.  

--
Ashesh

---

From: t.petch <[email-masked]>
Date: Wed, 13 Apr 2016 17:12:06 +0100

Andy

Um; I would rather take a step back and get a better architecture first.

When asked what SNMP is, I usually point to RFC1155 which introduces a
'simple, workable architecture '.  With NETCONF we dived into the
protocol except that that was not enough so we have a protocol and other
bits and pieces in the RFC.  YANG likewise, enmeshed with NETCONF, but
adding some more pieces.  So when an I2RS or an openconfig comes along,
they usually miss out on the key concepts, such as a datastore, because
they are not set out as clearly as key concepts might be, in amongst the
protocol and the DDL.

I would like NETCONF to be stripped down to be a protocol, with an
equivalent to RFC1155 setting out the framework, of which a protocol is
part.  (It would have made RESTCONF somewhat easier).

By the same token, I would have been more supportive of the recurrent
suggestions on the netmod list to take NETCONF out of the YANG RFC (
more so than of YANG1.1:-)

That done, then a replacement/enhanced protocol would be simpler to
design.

Tom Petch

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Netconf" <[email-masked]>
Sent: Sunday, April 10, 2016 6:04 AM

> I already proposed a way to do this in NETCONF:
https://tools.ietf.org/html/draft-bierman-netconf-efficiency-extensions-
01#section-1.3.2

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Apr 2016 09:32:43 -0700

Hi,

It is usually considered a good idea to decouple the message encoding format
from the protocol.  I don't want to start over with NETCONF.
It works fine even if the message sizes are large.
RESTCONF can address those issues.

Andy

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Wed, 13 Apr 2016 17:49:37 +0000

Hi Giles,

Your clean sheet of paper design presumably does not include clean sheet for how you model the data itself – for this one you presumably accept YANG models?  When you do that, you already constrain your design space considerably.

On the push side, one important aspect concerns the separation of the control model / the management of the subscriptions, from the push updates themselves.  I also think the YANG/Netconf framework should not be considered as something completely static; it may be evolved as requirements evolve.

For control model / subscription management, the current framework works provides a very good basis IMHO.  For push messages themselves, sure, there may be need for different transports and encodings, which I think can be accommodated via extensions to the framework.

--- Alex

From: Netconf [mailto:[email-masked]] On Behalf Of Giles Heron
Sent: Wednesday, April 13, 2016 8:54 AM
To: Ashesh Mishra <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [Netconf] time for a new NETCONF version?

Hi Ashesh

On 13 Apr 2016, at 16:51, Ashesh Mishra <[email-masked]<mailto:[email-masked]>> wrote:

On Apr 13, 2016, at 8:46 AM, Giles Heron <[email-masked]<mailto:[email-masked]>> wrote:

On 13 Apr 2016, at 16:44, Ashesh Mishra <[email-masked]<mailto:[email-masked]>> wrote:

+1 for Andy's comment.

Giles

--
Ashesh

On Apr 13, 2016, at 8:39 AM, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Apr 13, 2016 at 8:25 AM, Giles Heron <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,

Giles

Andy

On 10 Apr 2016, at 06:04, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Andy

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

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf
<Mail Attachment.txt>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Apr 2016 11:32:08 -0700

Hi,

So now we are starting over on NETCONF and YANG.

Sorry I brought up the topic.

XML is good enough for NETCONF.
I do not agree that the half-baked YANG modules that say
the protocol will use a different encoding are a good idea.
The message encoding is part of the protocol, not a YANG module.
(i.e, NETCONF MUST use XML. Period.  Use another protocol
if XML encoding is not desired.)

Andy

On Wed, Apr 13, 2016 at 10:49 AM, Alexander Clemm (alex) <[email-masked]>
wrote:

> Hi Giles,
>
>
>
> Your clean sheet of paper design presumably does not include clean sheet
> for how you model the data itself – for this one you presumably accept YANG
> models?  When you do that, you already constrain your design space
> considerably.
>
>
>
> On the push side, one important aspect concerns the separation of the
> control model / the management of the subscriptions, from the push updates
> themselves.  I also think the YANG/Netconf framework should not be
> considered as something completely static; it may be evolved as
> requirements evolve.
>
>
>
> For control model / subscription management, the current framework works
> provides a very good basis IMHO.  For push messages themselves, sure, there
> may be need for different transports and encodings, which I think can be
> accommodated via extensions to the framework.
>
>
>
> --- Alex
>
>
>
> *From:* Netconf [mailto:[email-masked]] *On Behalf Of *Giles
> Heron
> *Sent:* Wednesday, April 13, 2016 8:54 AM
> *To:* Ashesh Mishra <[email-masked]>
> *Cc:* Netconf <[email-masked]>
> *Subject:* Re: [Netconf] time for a new NETCONF version?
>
>
>
> Hi Ashesh
>
>
>
> I'm on the fence with that. The proposed PUSH mechanism is pretty nifty.
> Also, if I'm interpreting it right, Andy is suggesting we fix the
> deficiencies of NETCONF in the new version (and the lack of flexibility in
> encoding bring one of the bigger issues at this time).
>
>
>
> sure, PUSH is nifty.  But I’m not sure NETCONF is what you’d come up with
> if you started out with a clean sheet of paper to design a protocol for
> pushing telemetry data?
>
>
>
> Giles
>
>
>
>
>
>
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 13 Apr 2016 11:32:58 -0700

[Chair hat off]

+1

I would support the idea of the WG exploring the separation of transport from the encoding mechanisms used. 

There is clearly a need to have different encoding formats to meet different requirements. While XML and JSON works great for smaller pieces of data, we have not dealt with the issue of bulk data and its requirements. YANG push and streaming of operational data are examples of that. If extensions to the protocol allow for that flexibility, I would support it.

Thanks

> On Apr 13, 2016, at 10:49 AM, Alexander Clemm (alex) <[email-masked]> wrote:
> 
> Hi Giles,
>  
> On 13 Apr 2016, at 16:51, Ashesh Mishra <[email-masked] <mailto:[email-masked]>> wrote:
>  
> 
> 

Mahesh Jethanandani
[email-masked]

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 14 Apr 2016 08:16:18 +0200

> On 13 Apr 2016, at 17:39, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

This may be true for an implementation that support *both* XML and JSON. If you go JSON-only, then parsing and dealing with data in general becomes considerably simpler - no DOMs or event-driven APIs are needed. XML is great as for marked-up text (as in HTML) but much less so as a data exchange format.

Lada

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