Dean, Thanks for the thorough review! I'm traveling so will take until Friday for a full response.
Alia -------- Original message -------- From: Dean Bogdanovic <[email protected]> Date: 05/06/2014 6:05 PM (GMT-06:00) To: Alia Atlas <[email protected]>,Thomas Nadeau <[email protected]>,[email protected] Cc: "<[email protected]>" <[email protected]> Subject: draft-ietf-i2rs-problem-statement-01 Alia, Tom, Dave, Have few comments on chapter 5 in the draft The following requirement is fine, but some consideration have to be put in. Example, creating a filter construct or routing table has to be finished, before the next operation like add term to the filter or add route to the routing table is possible. Multiple Simultaneous Asynchronous Operations: A single application should be able to send multiple operations via I2RS without being required to wait for each to complete before sending the next. So would suggest changing from multiple operations to multiple independent operations High-throughput is always nice to have, but the quantification is a bit wishy washy. High-Throughput: At a minimum, the I2RS Agent and associated router should be able to handle a considerable number of operations per second above what basic Netconf or a propretiary CLI can. What does mean basic NETCONF? Today I can do couple hundred RPCs/sec over NETCONF. Question: what is RPC doing? Is it simple operational get or large config push? Or some other complex RPC? There is also difference in creating logical interfaces and adding term to a filter or adding route to a routing table. Creating interface is most taxing one and adding term is fastest create operation. IMO, NETCONF has no problem with throughput, it is the instrumentation and that is something we should focus in I2RS. What constructs do we want to control via I2RS and depending on that, make sure that the protocol can sustain max throughput. In the next chapter you are mentioning Responsive: It should be possible to complete simple operations within a sub-second time-scale. Here you are stating simple operation, so why not define few simple operations and put some quantification with it (in the below examples I'm pulling the numbers out of my hat) example: read routes - single prefix per transaction < 0.5sec - multiple prefixes per transaction < time on the wire + 0.5sec add route - single prefix per transaction < 0.5 sec - multiple prefixes per transaction 1000 routes/sec get filter info - single filter per transaction < 0.5sec - multiple filters and terms per transaction < time on the wire + 0.5sec create filter - single filter per transaction < 0.5 sec - multiple filters per transaction 2000/sec add term to filter - single term per transaction < 0.5sec - multiple terms per transaction 3000/sec get interface info - single interface per transaction < 0.5 sec - multiple interfaces per transaction < time on the wire + 0.5 sec create interface - single interface per transaction < 0.5 sec - multiple interfaces per transaction 100/sec I'm thinking how can you do assurance for i2rs. It looks as it is covered in following paragraph Scalable, Filterable Information Access: To extract information in a scalable fashion that is more easily used by applications, the ability to specify filtering constructs in an operation requesting data or requesting an asynchronous notification is very valuable. but it is not spelled out. Dean
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
