[VoiceOps] Does anyone implement RFC 3219?

[David Hiers]

As a technologist, I really dig clever stuff, and personally wouldn't
mind a  fully-dynamic, self-discovering TN routing scheme.  In fact,
as soon as my VP replaces "reliability" with "dynamic TN routing" on
my bonus plan, I'll be all over it!

Looking back, it was quite a leap to go from being an IP guy that
wanted nothing but instant, stable, route table updates to being a
phone guy that gets the quarterly LERG on a CD.  I just couldn't
believe that SS7 was just a bunch of static route sets on link sets,
and that the routing table was not in my switch as much as it was in
the SS7 network.  I kept thinking that I was reading about SS7v1, and
that all the cool stuff was in the  SS7v2 docs that I could not
find...

Since I don't know exactly which geese are laying the golden eggs to
make my analog POTS phone so reliable, I'm a bit careful when I'm out
picking the bird for the next big dinner :)


David





On Thu, Aug 20, 2009 at 9:42 PM, Paul Timmins<paul at timmins.net> wrote:
> 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
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>