[VoiceOps] Does anyone implement RFC 3219?

[Paul Timmins]

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