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.]