Re: [dispatch] Introducing ViPR: a new federation technology
"Bernard Aboba" <bernard_aboba@hotmail.com> Tue, 10 November 2009 03:30 UTC
Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D53413A6836 for <dispatch@core3.amsl.com>; Mon, 9 Nov 2009 19:30:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.252
X-Spam-Level:
X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[AWL=1.347, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kr3q4LdlO0xF for <dispatch@core3.amsl.com>; Mon, 9 Nov 2009 19:30:47 -0800 (PST)
Received: from blu0-omc4-s15.blu0.hotmail.com (blu0-omc4-s15.blu0.hotmail.com [65.55.111.154]) by core3.amsl.com (Postfix) with ESMTP id B51DB3A635F for <dispatch@ietf.org>; Mon, 9 Nov 2009 19:30:47 -0800 (PST)
Received: from BLU137-DS3 ([65.55.111.136]) by blu0-omc4-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 19:31:14 -0800
X-Originating-IP: [131.107.0.70]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU137-DS3E4BCD0CD54026197E49893AB0@phx.gbl>
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: dispatch@ietf.org
References: <mailman.5685.1257817361.4669.dispatch@ietf.org>
In-Reply-To: <mailman.5685.1257817361.4669.dispatch@ietf.org>
Date: Mon, 09 Nov 2009 19:17:21 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcphpykSUsCixUtqTVOlQEfXK0PdsQACLHQg
Content-Language: en-us
X-OriginalArrivalTime: 10 Nov 2009 03:31:14.0426 (UTC) FILETIME=[417EEDA0:01CA61B6]
Subject: Re: [dispatch] Introducing ViPR: a new federation technology
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2009 03:30:48 -0000
Kevin Fleming said: " I came away with the same conclusion you did; it's really only applicable to closely-aligned parties that want to federate, not for any providers that may provide SIP connectivity in between the parties that want to federate. This would make it somewhat complex to deploy in a hosted PBX scenario, unless the ViPR server was also virtualized to provide a separate set of data for each hosted PBX that chose to use ViPR." I'm not sure that it's only applicable to closely-aligned parties. As noted, the DHT approach does scale logarithmically. Although one might quibble with some of the dependencies (e.g. SRP/TLS is encumbered by multiple IPR declarations, as is RELOAD), the overall approach does not require pre-existing trust between the parties. There are existing approaches for moderate numbers of closely-aligned parties (e.g. DUNDI works at that scale, and even the existing RFC 3261 model isn't that broken in for that case, since I'm aware of customers who are federating with dozens of suppliers/customers using TLS with mutual authentication). The bigger issue as I see it is the tying of SIP federation in non-VOIP scenarios (e.g. Video, Web conferencing, IM&P) to PSTN and phone number identifiers. In those scenarios, the proposed introduction and verification mechanisms aren't much better than existing "buddy list" techniques for trust establishment. Those techniques have been in use for a long time (e.g. in XMPP federation) and have proven quite effective. Also, if one buys the arguments, then one could conclude that all that is necessary for VOIP bypass is a PRI and an Internet connection. Why bother with SIP trunking? However, that argument assumes that as the decline in the PSTN accelerates that SIP Trunking providers will utilize infrastructure ENUM to their advantage to route calls directly over the Internet without passing on the savings to customers. However, the evolution of Internet peering would indicate this not the most likely outcome. Back in the mid-1990s, peering was a significant issue for second Tier ISPs and access cost much more than it does today. Today recent measurements show that 50 percent of Internet traffic is originating in only 150 ASes, and that kind of consolidation also tends to go along with major declines in consumer costs and an lessening of importance of peering concerns. So my own guess is that as SIP trunking becomes a commodity that the industry will grow more and more competitive and that in a decade infrastructure ENUM will apply to a very large fraction of all calls, with the benefits being passed on to customers. In that kind of scenario, ViPR would be unnecessary.
- [dispatch] Introducing ViPR: a new federation tec… Jonathan Rosenberg
- Re: [dispatch] Introducing ViPR: a new federation… Richard Shockey
- Re: [dispatch] Introducing ViPR: a new federation… Kevin P. Fleming
- Re: [dispatch] Introducing ViPR: a new federation… Bernard Aboba
- Re: [dispatch] Introducing ViPR: a new federation… Henry Sinnreich
- Re: [dispatch] Introducing ViPR: a new federation… Jonathan Rosenberg
- Re: [dispatch] Introducing ViPR: a new federation… Bernard Aboba
- Re: [dispatch] Introducing ViPR: a new federation… Bernard Aboba
- Re: [dispatch] Introducing ViPR: a new federation… Klaus Darilion
- Re: [dispatch] Introducing ViPR: a new federation… Klaus Darilion
- Re: [dispatch] Introducing ViPR: a new federation… Paul Kyzivat