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
