On Mon, Apr 21, 2014 at 3:18 PM, Thomas Nadeau <[email protected]>wrote:
> > > > On Apr 21, 2014, at 12:46 AM, "Jan Medved (jmedved)" <[email protected]> > wrote: > > > > > > > >> On 4/19/14, 5:49 PM, "Jamal Hadi Salim" <[email protected]> wrote: > >> > >> On Sat, Apr 19, 2014 at 4:11 PM, Dean Bogdanovic <[email protected]> > >> wrote: > >> > >> > >>> It comes down how many transactions are required? Will you updated 1000 > >>> routes in single transaction or in 1000 transactions. > >> > >> Take your pick. The point is it boils down to how that is modelled and > >> carried > >> over the wire (and influences those decisions). > >> > >>> From my perspective there are two important metrics for i2rs > >>> throughput > >>> and > >>> latency > >> > >> Now we are talking. > >> > >>> > >>> 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. > >> > >> Agreed. > > > > 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. > > This is the right approach. The speed up vs pita factor for binary > encoding isn't worth it. And as you say, the CPU performance is so fast > even today that it's not an issue. > > > > > > >> > >>> 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. > >> > >> But i do believe there are limitations which are not obvious without > >> contrasting against requirements. > >> > >>> You can add your comments to the existing drafts. > >> > >> I would gladly do - but i worry whether the discussion is about crowning > >> some > >> solution instead of meeting such objectives; if the WG decides to move > >> in that > >> direction i would be happy to contribute. > >> There's material floating, the old protocol draft; Joel pointed to the > >> architecture > >> draft covering model requirements. Andy mentioned possible "stretch" > >> requirements. I think what would be appropriate is one draft for the > model > >> and one for the protocol with gap analysis. > >> > >>>> > >>>> 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. > >> > >> 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. > > > > 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. > > I agree. I've always viewed what needs to be done as more or less a subset > of what's in netconf today. > > I will try to be more specific here. IMO: I2RS = (NC | RC) + YANG - datastore_validation - NV_storage + owner_priority_ACM My early implementation feedback (hope to be done before Toronto): The message encoding has virtually no impact and it is not the bottleneck. The new protocol stack screams, because distributed YANG validation and NV-storage can be really expensive. The system's ability to activate changes in the underlying firmware is the bottleneck in NC/RC, and that depends on the implementation. > Tom > > Andy > > > > > > > > >> Note: The draft is a good starting point but is missing as an example > >> the issue of > >> latency and throughput. > >> > >> cheers, > >> jamal > > > > _______________________________________________ > > i2rs mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/i2rs > > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
