On Apr 19, 2014, at 3:08 PM, Jamal Hadi Salim <h...@mojatatu.com> wrote:
> On Sat, Apr 19, 2014 at 10:22 AM, Dean Bogdanovic <de...@juniper.net> wrote: > >> >> What is working i2rs code? > > Code that implements, using your choice of model and protocol, the I2RS > semantics. To examplify using your slides at the meeting, iirc, > such semantics would be between the agent one side and what iirc > you called client (in our case we call them Apps). > i.e take something like the RIB info model and cast it into your model choice > and make APIs available to message things between a basic agent and > the routing daemon. > >> From Juniper perspective, I can claim having PoC i2rs code, as I can >> dynamically create >> REST APIs (will not call them RESTconf, as it has only partial compliance >> with >> current RESTconf draft) based on the service described on the device. The >> PoC functionally >> is very close i2rs architecture document and with that can see what services >> can be created >> and abstracted for i2rs. >> >> So for i2rs, as long I can create a data model for a service, where the >> service is simple as add or >delete route and can programmatically consume >> that service, it is i2rs. Many vendors today can do >that with >> NETCONF/RESTCONF/YANG and we are voicing our preference for that. >> > > Sorry, I dont think that is sufficient. The programmatic APIs part is obvious. > There are bigger issue which shape how a protocol is to be wired and > what model would be > sensible; in my response ealier, one you and I discussed was speed. > How do you do > a 1000 route update or add with JSON? It comes down how many transactions are required? Will you updated 1000 routes in single transaction or in 1000 transactions. >From my perspective there are two important metrics for i2rs throughput and latency 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. 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. > If it is a requirement then the agent needs to be able to handle > clients of different > latencies etc and deal with congestion issues that are common in proxies when > you have multiple users being considered and probably a single entry > to the routing interface. > If it is not a requirement - should that not be stated somewhere? You can add your comments to the existing drafts. > > 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. > > cheers, > jamal _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
