Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2

["Alberto Gonzalez Prieto (albertgo)" <[e-mail]>]

Thanks Andy,

Agreed.

For the example below, using a periodic subscription on the list of interfaces would result in ~100k entries.
Alternatively, using an on-change subscription would result in a single entry on the wire (I.e., just the config delta).
How efficient the delta computation (on the publisher) would be is implementation-specific.
A publisher implementation has the option of not accepting/supporting on-change subscriptions. A reason for not accepting an on-change subscription is a high  computational cost for serving it.
That is, there are trade-offs that publishers can control wrt computational cost, space requirements, generated traffic.

Thanks,

Alberto

From: Andy Bierman <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, October 28, 2015 at 12:03 PM
To: Alberto Gonzalez Prieto <[e-mail]<mailto:[e-mail]>>
Cc: Kent Watsen <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Alia Atlas <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2

Hi,

The issue wrt/ PUT vs. PATCH is really a matter of context
and priorities.  If you delete 1 interface out of 100,000, and you
need to send the updated parent container, instead of just
sending "delete interface X", the message could be 10,000
times bigger on-the-wire.  The internal processing could be much
higher (e.g., compare 99,999 interfaces to the saved values
to determine there were no changes).  If efficiency is of
no concern, then updating the parent resource is probably OK.


Andy






On Wed, Oct 28, 2015 at 2:16 AM, Alberto Gonzalez Prieto (albertgo) <[e-mail]<mailto:[e-mail]>> wrote:
Thanks for the input Andy.

In the NETCONF draft, for on-change updates, we consider the operations in RFC6241 for edit-config, including merge, and delete.
(when using json encoding, the changes are encoded based on yang-patch)
Does that address the PUT/PATCH inefficiencies you mention?

FWIW, we do not explicitly include yang:insert from RFC6020. It makes sense to me including it since not using would lead to inefficiencies, as you correctly point out.
It also makes sense to me adding “move” to the list of operations in on-change updates.  Thanks for bringing this up.


For periodic updates, the updates contain a snapshot of the current state. That is analogous to a PUT. The rationale was that to compute the deltas, we would need (a potentially sizable) per-subscription state.
E.g., a subscription for fast-changing oper data subtrees with a large number of descendants. Such data may not be versioned and its incremental deltas may not be tracked. In such cases, the state to keep would be a replica of the snapshot used for the last update.

Thanks,

Alberto


From: Netconf <[e-mail]<mailto:[e-mail]>> on behalf of Andy Bierman <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, October 27, 2015 at 12:50 PM
To: Kent Watsen <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Alia Atlas <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2

Hi,

I support the feature in general as an optional addition to NETCONF or RESTCONF.
I was looking at the details a bit, and I don't think it covers all YANG operations
(such as insert, move, delete).

I am implementing a datastore replication protocol based on deltas
represented with YANG Patch.  This looks much more efficient in practice
than sending complete updates of resource representations to the client,
especially for delete, insert, and move.  You basically end up with PUT
instead of PATCH, with all the inefficiencies that involves.

I think the subscription and push control in the yang-push draft is great,
but the messages on the wire should be more efficient.


Andy


On Tue, Oct 27, 2015 at 12:22 PM, Kent Watsen <[e-mail]<mailto:[e-mail]>> wrote:

I think it important that whatever we do in NETCONF we can also do in RESTCONF.   To that end, I support the WG defining "yang-push” for both protocols.

Actually, I’m a little surprised that we’re discussing this.  Maybe it’s just me, but when the WG adopted draft-ietf-netconf-yang-push, I thought that it would cover both protocols eventually.   Perhaps that a separate draft has been produced is another surprise here - do we really need another draft?

Kent

From: Netconf <[e-mail]<mailto:[e-mail]>> on behalf of Susan Hares <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, October 27, 2015 at 2:52 PM
To: "'Eric Voit (evoit)'" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: 'Alia Atlas' <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2

NETCONF:

These drafts is important to the I2RS pub/sub.   Is the RESTCONF draft going to be adopted (draft-voit-restconf-yang-push-00.txt)?

It would be really helpful.

Sue Hares
I2RS WG chair

From: Netconf [mailto:[e-mail]] On Behalf Of Eric Voit (evoit)
Sent: Tuesday, October 13, 2015 11:37 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2

There are a couple new drafts posted in NETCONF:

(1)  Subscribing to YANG datastore push updates
http://www.ietf.org/id/draft-clemm-netconf-yang-push-02.txt
As per earlier NETCONF discussions<http://www.ietf.org/mail-archive/web/netconf/current/msg10432.html> we are expecting this draft to become draft-ietf-netconf-yang-push in the coming days (once the NETCONF charter is approved).  Look for an OpenDaylight client in the Beryllium release (Feb).

(2) Restconf subscription and HTTP push for YANG datastores
http://www.ietf.org/id/draft-voit-restconf-yang-push-00.txt
Extends draft-clemm-netconf-yang-push in the following ways:

·     proposes Restconf subscription and push mechanisms to continuously stream information from YANG datastores over HTTP

·     provides a mechanism to support static subscriptions so that an operator can stream updates over HTTP without Restconf

·     provides YANG model extensions to leverage HTTP/2 so that individual subscriptions can get custom treatment via their own HTTP streams.

Thanks for your interest, and we look forward to the discussions!

- Alexander Clemm, Eric Voit, Alberto Gonzalez Prieto, Ambika Prasad Tripathy, & Einar Nilsen-Nygaard





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