Hi Dean, Sorry for the long delay :-( I got felled by an ear infection. Responses in-line.
On Tue, May 6, 2014 at 7:05 PM, Dean Bogdanovic <[email protected]> wrote: > 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 [Alia] Agreed and changed. > High-throughput is always nice to have, but the quantification is a bit > wishy washy. [Alia] I know - it varies based on use-case and what's being controlled. > 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. [Alia] I know it depends on the back-end as well as the protocol. Remember this is the problem-statement and these are desired aspects. I've been trying to encourage less wishy-washy numbers for use-cases, but without much success. Should I just claim a goal of a sustained rate of 10000 simple operations/sec? OR bursts? [Alia] I'll update it to: "At a minimum, the I2RS Agent and associated router should be able to handle a considerable number of operations per second (for example 10,000 per second to handle many individual subscriber routes changing simultaneously). " I'd like better wording and example though. > 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 [Alia] Hmm, I think this is too much detail for a problem-statement. What about for responsive: "Within a sub-second time-scale, it should be possible to complete simple operations (e.g. reading or writing a single prefix)." > 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. [Alia] Can you clarify please? > Dean > > > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
