On 4/19/14, 5:49 PM, "Jamal Hadi Salim" <[email protected]> wrote:
>On Sat, Apr 19, 2014 at 4:11 PM, Dean Bogdanovic <[email protected]> >wrote: > > >> It comes down how many transactions are required? Will you updated 1000 >> routes in single transaction or in 1000 transactions. >> > >Take your pick. The point is it boils down to how that is modelled and >carried >over the wire (and influences those decisions). > >> From my perspective there are two important metrics for i2rs >> throughput >> and >> latency >> > >Now we are talking. > >> >> IMO, I2RS agent has to provide as high as possible throughput and add >>minimal latency to the >process. What is the throughput required? Don't >>know at the moment. I saw some request in high >single digit thousands >>per second, but not sure about use cases. On the latency side, you want >>it as >close to 0 as possible, but that will be highly platform >>dependent. >> > >Agreed. Both throughput and latency are meaningless from the standardization point of view - they both largely depend on the underlying system. Speaking for NC/Y implementations that I¹ve been involved with, the throughput of the Netconf Agent itself is much larger than the rest of the system, and its latency is negligible compared to the rest of the system. This happens to be true both for an embedded agent (XR), where ultimately both throughput and latency are determined by how fast you can program hardware, and for the controller, where both throughput and latency depend on how fast you can shove things into a data store. Rather than focusing on devising a super fast binary encoding for the protocol (which will speed up maybe 2-5% of the overall CPU cycles), we need to have a self-describing schema-based message encoding which allows for creation of tools that generate most of the agent and client code. NC/RC/Y gives us exactly that. The raw speed of the agent (optimized protocol processing, message encoding, etc.) must be weighed against the ease and speed with which new APIs can be added to system - we have Moore¹s law for CPUs, but not for human brains ;-) We need to compensate for that with tooling/automation. > >> I have to start doing some PoCs to see what can and can not do with >>existing tools. If those tools >work, then good. If those tools don't >>work, then back to the drawing board. Until things work, keep on >moving >>with what works and try to find break points. >> > >But i do believe there are limitations which are not obvious without >contrasting against requirements. > >> You can add your comments to the existing drafts. >> > >I would gladly do - but i worry whether the discussion is about crowning >some >solution instead of meeting such objectives; if the WG decides to move >in that >direction i would be happy to contribute. >There's material floating, the old protocol draft; Joel pointed to the >architecture >draft covering model requirements. Andy mentioned possible "stretch" >requirements. I think what would be appropriate is one draft for the model >and one for the protocol with gap analysis. > >>> >>> Unfortunately - we are not having that kind of useful discussion and i >>> feel like a broken >>> record asking for requirements. >> >> I believe we have a set of requirements. It is in >>draft-rfernando-i2rs-protocol-requirements. >>You can always comment that draft and argue pro and con each requirement. > >Glad we are bringing that draft into play;-> How does restconf fair >against it? Reasonably well. When we evaluated restconf against these requirements (I am a co-author), the major deficiency found was lack of notifications in restconf, which was addressed in a subsequent restconf revision. There are still things that would have to be added (for example, client identities), but this can be addressed either in the protocol or in models. There is nothing *structural* in restconf that would prevent it from satisfying the requirements set. And as I said earlier in this thread, about 80-90% of what I can think that we can do with I2RS (and it¹s much, much more than just RIB programming ;-) ) can be addressed with NC/RC/Y today. >Note: The draft is a good starting point but is missing as an example >the issue of >latency and throughput. > >cheers, >jamal _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
