I2RS Meeting 2/19/2015   

Agenda:    draft-netmod-clemm-datastore-push-00  (Alexander Clemm)   


Join WebEx meeting   
https://ietf.webex.com/ietf/j.php?MTID=m16b13629a3e3768ba09d1d2b23849b53   

Join by phone
1-877-668-4493 Call-in toll free number (US/Canada)   
1-650-479-3208 Call-in toll number (US/Canada)   
Access code: 646 011 019   

Etherpad for minutes:  
http://etherpad.tools.ietf.org:9000/p/i2rs-interim-2015-02-19-minutes  

Alexander Clemm presenting on proposals for push mechanisms.
draft-netmod-clemm-datastore-push
addresses requirements from draft-ietf-i2rs-pubsub-requirements
and enhances Netconf polling with a subscription based push mechanism.
This includes filter capability.  
It also includes policies such as period of time and frequency, and change damping mechanisms.
Using and RFC 5277 RPC "create-subscription" to subscribe to a stream called "push-update"


Eric Voit: Modify operations seems to be more preferred based on feedback from other lists. 

Joel Halpern: if you suspend and resume with exactly same parameters, you don't have to resend all?

Alex: yes. 


Eric Voit: Do we want subscriptions to be permanent? What about zombie subscriptions? Could be a mechanism in another draft to garbage collect stale subscriptions. 

Alex: Extension of subscription could be mapped to modify operation. 

Eric: Application logic could be added to supply this logic until the operations occur

Don Fedyk: Do you have any priority mechanism on subscriptions? 

Alex: Do subscribers come as a first-come-first serve priority or a type of priority - is a valid concern. We have not specified that in the draft. It is possible to add that priority scheme.  It is outside of this draft.

Eric: Think are coming into the next version of the requirements for QOS: deadline, etc.  

Alberto: This drafts describes mechanism to implement the priorities, but nothing is specified in the draft on how to implement these priorities? 

Alexander: We will publish in the next draft additional changes on the subscription model and the 
alternatives to we showed in this presentation on the push model.  Is there additional feedback? 

Ambika: Is this a streaming datastore? If not we are specifying filter to the data stream then what will happen - Will all the  data go to the client? 

Alexander:  If we do not specify any filters, then all the data stream will get pushed out (according to defaults).  On the other hand, if we specify filters going into the stream  - then you will get all the streams.   This is the nozzel vs. facet choice.

Don: Is there a model on how this data will flow from the switch?  Routing systems do not often have a lot of out-of-band channels for data.  

Alexander: Flow between the subscriber and the subscription service - =could be made more specific in the draft. The internal model within a router model is not written here. We considered this an internal aspect. 

Kent: Section 3.3 says that netconf datastore will be used. RFC5277 assumes a netconf cryptographic.  The config datastores are going through the dataplane so this would not be at a problem. The operational state will have a higher rate and be originated on the line cards.  Do we have any non-functional requirements on the operational rate to specify the rate limits?  

Alexander: This could lead one to an alternate transport model.  If you allow a different data model with two different data streams.  

Kent: Is there a requirement for I2RS for us to solve this problem? 

Alexander: I think this is an issue for I2RS for updates.  You do not know how much data will be flowed from operational state from a particular data model in a particular node.  It is hard to give a specific limit for a particular model, so it is important to have a negotiation on resource usage.  If the updates exceed rates, updates, and others. 

Eric: There are requirements in the I2RS on the limits and ranges of speed and data.  These requirements can give a baseline. 

Alberto: The servier can reject: a) at the initial request or b) during the life-type of the subscription. 

Sue Hares: Any other comments?  We had this informational presentation to help us understand what requirements should exist for I2RS pub/sub requirements. 

Alexander: We appreciate comments on the mailer.

[Meeting end 10:59 - recording is online, and revised minutes will show this information.]