Hi Jan, You said:
" 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 a couple of questions: 1. AFAIK we don't have yet a routing protocol whose speakers exchange XML encoded messages, why is that? 2. Do you think we could replace BGP transport with Netconf RPCs? (I am pessimistic about what Yakov would say about this idea :=)) 3. If I am to develop an i2rs client that can learn or generate route updates at the speed and volume of a regular BGP speaker, can it, using Netconf, instal these updates in the i2rs agent's RIB in a timely manner? What if i2rs client is twice as fast as the BGP speaker? What if there are two or more such i2rs clients talking to the same i2rs agent? Are these are reasonable use cases at all ? 4. Could we replace BGP transport with ForCES? 5. Is it not possible that for some things i2rs will end up using Netconf, while for others ForCES and/or something else? IMHO we can not give convincing answers for 3. and 5. until we see the requirements agreed upon by all interesting parties. In this I totally agree with Jamal. My personal answer to 4. is why not? It is binary and hence as fast. I happen to like the granularity at which ForCES protocol allows for incremental updates and how the messages could be limited both in size and CPU processing to just the very things that have changed. Regards, Igor _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
