I2RS Interim 2015-01-22 Attendees: Sue Hares Jeffrey Haas Eric Voit Ignas Bagdonas Xufeng Liu Don Fedyk Carlos Pignataro Alex Clemm Dan Romascanu Sriganesh Kini Cary Fitzgerald Alberto Prieto Dean Bogdanovic Kent Watsen [Agenda] Status. Traceability Pub-sub Status: Design teams on the wiki. Let chairs know if you want to join team [Traceability] Presenting: Carlos Pignataro [slides] Ignas: Re: resources required for logging, there may be a long delay between operation request and response. How do you log the request? Log immediately, or after it completes? Carlos: I think this is addressed in slide 8. Let me know if that is not the case. Slide 9 - granularity. See RFC 3339 Dean: Using nanoseconds, what do you expect to get? The drifts across multiple systems will be outside the granularity for inter-system comparison. It will be very precise, but hard to put together. Carlos: nanosecond good for correlating in-agent but not across systems. For systems that can do this, lets take advantage of it. Main point is we need to specify granularity. Jeff: issues about presentation formats. Human readable is nice - we should make it an option. Use 32.32 format to allow in-system and inter-system correlation. Ignas: Correlation context - in agent. Used in perspective of multiple requests within an agent rather than between agents. Jeff: Difference is in-system correlation vs. inter-system. Ignas: we are in agreement. Slide 11 Jeff: Long running transactions need transaction id. Tracing can use this. Our I2RS protocol is specified as asynchronous, We need to be submit a transaction and then the routing system must say "I've got it as a valid transaction", and then respond later "this is done now." Due to this, the I2RS protocol will require a transaction id. This transaction id would be useable here. Kent: This is correct. The bulk-transfer and interactive CLI presentation and long-run transaction share this requirements. I sent an email to the netconf group that described this problem. The hope is that the solution to this problem would be from restconf and netconf. Kent: Bulk transfer and interactive cli drafts/long running requests. All of these share commonality of request/response. Put together reqs to netconf in mail. Not a lot of response in the wg. Solution will hopefully be applicable to both. Slide 12: Jeff: We will not be able to fully complete the traceability document until we've completed long-running transactions. Carlos: How do we want to address this for now? Sue: Are you asking about the technical or process piece? Carlos: What type of text should we add? Jeff: Likely a opaque text string is sufficient? Sue: Problem statement should be added as pointer into document. Leave editorial note. Carlos: Makes sense to me. Next steps: Asking for WGLC next ietf? This is a simple document. Sri: Field, actor-id is first place that it is defined. Last interim - discussed broker model/secondary id? We should reconcile the terminology? Carlos: Good point. Let me see if we are referring to actor-id as secondary identifier. We will take care of this. Kent: Just forwarded email to i2rs related to this. There has been no discussion about it since that mail. Sue: Do you think the reqs should be done in i2rs and solution in netconf? Kent: Seems reasonable. [Pub-sub model] draft-voit-i2rs-pub-sub-requirements-00 Presenting: Eric Voit [slides] Dean: When you say yang data stores, this is the data that is l on the yang data that was created? Eric: Correct. Dean: Do you have to be notified when the yang data is changing? Eric: There is certainly version control on the yang models. What we're trying to understand is if individual objects in a model is changing. Frequent changes on specific objects. This requires good hygiene on version-ing of individual models. Dean: I understand, thanks. draft-netmod-clemm-datastore-push-00 [Q&A] Eric: Want to make this a WG draft. Would like feedback. Jeff: I think this captures our requirements and should be adopted. Sue: Me too. Dean: Also agreed. Don Fedyk: If a request is resource intensive, what are the rate limiting mechanisms? One valid response is a partial response, then indication that you have exceeded. Eric: That would be a good thing in requirements document, along with the mechanism in the technology doc. We have not pointed out how to do the analysis. Point for progressing the document. Alberto: We are considering two mechanisms, when pub gets request, the client gets an indication what can be fulfilled at subscription time. Ongoing, the publisher provides indication how things may change. E.g. suspended. Eric: What does exhausted means will vary depending on objects, etc. Want to put together a quick demo code of how such a mechanism would work. Can demo at a future meeting? Sue: I would be interested. Kent: The initial transport focus was netconf, assuming also restconf. Wondering about other transports. If netconf/restconf is the control channel, but the subscription was something that was binary - that is the data plane. For the transports do you mean just the data? Eric: Just the data. Kent: I agree with that. Since the mechanism may use other data transports than netconf, that means that group aside than netconf may also have to be involved? Eric: There may be the ability to change the transports. We have not identified how to jump between transports. Not asserting how that would look like today. Xufeng: Subscription - per client basis? Clients interested in different portions of tree, they may get different kind of notifications? Eric: Subscriber will target the specific nodes of interest. Clients may vary on what they are interested in. Kent: In the reqs doc, like to see non-functional requirements such as max number of clients that will be supported? If the requirement is supporting some number, that may impact implementations. Eric: Can consider it. Negotiation pattern can help with this. Different limits for different boxes. Jeff: SNMP has counter examples. Proxies may help. Not a common use pattern in SNMP. May need to suggest that this pattern be considered in our reqs doc? Eric: With a highly resource intensive stream, it may be useful to a multicast transport. We have not quantified this issue yet. We must address this issue. We'd love to have additional authors and help. Jeff: As long as the subscription mechanism looks like netconf or restconf, we have the ability to specify data models. We have the ability to use middle boxes to proxy this data. If we gather routing statistics from router A and router b. For example, if you use interfaces from one box and a second box; the middle box must be able to distinguish between the two boxes. This must be handled as the "meta" data outside the stream. Eric: We have multiple systems going to the subscription service. We are trying to get the right boundaries so that we can handle the boundaries of the middle box service. Sue: Will begin a WG adoption for this on the list. Please send chairs your comments. Should happen in a week.