Hi Igor, On 4/21/14, 6:07 AM, "Igor Bryskin" <[email protected]> wrote:
>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? I am not talking about routing protocols, but protocols that constitute “APIs” into the system. Such protocols are NC/RC/Y, Forces, OF, PCEP, ... >2. Do you think we could replace BGP transport with Netconf RPCs? (I am >pessimistic about what Yakov would say about this idea :=)) I am not suggesting that, although it’s doable. In ODL we internally normalize protocol messages on yang-encoded NC RPCs and Notifications before putting them on an internal message bus. We defined yang models for OF, PCEP and BGP messages. BGP, PCEP, OF, etc is used externally, though. When running benchmarks & profiling, the normalization is barely a blip on the radar… The advantage is that we present a uniform view of protocols to apps running in the controller and have bunch of tools that generate a lot of the app code that needs to interact with the respective protocol. It also allowed us to re-use not only code, but design patterns as well. >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? As I said before, the protocol by which you learn the route updates is a small fraction of the overall CPU cycles. For a large scale deployment it’s more about the right organization of data in the RIB for fast updates and scale; after that it’s about the speed at which you can install the routes in hardware. >What if i2rs client is twice as fast as the BGP speaker? I don’t understand the question - how can an i2rs client interact with a BGP Speker? >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? "That's foolish. You pick the one right tool.” (Anton Chigurh in No Country for Old Men) Why would we do that? Two sets of engineering rules, configurations, tool chains, bugs… (My $0.02) > > >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. We have been discussing I2RS use cases and requirements for the past year or so. It is my understanding that at the last IETF there were two proposals that can meet the requirements: Forces and NC/RC/Y. There have been cases made for each one of them - Andy and Dean made the case for NC/RC/Y, and Jamal made the case for Forces. Ed has asked the community to a vote for one of the two. Is my understanding correct or not? If my understanding is correct, why are we going back to square one? >My personal answer to 4. is why not? "I am pessimistic about what Yakov would say about this idea :=))” (... earlier in this email thread) >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 > Thanks, Jan _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
