Hi Jan, Please, see in line. Igor ________________________________________ From: Jan Medved (jmedved) <[email protected]> Sent: Monday, April 21, 2014 12:55 PM To: Igor Bryskin; Jamal Hadi Salim; Dean Bogdanovic Cc: [email protected]; Joel M. Halpern; Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model
>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, ... IB>> Were do you see routing or signaling protocols different? Why can't you use for example Netconf/YANG for provisioning of TE paths? >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. IB>> Same question: why don't we replace signaling and routing protocols with Netconf/YANG and have a universal tool for all network control needs? >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. IB>> But the WG like i2rs can only influence on the speed of the protocols, not internal NE architecture and infrastructure as you keep referring to as well as the facts we have to take your word for. >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? IB>> I meant to say what if i2rs client can produce calls to RIB manager twice as many as local 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? "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) IB>> Well, in the past we had a choice which IGP to use: OSPF or ISIS. The decision was to let market to decide, and it turned out that both are well deployed. Another example, we had to choose which signalling protocol to use for setting up TE paths. In this case we decided to choose one and ended up with the RSVP-TE, arguably the worst possible choice we could make (at least in case of transport networks), discarding all other options in a very early stage. > > >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? IB>> I don't think we have a satisfactorily protocol/model requirement document yet, which is a tightly defined an unambiguous enumeration of qualitative and qualitative parameters of the protocol and model that are required, desired, etc. for i2rs architecture to be successful (Take a look for a good example at MPLS-TP requirements RFC). We have to go to square one and write such a document, I think Cheers, Igor _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
