Re: IETF 55 EOS WG Minutes and Presentation
Juergen Schoenwaelder <[email protected]>
| Newsgroups | gmane.ietf.eos |
|---|---|
| Message-ID | <[email protected]> |
>>>>> Wijnen, Bert (Bert) writes: Bert> I did not get a warm feeling at that point. In fact I was quite Bert> disappointed with the response as to how many want to "help", Bert> "review", "implement", "use" this technology. I certainly like to use and support "a faster retrieval mechanism". Retrieving SNMP tables of non-trivial size often reminds me of the days where I found kermit over a 9.6k serial line a cool thing to have. I ship megabytes of documents around with virtually no delay (according to human think times) on the Web these days, but getting a few hundred rows out of the average SNMP enabled router nearby is so damn slow that you can't really build serious applications other than debuggers (called MIB browsers) or relative static polling engines. Even answering simple questions such as "tell me the physical port and the status of the interface with IP address X" by joining the ipAddrTable, ifTable and entPhysicalTable on some of my real-world boxes (in what people classify as an enterprise network) reaches response times that are hardly acceptable in the 21st century. I encourage Wes to move on and especially to implement his ideas as part of NET-SNMP so that the SNMP community can play with it. If the new protocol operations turn out to provide significant speedups for things like the example query mentioned above, then I believe that others will use these features in their applications and finally customers will ask for applications that give a much more reasonable response time. Of course, one can argue that answering queries like the one mentioned above with SNMP is not a good usage of this kind of protocol in the first place. And in fact, on some boxes it is faster to just dump the configuration and extract the relevant information from there. If the consensus is that this is how we approach network management problems in the future, then of course we do not need things like EOS and SNMP is just fine as it is today. /js -- Juergen Schoenwaelder <http://www.informatik.uni-osnabrueck.de/schoenw/>