Re: Re: VoIP peering & routing protocols (revisited)

["Kalogiros Constantinos" <ckalog@aueb.gr>]

======= At 2005-04-19, 22:52:58 you wrote: =======
>I'll agree with both Randy and Richard and say that the complexity of 
>TRIP perhaps outweighs it's usefulness, and the fact you mentioned 
>that there are large numbers of "real-life" attributes that are 
>missing from the spec makes most people hesitant to commit the effort 
>into coding an open-source implementation that could expect 
>wide-spread use.   Chicken, egg.
>
>I still hold the theory that if a well-written, complete, extended 
>(QoS metrics, pricing information, authentication information), 
>BSD-licensed version of the TRIP stack were produced or released, 
>that it would gather more momentum than it has now, which currently 
>hovers right around "absolutely none."  Feel free to pester the guys 
>at Acme Packet into releasing their TRIP stack as open-source, which 
>I think would be an excellent start.

Of course, complexity vs functionality is a tradeoff that cannot be ignored. However, in a competitive environment like VoIP market (where real money are exchanged and thus there are a lot of issues to be tackled) complexity is inherent. On the other hand, TRIP operation should not be a big problem with so many experience gained from BGP...
>
>Another problem with TRIP's basic design is that it is championed as 
>being "very similar to BGP."  BGP assumes that routes are 
>redistributed with path information to other peers.  I think that in 
>the IP telephony world, this model rests on the assumption that those 
>entities which are exchanging route information don't mind if their 
>peers see information about the actual endpoints.  I think that most 
>"carriers" want to disguise this information, so the TRIP model is 
>already looking like a hub-and-spoke model instead of a mesh as far 
>as the full routing knowledge database is concerned.  (Let's say I'm 
>Banzai Telegraph and Telephone, and I buy/exchange routes from/with 
>Quince Telecom and I use TRIP as the protocol for exchange.   In 
>addition, Quince Telecom buys routes from Sprout Telecom. 
>Realistically, Quince Telecom would never tell me (BTT) about the 
>fact that a certain route was learned from Sprout Telecom - they 
>would want to disguise that fact so that BTT would not circumvent QT 
>and send traffic directly to Sprout.)

Indeed... However (correct me if i'm wrong) path information is only used as a selection criterion (estimating financial cost, and quality if media path = routed path). In VoIP,  the main criteria are least cost routing (assuming existance of pricing info) and quality (information collected locally). So this should not be a great obstacle...
>
>So, we're back to the model of clearinghouses, even if TRIP (and 
>other protocols) emerge as methods for route exchange.  Trust, 
>authentication, and centralized control are still unfortunately very 
>high on the list of requirements for any route exchange.  If you're 
>looking for a TRIP-like model, see the (open-source) Asterisk 
>project's DUNDi protocol, which has some interesting concepts but is 
>currently stunted by being exclusively integrated into the Asterisk 
>call management system.  DUNDi also has some of the same problems as 
>TRIP, but at least is being implemented in what seems to be a real 
>manner (though it also lacks the pricing and QoS metrics that I think 
>are critical for carrier interconnection.)

I definitely agree with you. The question is: What is the value of a distributed system to providers?

>
>JT
>
>
>
>-- 
>
>.
Costas Kalogiros





--
To unsubscribe send a message to voip-peering-request@psg.com with
the word 'unsubscribe' in a single line as the message text body.
An archive is at <http://psg.com/lists/voip-peering/>.