On Mon, Apr 21, 2014 at 07:36:44AM -0400, Jamal Hadi Salim wrote: > On Mon, Apr 21, 2014 at 1:46 AM, Jan Medved (jmedved) <[email protected]> > wrote: > > On 4/19/14, 5:49 PM, "Jamal Hadi Salim" <[email protected]> wrote: > > > > Both throughput and latency are meaningless from the standardization point > > of view - they both largely depend on the underlying system. > > I am sorry, I disagree. Understanding latency and throughput needs is > fundamental.
I agree - the understanding is required to help us decide whether the properties of a given data modeling language/protocol pairing satisfy our requirements. It may not be the primary deciding criterion but it will certainly be a big one given the high-throughput desires we have for I2RS. To use this as a jump-off point, what we need is a listing of such requirements and properties of a given data modeling language/protocol that realizes that perhaps better than another example. I'm still familiarizing myself with the IETF wiki and am unclear what sort of security permissions are present in it, but I'm happy to provide wiki space for these things to be enumerated. For the above item, there are various properties from the different mechanism that may be of benefit. (I'm still not through my protocol reading, so mistakes in characterization of a given protocol are all mine.) The binary encoding of FORCES may help with speed. It was asserted elsewhere (copied below) that this may only be 3-5% of a speed improvement. (I had thought I recalled a discussion in netmod(?) at one point of a BER format for YANG, but my google-fu is failing me.) A somewhat negative property of XML is that a document is only considered valid once you have the whole document. Thus, document size may matter. > Your focus in that case is provisioning. I2RS is not a CLI replacement. > It is not a provisioning system. If i am mistaken and it falls under > the auspicies > of either CLI replacement or provisioning - then by all means Netconf/Yang is > a clear selection and lets end the discussion. I've been working through the various I-Ds in detail. Using the BGP use case as an example, one of the desires may be to dynamically provision BGP peering sessions. Given that the I2RS cases are not strictly to provide the configuration of BGP but are likely a subset of this piece of configuration in an ephemeral context, this seems to suggest that the I2RS pieces of the system should ideally have good alignment with configuration systems. Thus, if YANG were used for provisioning BGP, there's a strong desire for there to be symmetry in the I2RS model - and thus potentially to share a portion of the YANG. The same observation would hold for a FORCES implementation of I2RS. Another example is the RIB. We want to leverage existing data models in a configuration context while also providing I2RS extensions for configuration, monitoring, etc. > Even if say a few tens/transactions per second is what the requirement says > then I would go with your approach. > > > 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), > > I'd like to argue your 2-5% (as i am sure papers which have been written on > how > to speed up string processing will), but lets just ignore that for a sec: > Lets say your approach takes 1000 cycles. You can say only 2-5% of those > cycles > are used for encoding/decoding ascii. That would be a correct statement to > make. > What it is ignoring is: you are spending 1000 cycles instead of 50 for > the overall > computation. The other half of such a discussion tends to be around letting other consumers of the encoded information Do Something Useful with it. This does to some extent argue and influence what your programming model/API is. If your access to everything is always via strict API, binary encoding a great. But an (IMO) advantage of text-based systems is that it's pretty trivial to do a lot of things. I suspect I'm not the only one that uses text-based expansions of binary objects for various work. (And I'll also note that I leave things in binary format with API access when it makes sense.) What I'm really saying is that the ecosystem is likely to expand binary encoding to text just as much as it's going to move to a binary encoding. > >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. > > > > So does ForCES. BTW, Ive heard you repeat this statement above a few times > (as well as from Thomas); Would you say section 4.5.3 of RFC 5812 provides a good example of that? (Just to pick one from my reading.) > > 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. > > > > Lets take that hammer and use it to fix everything we see on our way. Jamal, while the point is being made perhaps a bit less than pleasantly, there is certainly something there to discuss: The work Jan cites has a depth of models that cover many pieces of functionality similar to those that I2RS looks to address. They've done enough work against Yang/Netconf to have an idea of the remaining gaps. While I agree that within the limited scope of the FORCES documents that I've read that the modeling language and to a large extent the protocol can similarly address the problems, I haven't the depth to determine whether similar coverage of I2RS cases can be done within FORCES and what would need to change. It is also unclear aside from the binary encoding / more atomic transaction model (note, I haven't read restconf yet for proper comparison) that FORCES would bring vs. Yang/Netconf. That comparison is what the WG needs in somewhat greater depth than the existing gap analysis. -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
