Dino, > >>> Perhaps we should first agree that there is a need a *short term* > >>> solution for both IPv4 and IPv6. The following (from Tony's e-mail > >>> on 5/26/2008) is relevant to the discussion on whether there is > >>> such a need: > >>> > >>> Well, Ross Callon has been quoted as saying that the Juniper > >>> implementation will have no problems up through many millions > >>> of routes. > >>> > >>> Now, conceptually, that could happen tomorrow. However, at the > >>> current growth rates, that's likely to be many years. > >> > >> The routing table size problem is not the only problem. > > > > Good. So, at least we seems to agree that we do not need LISP > > to deal with the routing table size. > > No, you didn't read the sentence carefully, I said "not the only > problem". There is problem with any database that gets too large. > Yakov, the vendor side of it is one thing and most of our products can > support large tables. That's not what I'm worried about. I'm worried > about the increase in OpEx and control plane performance for the > operators.
Wrt OpEx how exactly does LISP going to reduce it, and who are the parties that are going to see that reduction ? Wrt control plane performance, what are the problems that LISP is going to solve ? And if there are already existing solutions to these problems, then why LISP's solution is better ? Yakov. -- to unsubscribe send a message to [EMAIL PROTECTED] 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
