On Mon, Apr 21, 2014 at 1:46 AM, Jan Medved (jmedved) <[email protected]> wrote: > > On 4/19/14, 5:49 PM, "Jamal Hadi Salim" <[email protected]> wrote: > > Both throughput and latency are meaningless from the standardization point > of view - they both largely depend on the underlying system. >
I am sorry, I disagree. Understanding latency and throughput needs is fundamental. We are talking about a part of the system that is optimized for speed typically (at least I hope your RIB manager is) that you will now need to interact with. We are not talking about you banging at some 8 bit PIO bus on a micro-controller. > 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. > You have a single user in that case. Factor in the many users. Your focus in that case is provisioning. I2RS is not a CLI replacement. It is not a provisioning system. If i am mistaken and it falls under the auspicies of either CLI replacement or provisioning - then by all means Netconf/Yang is a clear selection and lets end the discussion. Even if say a few tens/transactions per second is what the requirement says then I would go with your approach. > 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), I'd like to argue your 2-5% (as i am sure papers which have been written on how to speed up string processing will), but lets just ignore that for a sec: Lets say your approach takes 1000 cycles. You can say only 2-5% of those cycles are used for encoding/decoding ascii. That would be a correct statement to make. What it is ignoring is: you are spending 1000 cycles instead of 50 for the overall computation. > >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. > So does ForCES. BTW, Ive heard you repeat this statement above a few times (as well as from Thomas); Programmatic APIs are a given. We've had them in ForCES implementations for a few years. We were told IETF is not about APIs - just protocols; so nobody bothered. I will make that clear again: We have programmatic APIs. >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 ;-) Agreed - but within reason. There is a cross-over where it is abuse of human intelligence i.e there is a threshold where it is not sensible to optimize for efficiency at the expense of usability - but if i can get both; what is the problem? I dont think we are that different from a usability perspective. We have different perspectives. You have been doing provisioning systems where latency and throughput require to be better than humans; I have been working on systems where i need to failover or have a board with a few hundred thousand table rows boot up very fast. My view is I2RS is closer to my perspective. >We need to compensate for that with tooling/automation. > Jan, how about this: You show up with your tools and i will show up with mine. The starting point would be an information model that none of us have seen before. Lets convert that to a data model, output code and start using it via an app. If I beat you by <5 minutes - you win. Lets do this live at the next meeting;-> >>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. > As i said earlier, the draft is a good starting point but not sufficient (It also delves into areas that are not protocol specifics). To be honest, I dont recall seeing it when i published my gap analysis here: http://datatracker.ietf.org/doc/draft-hadi-i2rs-forces-gap-analysis/ I was going to update my draft (in which case I will reference it); but i am not sure if it will be worth it. > 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. > Lets take that hammer and use it to fix everything we see on our way. Note: I am not even arguing ForCES is the way to go - this may be a totally different protocol. cheers, jamal _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
