Jamal, On Tue, Apr 22, 2014 at 09:21:14AM -0400, Jamal Hadi Salim wrote: > On Mon, Apr 21, 2014 at 3:02 PM, Jeffrey Haas <[email protected]> wrote: > > 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. > > > > Do you see a whole BGP table (or larger) being injected/dumped via I2RS?
I can definitely see such a case, although the more likely paradigm is injecting a large number of RIB entries that may have some BGP properties, such as communities or inputs to various BGP-like policy mechanisms. > > but I'm happy to provide wiki space for these things to be enumerated. > > > > That would be nice. I have created stubs in the wiki for such comparisons. Would you mind starting the work for FORCES? http://wiki.tools.ietf.org/wg/i2rs/trac/wiki You will require a datatracker login. If you run into issues with editing, please unicast me. This is the first time I'll have done more than editing it myself. If someone is willing to start stubbing in similar items for Netconf/Yang, that would be helpful. > On compute: > I would expect json to perform better than XML when sending to a browser. While I think that detail is true, I suspect a browser is not the first order consumer of the information. > In particular given that json is a native format to javascript (but > also heard of > some decent C/python parsers). If you extended that thought to binary data > it will likely perform better than json to an I2RS agent because > it is closer to the native format of the I2RS agent ( a lot less > translation needed). My general experience with such things is that JSON does fine when you want to pass around JavaScript native data, but that you lose some of the semantic layering in turning things into JavaScript. My personal preference would be that if we provide JSON layers that they effectively be at the far end of the pipe (UI facing) rather than the native object in-protocol. Obviously such details are discussion points and the above is simply my opinion and experience. > String processing may be alleviated with newer instruction sets that > processor vendors are putting out (glibc uses some of the SSE > instructions on x864 when > available to do things like strcmp) - but that still will not give you > the 3-5% difference > claimed. There's also a bunch of vendors who would sell you xml or > string processing > offload. But i wouldnt call that commodity or depend on that when > defining wire format. While certainly not a constraint on the working group, I tend to remember that we want I2RS to be as pervasive as possible. This means that anything we can make work well on older platforms means it's more likely to be supported across a wide range of devices. This has impact, for example, on crypto load. [Several other good points that should be in the wiki entry elided.] > Should be noted that it is not just about compute resources, but also > network resources. > If i send 1000 RIB components in ascii (doesnt matter whether it is > json or xml) vs > the same amount in binary; i would expect the wire resources to be > several magnitudes > better with binary. It will also be a lot closer to native format the > RIB manager > uses. Same with sending XML vs json to a browser - json is a native > format to javascript > and a lot more compact, therefore will perform better. > Wire performance can be improved by the classical technique of using > compression > on the wire. That adds cost to the cost of compute. I think I made this observation at the last IETF session: Even for simple compression, XML tends to compress *very* nicely with small dictionaries. Since HTTP compression is well deployed, I suspect this isn't quite as big a deal as it could be. Of course, that presumes we're layering on top of something HTTP-like. > > But an (IMO) advantage of text-based systems is that it's pretty trivial to > > do a lot of things. > > This is true. The cost may be extensibility as i said above. > Note: most of the time the arguement ive heard for ascii is it is > useful for the operator > for debugging - which clearly not true considering the wire format is always > encrypted. This may have been true for smtp or early days of http - but > clearly > not true for the domain we are talking about. It's pretty common to either tap before or after the transport APIs for debugging. I think the distintion is that in something text-like you can tap and do thinks potentially simpler than if you have to look at binary PDUs. That requires tapping one level back before the binary marshalling layer. Obviously that is doable as well, but simply moves the point of complexity one layer up/down. > >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. > > > > I am juggling that in my head and not seeing going ascii from binary. To offer a somewhat BGP network operations example, those who use the MRT file format (RFC 6396) typically have programs that convert from/to that format in human-readable form. Some users may use binary API to interact with the files but the majority of operators I've interacted with that use it tend to simply transform it to ASCII and Do Something Clever using their favorite scripting language. > So my take on this is: > Lets have the informational description of what I2RS needs - perhaps > by going over > use cases. It is easy to provide the ForCES view of those model. I've left a stub in the wiki for helping to derive or map requirements. -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
