Subject: [i2rs] I-D Action: draft-ietf-i2rs-pub-sub-requirements-01.txt

From: [email-masked]
Date: Mon, 09 Mar 2015 15:03:09 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Interface to the Routing System Working Group of the IETF.

        Title           : Requirements for Subscription to YANG Datastores
        Authors         : Eric Voit
                          Alex Clemm
                          Alberto Gonzalez Prieto
	Filename        : draft-ietf-i2rs-pub-sub-requirements-01.txt
	Pages           : 16
	Date            : 2015-03-09

Abstract:
   This document provides requirements for a service that allows client
   applications to subscribe to updates of a YANG datastore.  Based on
   criteria negotiated as part of a subscription, updates will be pushed
   to targeted recipients.  Such a capability eliminates the need for
   periodic polling of YANG datastores by applications and fills a
   functional gap in existing YANG transports (i.e.  Netconf and
   Restconf).  Such a service can be summarized as a "pub/sub" service
   for YANG datastore updates.  Beyond a set of basic requirements for
   the service, various refinements are addressed.  These refinements
   include: periodicity of object updates, filtering out of objects
   underneath a requested a subtree, and delivery QoS guarantees.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-i2rs-pub-sub-requirements-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-pub-sub-requirements-01

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.

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Mar 2015 16:13:14 -0700

Hi,

This draft says it addresses 2 deficiencies w/ existing mechanisms:

 The existing YANG technology ecosystem
   is proving insufficient for those applications due to:

   o  a reliance on RPC-style interactions where data is configured or
      fetched on-demand by applications.

   o  change notifications which identify a node associated with the
      config change, without the actual data updates

I don't understand why RFCs for configuration are a problem.
The nice thing about polling is that the server is fairly
sure the client is alive and still wants the updated info.

I certainly agree that things could be simpler on the client by
moving complexity to all the servers instead.  Not sure the
extra work each device will do is worth the increase in required
resources.

Currently, NETCONF/NACM does not support the access control
granularity that would be required to prune unauthorized data
from notifications (e.g., netconf-config-change for some unauthorized
data requires the new value to be removed from the payload,
depending on the user-id of the recipient).

Keeping the config data out of the notification was
a deliberate decision by the NETCONF WG, because of increased complexity
on the server, increased payload size, and lack of access-control support.

Andy

On Mon, Mar 9, 2015 at 3:03 PM,  <[email-masked]> wrote:
> _______________________________________________
> 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: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 10 Mar 2015 13:21:43 +0000

> The nice thing about polling is that the server is fairly sure the client is alive and
> still wants the updated info.

Polling is unlikely to have the required reaction speed. The very first requirement of the i2rs-usecase WG draft is "monitor the available routes installed in the RIB of each forwarding device, including near real time notification of route installation and removal".    

> I certainly agree that things could be simpler on the client by moving complexity
> to all the servers instead.  Not sure the extra work each device will do is worth
> the increase in required resources.
> 
> Currently, NETCONF/NACM does not support the access control granularity that
> would be required to prune unauthorized data from notifications (e.g., netconf-
> config-change for some unauthorized data requires the new value to be
> removed from the payload, depending on the user-id of the recipient).

Thanks.  We certainly need to explore this.  And solve this.
 
> Keeping the config data out of the notification was a deliberate decision by the
> NETCONF WG, because of increased complexity on the server, increased
> payload size, and lack of access-control support.

Understood.  And choices previously made can meet the needs of many applications.  However supporting quick reaction to topology changes gets hard when multiple interactions are needed to figure out the specifics of the routing update.

Eric
 
> > 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.
> >
> > Internet-Draft directories: http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs