Dino,Dino,Whether "it's not at all bad" depends on the locality of the traffic.Right, the guys at UCLB are gathering data on this.Ok.To preserve "truth in advertising" the LISP spec needs (a) to clearly spelled out the assumptions you make about the locality of the traffic, as well as (b) to document the system behavior if these assumptions turned out to be incorrect.Right, but we don't have the data yet so that is why it's not documented.Just because "we don't have the data yet" is *not* a valid reason forwhy (a) and (b) are "not documented". This is because to document *assumptions* does not require the data - the data is required to test the assumptions. Likewise, documenting the system behavior if the assumptions turned out to be incorrect does not require the data.We are assuming, at this point, nothing in terms of traffic locality.First you agreed that whether "it's not at all bad" depends on the locality of the traffic. But then you assume "nothing in terms of traffic locality". Putting the two together means that you have no clue on how bad that is going to be.
We have a rough idea but no data yet to back it. That is all I am saying Yakov.
And, by the way, you still did not answer my original question. Namely, what were the problems that motivated development of CEF, and how these problems would be solved in the context of LISP ?
I did answer it. It was software switching based population of the hardware or faster path forwarding cache.
Dino -- to unsubscribe send a message to rrg-request@psg.com with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg