John Todd wrote:
1) TRIP is great, but ultimately doesn't work on a global basis. It may work in tightly-coupled environments, such as a large multi-national firm, or even a keiretsu-style conglomerate of companies, but in "the wild" it would be unworkable. Why?
a) Phone numbers are not in large spans of sequential space, and are growing more fractured by the day. Just the amount of route injections to cover transferred mobile numbers would (I suspect) be in the hundreds of thousands of records per day if even 50% of the world's phone numbers were in the tables. (Look at some of the update and churn numbers in China and India to make your head spin.)
b) The trust model of who "owns" a number is unworkable in an endpoint-trusted environment with a non-hierarchical routing structure. Who, really, is supposed to get the call for a particular E.164 address? Well, that sounds like the role of a central authority to me. So why have TRIP if you have a central repository? (Feel free to exchange the words "central authority" for "several dozen or even several hundred nationally-designated legally compliant bodies of authority with geographic reign")
c) The potential for abuse or misconfiguration is serious, and filtering to prevent that type of problem (as Alex Balashov notes) is formidable. That would be an understatement. It is nearly impossible. The fluctuations of the route tables would be significant, and even one incident where an "important" number is mis-routed to the wrong person would have possibly two orders of magnitude more of a press/public opinion result than those events that occur with some frequency in the BGP tables.
And as a corollary to this, one only has to look at NANOG and ARIN-Discuss to see that there is a lot of focus on routing table size and prefix length and bloat, especially as it appears to continue growing. And those are just publically routed networks, such as the two /22s my employer has (each customer's /29, etc don't appear in BGP). Routers are already handling something like 300,000 routes right now, and rising. My back of the napkin calculations say that if you wanted to handle routes for every possible thousands block out of every NPA/NXX allocated by NANPA and the CNAC at this time, you'd have 1,627,520 routes in your switch, all of which could be changing at any minute with a dynamic protocol. If each route and its destination took 15 bytes to store, the routing table size would be 24,412,800 bytes (about 24MB) per copy of the table you store. I would assume you would get a copy from each of your vendors, and do some math to determine which one is the cheapest at any given time. Mind you, this is constantly changing (BGP changes enough where you can't even keep the protocol in sync over a 64k ISDN line anymore because of the sheer amount of changes being made to the table at any given time). This sounds easy from the "but my computer has lots of RAM" standpoint, but if your computer is your switch, it should probably focus on doing realtime things like routing audio rather than constantly updating a thrashing routing database. If your computer isn't your switch, realize that this gets that much more unrealistic, as many switches are embedded systems that often have at the most 64M-128M of RAM. And all of this is so each switch can know the endpoint state of every other switch in the world (or maybe just the US?) and maybe its location? This doesn't scale well. Many of the "We can't keep going on like this forever" solutions being proposed in IP land for the issue of route table explosion are similar to enum or the existing US LNP databases, which scale amazingly well compared to the solutions used by ISPs. Note that in a real world deployment, each switch would have to have every ported number in its BGP-like database. I note the emails that I get sometimes that warn that someone will be porting more than 15,000 numbers in an hour from the NPAC, and am very, very glad I don't see things like that on my switch, and have the luxury of just dipping those databases when I need to know who owns a number and where to route it. I'm not necessarily in full favor of the status quo here, but I'm thinking this isn't a good solution to the problem. -Paul